CircleCI - MCP Server

I have been using CircleCI  for the past four years.

CircleCI  is mainly used for creating Docker  images and deploying them into the Kubernetes  environment that we have.

We have three branches: dev, staging, and pre-prod. Whenever there is any code that goes into the dev branch, it gets automatically triggered via CircleCI. It creates the ECR image for multi-architecture and pushes it into the ECR. After that, it performs a kubectl rollout status for that. For three different tags including staging and dev, we have different environments, and different tags are pushed to it, with codes pushed to the different ECRs that we have.

It gets triggered automatically by code changes, so it is quite easy, and we have configured YAML for it. Notifications come to our Slack whenever there is any code pushed or something on our page.

The best feature about CircleCI is running multiple jobs in parallel. We do not have to maintain anything, as there is no server maintenance required. It starts building in minutes and has easy, excellent container support, as well as faster pipeline deployments, easy PR-based pipelines, deep integration with GitHub  and GitLab  that we have wanted, and no need to manage agents manually.

Running parallel jobs where dev gets automatically updated every time has helped our team significantly. We have that running with test cases executing as well as sometimes a module that has a backend and frontend with both codes inside it. Different parallel jobs are running, executing, and checking those for different multiple test cases. An ECR build is running on the multiple sides of it, creating the Docker  image. If one of those parallel jobs fails, then the other automatically gets failed. It saves a lot of time to do those things.

There is no need to manage agents manually, and no server maintenance is required, as this is a SaaS model, so it is quite easy.

CircleCI starts building in minutes, and there is no need to manage agents manually, as well as it has excellent container support, can run multiple jobs, and speeds up the CI/CD significantly. It has helped us a lot.

I see faster deployment times as an outcome. Not reduced cost because it is costly, but definitely faster deployment times, as it is a parallel-based solution.

Time saved is one of the things that we have observed. We have saved a lot of time.

CircleCI is quite stable.

CI/CD is quite scalable. It is highly scalable, as it is not on our system, so we do not need to take care of the runners as well.

CircleCI can be improved by making it less costly, as it is very expensive. The config complexity, like the YAML config, can become messy in complex projects. Making it simpler, much like having a Docker Compose YAML or Kubernetes  YAML, is necessary from that perspective.

Rather than keeping it a SaaS project, they can think of it through a Jenkins  approach, where we can also self-host it into our environment, but it is acceptable.

It is very expensive, and many organizations cannot afford it. The config complexity, like the YAML configs, can become messy in complex projects. A better DevOps person can only handle it, not a normal person. For that reason, I chose a rating of seven.

It is quite expensive, to be honest. As mentioned, many organizations cannot afford it because of the parallel execution prices as well as the config complexity.

I have been working in my current field for more than six plus years.

CircleCI is quite stable.

CI/CD is quite scalable. It is highly scalable, as it is not on our system, so we do not need to take care of the runners as well.

Customer support is highly worth it for the money that is there.

I would rate the customer support a ten out of ten, as they take money but provide the best customer support.

We have tried Jenkins  as well as GitHub Actions  for it. We switched from Jenkins because we had to maintain our own runners and everything there, which provided less control. For GitHub Actions , since it is a cloud-native solution, we wanted to use CircleCI, which has a quite good community-based support.

I evaluated Jenkins, GitHub Actions, and GitLab  CI/CD.

My advice to others looking into using CircleCI is to just not get overwhelmed by the complexity, particularly the config complexity. Just try to learn it, as now AI tools will definitely be there to help you out. Start using it, and once you get used to it, ask them to have a conversation over the pricing aspect.

For a specific example of how I use CircleCI  for deployments in my projects, I utilize it for continuous integration and automation to have the builds. I create YAML pipelines with it, and we first have some steps such as installing Node if it is a front-end build or installing the dependencies. After that, I build the project. Following the build, I deploy it on AWS  Elastic Container Service of the image. After the image is deployed, I deploy that image on the running EC2 , either in EC2  or within the S3  bucket. Then, the environment is ready, and I run the tests against that environment.

Additionally, I use CircleCI for insights and dashboards, doing some dashboarding and monitoring the results, duration, and how the runs have been, including the output and generation of reports or sending notifications to email addresses. I also connect it with Azure DevOps  and GitHub .

Among those features, I find the most valuable in my day-to-day work the automation aspect, as we have a large product team with many developers who continuously create branches and push code, necessitating automation that builds the pipeline and the branches automatically while giving faster feedback. There is speed, flexibility, and intelligent pipeline orchestration possible with CircleCI, which we appreciate. Additionally, we have hooks and can run tasks on commit or push, which allows executions based on those events, and the self-hosted runners to run jobs on our infrastructure or use provided agents by CircleCI itself are also beneficial.

CircleCI has positively impacted my organization by bringing in faster deployments, which means we can release faster, receive quicker feedback, and enhance collaboration and communication across the entire team. We benefit from really good dashboards, build performance analytics, and optimization of resources, which allows for multiple containers or virtual machines, significantly reducing build time. Additionally, the security and vulnerability scanning provided out of the box helps tremendously, as we just need to push the code and everything is managed by our CircleCI YAML scripts.

I believe CircleCI should leverage the growing trend of AI by offering an out-of-the-box AI-driven dynamic YAML file creation feature using natural language processing. Instead of having users define pipelines manually, users could simply use natural language to define their needs and let the AI generate the YAML configuration automatically. Implementing a multi-agent architecture could also enhance usability.

I rated CircleCI six out of ten because I think they need more transparency in pricing, as there are instances of unclear network data transfer and storage costs related to caching and workspaces. Additionally, there are sporadic platform security incidents that need addressing, and pipelines require good protection. Secret rotation should also be prioritized. There are occasionally long-running workflows that can be difficult to debug, and improvements could be made in job startup times and cache management.

To ensure that security and compliance requirements are met while using CircleCI, we utilize restricted contexts for secrets along with short-lived credentials. We follow some regulatory guidelines, ensuring that every job runs in an isolated environment, either in a Docker  container or a virtual machine. Furthermore, we maintain secret rotation and use secure API tokens while implementing appropriate access controls.

I rate this product six out of ten.