Operations | Monitoring | ITSM | DevOps | Cloud

The internal DevOps team at JFrog needed to provision cloud resources, create environments, and manage infrastructure for our developers. Unfortunately, it involved wasting a significant amount of time on repetitive tasks, that was slowing down the pace of innovation and taking away our developers’ focus from building new features and industry leading products.

Most CircleCI pipelines are configured to trigger automatically on code commits, but not every development scenario fits that model. Sometimes you need to trigger a build manually—to test pipeline changes, retry a flaky test, or run CI on a colleague’s branch—without the friction of pushing empty commits or navigating to the UI to manually trigger a build.

In our post, 9 Continuous Delivery Tools For Reliable Releases, we explored why continuous delivery is critical to building robust development pipelines — and how it helps teams deliver customer value while boosting the bottom line. Today, we’re diving into the next evolution of that pipeline: continuous deployment. Today’s technology companies need to release quality features quickly and put them in users’ hands even quicker.

Containers have been with us for a while and are ubiquitous in the Secure Software Development Life Cycle (SSDLC). According to some reports, nearly 60% of organizations use containers for most or all of their production applications. It’s no surprise really, as containers provide consistency and standardization across the lifecycle while speeding up delivery pipelines. They revolutionized how we develop and deploy apps in the cloud and there is no sign of this changing anytime soon.

In a single pipeline, it’s easy to control job order. But in a large engineering org with dozens of pipelines, hundreds of contributors, and countless shared environments and services, that control can start to slip. Pipelines interfere with each other. Deploys overlap. Test environments break. Someone merges code, triggers a build, and gets a failure they can’t reproduce. Unfortunately, this kind of instability is a routine byproduct of scale.

At CircleCI, we’re committed to making our platform work seamlessly with the AI-powered tools that developers increasingly rely on. Our journey into AI integration is focused on creating a robust Model Context Protocol (MCP) server that allows AI assistants to access and understand CircleCI data in real-time. This enables developers to debug build failures, analyze test results, find and fix flaky tests, and improve pipelines using natural language within their favorite AI tools.

Distributed architecture is increasingly being adopted in current software systems because it brings great scalability and flexibility, keeping them resilient under real-world conditions, Unfortunately, this new distribution also introduces new points of failure in the systems. Traditional testing methods are no longer enough; they focus only on whether a system works, not on whether it keeps working under stress or failure. That is where chaos engineering comes in.

CircleCI gives you deep visibility into your builds, workflows, and tests, but jumping between browser tabs, copying project URLs, or re-authenticating across tools can slow things down. What if your IDE could just show you the projects you’re working on and let you act on them directly? This post shows how to use the list_followed_projects tool in the CircleCI MCP server to browse and interact with your CircleCI projects by chatting with an AI assistant inside your IDE.