CircleCI Reviews

In my organization, particularly as I am in the telecom sector at Ericsson, CircleCI is primarily used as a continuous integration and continuous deployment tool because we use this to automate our software delivery lifecycles. This includes automatically triggered builds whenever code is pushed to the repository. It also ensures that all new code changes are continuously integrated and validated. We also use CircleCI for continuous testing, such as the different layers of testing including unit tests, integration tests, and sometimes regression test suites. CircleCI is also used for deployment automation. Orchestration is also an important part nowadays because it allows us to define workflows where different jobs are executed in a sequence or in parallel.

I have significant experience with CircleCI. I will emphasize one of my latest experiences which occurred in one of our recent projects in our particular domain. We used CircleCI to automate the build, test, and deployment of a microservice-based application. Whenever we pushed code to the Git repository, it automatically triggered a pipeline that built the application using Gradle for Java services and then executed unit and integration tests. After the successful testing, it built a perfect Docker image and then the image was pushed to the container registry. Then finally, the service got deployed to a Kubernetes staging environment. We also configured approval steps, so production deployment only happened after manual validation. This reduced the manual efforts, improved deployment consistency, and helped us release new features much faster with fewer errors.

CircleCI offers many features. If I need to emphasize some points, then it will be the easy CI/CD pipeline configuration because it uses simple YAML-based configuration with the config.yml file, and it makes it easy to define and manage pipelines. It also has powerful workflow orchestration because it allows creating complex workflows with sequential and parallel job execution, which enables efficient pipeline design. It also integrates smoothly with Git repositories, Docker, Kubernetes, and other DevOps tools, which makes it flexible for different environments. The native support for Docker makes it easy to build, test, and deploy containerized applications.

The feature that has made the biggest difference in my day-to-day work is Docker and container support. Native support for Docker makes it easier to build, test, and deploy containerized applications throughout our organizational projects.

Another feature that really impressed me is the security and access control. It provided environmental variables, secrets management, and role-based access to secure pipelines.

Debugging is an important point for improvement because when pipelines fail, debugging can sometimes be difficult, especially for the complex workflows which we have already faced in our organization in different projects. Logs are available, but root cause analysis can take time, so that can be improved. Also, configuration management challenges exist. Although YAML configuration is flexible, it can become complex and hard to maintain as pipelines grow in size and include multiple workflow conditions. The limited visibility for large pipelines is also a concern. For very large enterprise pipelines, the UI can feel less intuitive in terms of tracking dependencies and understanding the full workflow at a glance.

Cost optimization is one important point for improvement. In cloud-based usage, costs can increase due to long-running jobs and inefficient pipelines. Proper optimization through caching and parallelism is required, otherwise it can become expensive, which we faced in one of our telecom projects last year.

One thing CircleCI can improve is related to cloud runners, where any network or platform issues can impact pipeline execution. This can be a concern for critical telecom deployments.

I have been working almost five years in my current field.

CircleCI seems balanced most of the time. Overall, CircleCI has been stable and reliable for our needs at Ericsson in different telecom projects. For our day-to-day CI/CD operations, the platform performs consistently well, and most pipelines run without issues. We have been able to depend on it for critical build and deployment workflows, especially in automated environments.

Sometimes downtime or issues are observed. There have been occasional minor outages or slowdowns, which is expected with any cloud-based SaaS platform. Sometimes we notice delays in job execution or queue times, especially during peak usage. Rarely, external factors such as network or integration issues have impacted pipeline execution, but these are manageable.

CircleCI has scaled well with our needs at Ericsson as our projects and teams grew. One of the key points is easy horizontal scaling because as the number of repositories and services increased, CircleCI was able to handle multiple pipelines simultaneously. We could run jobs in parallel without major performance bottlenecks.

The support for microservices is also notable. With the shift toward microservices, the number of builds and deployments increased significantly, and CircleCI handled that well by allowing independent pipelines per service, improving efficiency and isolation. The built-in support for parallel job execution helped reduce pipeline execution time even as workloads increased.

We faced some challenges, such as increased costs with higher usage, requiring optimization, and pipeline complexity grew, making maintenance more challenging. But that also can be managed because CircleCI scaled effectively with our growth but required proper pipeline design, cost management, and governance to maintain efficiency.

Our experience with CircleCI's customer support has been positive. For technical issues such as pipeline failures, configuration errors, or integration queries, support responses were reasonably quick and helpful. The documentation and community resources also helped resolve many issues without direct support intervention. CircleCI provides detailed documentation, which often allowed us to troubleshoot and resolve problems independently. Overall, support has been reliable for most scenarios, though response times can vary for complex enterprise issues.

Before adopting CircleCI, we had experience with traditional CI/CD tools. We used Jenkins. It was highly flexible and widely used in enterprise environments, and it supported a large number of plugins. However, while using Jenkins, we faced some challenges, such as high-maintenance effort. Also, the pipelines were sometimes hard to standardize and maintain. It required dedicated effort for infrastructure management, which generally resulted in a slower setup for new projects.

After that, we explored CircleCI. The reasons we switched to CircleCI include that it has a managed SaaS platform. CircleCI reduced the need to manage the infrastructure, unlike Jenkins. Also, the faster setup and simplicity of YAML-based configuration made pipelines easier to define and replicate. Better scalability is also one of the most important key parts. Features such as workflows, orbs, and Docker support made it more aligned with microservices and container-based architecture.

Adopting CircleCI initially was moderately easy, especially for teams already familiar with CI/CD concepts. In our project at Ericsson, for basic use cases such as build and test automation, the setup was quite straightforward because CircleCI integrated easily with Git repositories. Getting the first pipeline running took minimal effort. The YAML-based configuration, the config.yml file, was easy to understand at a basic level, which helped us get started quickly.

We faced some challenges. As we moved to more complex pipelines with multiple workflow conditions and conditional jobs, the configuration became more intricate. Understanding advanced features such as orbs, caching, and parallelism required some learning and hands-on experience. Overall, CircleCI's initial setup is quite good.

We have seen a clear return on investment from using CircleCI at Ericsson, both in terms of efficiency and quality. It reduced the deployment time. Earlier, deployments could take hours with manual steps. With CircleCI, this is reduced to 30 to 40 minutes depending on the pipeline size. A 60 to 70% improvement in release time was observed.

The deployment frequency increased a lot because it moved from weekly or ad-hoc releases to multiple deployments per week, even daily in some cases when we do multiple integrations. Faster delivery of features and fixes is an important point in terms of customer view.

Reduction in manual effort also happened because a significant drop in manual intervention for build, test, or deploy has been observed. In our organization, it resulted in approximately 15 to 20% cost savings. Also, faster issue detection has been observed. The MTTR improvement, reduced mean time to resolution, is also an important KPI that we can show to our customers to get more projects.

Before adopting CircleCI, we did evaluate other CI/CD tools to ensure we selected the best fit for our requirements at Ericsson. Some of the tools we considered were Jenkins, GitHub Actions, and GitLab CI/CD. The evaluation criteria were all about the ease of setup and maintenance, scalability for enterprise workloads, integration with existing tools which we already have in our projects such as Git, Docker, and Kubernetes, and also the performance and pipeline speed.

CircleCI was chosen because of its easy usage, managed SaaS platform, performance-based features, scalability, modern features, and flexibility. It has a great ability to scale pipelines easily.

I would advise organizations or individual developers who are trying to use CircleCI to begin with basic pipelines and gradually move to advanced workflows such as deployment automation, parallel jobs, and approvals. You should avoid overcomplicating from day one. You need to plan workflows properly, use caching, parallelism, and reusable components to optimize performance and reduce execution time. Since CircleCI uses a usage-based pricing model, you should regularly monitor pipeline usage and optimize long-running or unnecessary jobs.

I rate CircleCI an eight out of ten because I think some points can be improved, such as better debugging and error insights, a more intuitive UI for complex workflows, and enhanced cost visibility and optimization recommendations.

I have been using CircleCI for around one year in my recent projects. During that time, I used it regularly for automated test execution, build validation, and supporting release pipelines. It became part of our day-to-day workflow, especially for sanity suites and regression testing, and continuous integration activities.

In one of my projects, I use CircleCI whenever developers push new code to the repository. It automatically triggers the build and runs our smoke suites and regression test suites, then generates the test reports. My role is to monitor failed jobs, analyze whether failures are due to code issues, flaky tests, or UI failures, and help optimize the test pipeline so feedback reaches developers quickly. This helps catch defects earlier before they move to higher environments, optimizing our speed and quality of the builds going for deployments.

CircleCI fits majorly in the CI/CD pipelines part and is an important part of our delivery workflow because it creates a common checkpoint for developers, testers, and DevOps teams. Before any code moves forward, an automated check must pass, improving the release confidence. It also creates a process, and process is what makes deployments easier and generates confidence in the builds. It also reduces manual coordination between teams since build, test, and notifications are automated powerfully through CircleCI. For our team, it helps maintain consistency, faster feedback cycles, and confident releases, especially when multiple code changes happen in parallel.

One of the best features CircleCI offers is its automation capability. Whenever code is pushed, it can automatically trigger builds, run test suites, and provide quick feedback without manual intervention, helping our team catch issues early and maintain faster release cycles. Another feature I think of is parallel test execution, which we used to split regression suites across multiple environments such as staging, interop, beta, and production. Testing these across particular environments usually took considerable time, but by using CircleCI, it significantly reduced the execution time and helped us deliver faster feedback to developers across these environments.

Using parallel execution made a significant difference in our workflow because earlier, the full regression suite took considerable time when tests ran sequentially. With multiple environments for testing, after using parallel execution, we divided the test suite across multiple containers, allowing several tests to run simultaneously. This reduced the overall execution time significantly and helped us get feedback much faster. Developers did not have to wait extensively for test results, and blockers were identified earlier. Our team could support more frequent releases with better efficiency, which is a core competency of a good QA.

One more feature in CircleCI that comes to mind is the reliability and visibility it provides. It is easy for the team to track build status, test failures, and logs from one place, saving time during debugging. I appreciated how pipeline configurations are maintained as code because it makes changes more structured and easier to manage across environments. Overall, beyond speed, it helps bring better consistency and transparency and confidence to the overall release process.

CircleCI has positively impacted my organization in terms of speed, quality, and team efficiency. It reduced the time taken for build validation and regression testing because many checks are automated, smoothing the release process. When code is pushed, CircleCI runs smoke testing and regression suites, helping us release updates faster without compromising quality. It also improved defect detection early in the cycle, minimizing issues reaching staging or production environments and reducing production tickets. Regression execution time has improved by approximately 40 to 45 percent after starting to use CircleCI, keeping in mind the parallel execution. Earlier, full regression cycles took several hours when tests ran sequentially, but once we started splitting suites across multiple executors, the test results came much faster. For release cycles, overall turnaround time has improved by approximately 25 to 30 percent because builds, automated validations, and feedback loops became faster. This meant developers got quicker responses, fixes happened sooner, deployments moved more smoothly, and products have been deployed before release dates.

One limitation I see in CircleCI is the troubleshooting of complex pipeline failures, which sometimes takes time, especially when multiple jobs or containers are involved. More intelligent root cause insights would be helpful. The configuration experience often depends on YAML setup, which feels more technical for new users not from the DevOps team. A more guided visual pipeline builder would ease onboarding. I also feel that deeper flaky test analytics would add value because quickly identifying unstable tests versus actual product defects is important for QA teams.

Integrations are generally strong, but sometimes teams need more plug-and-play connectors for niche tools or simpler setup steps for third-party testing platforms. Making those integrations more seamless would save onboarding time. The technical content in documentation is useful, but in some advanced scenarios, it can take time to find exact solutions. Including troubleshooting guides or real-world examples would be helpful. Regarding support, faster resolution for urgent pipeline blockers is always valuable, especially when builds impact release timelines.

I have been working in the same field for 3.5 years.

In my experience, CircleCI is stable overall. It is dependable for day-to-day CI/CD operations, and most of our builds, test runs, and scheduled pipelines execute consistently without major issues. Public status reporting also shows high uptime across services, reflecting a generally reliable platform.

CircleCI scales effectively, which is one reason it works for growing engineering teams in our organization. As project demand increases, we can handle more builds, parallel test executions, and multiple pipelines running simultaneously without needing to manage extra internal infrastructure.

I have limited experience with customer support, but I have heard they are proactive in solving issues. I have seen this happening with a separate team but have not had direct communication with customer support.

Before CircleCI, we used traditional CI setups, mainly Jenkins-based workflows. While Jenkins is powerful and flexible, it required more maintenance, plugin management, and administration effort. We moved to CircleCI because we wanted a more streamlined, cloud-based solution with faster setup, easier scalability, and less operational overhead.

In our organization, CircleCI is primarily deployed as a public cloud solution. We use the hosted SaaS model, which reduces infrastructure maintenance and allows us to scale pipelines based on demand.

For our CircleCI setup, since we are using the hosted SaaS version, the underlying infrastructure is managed by CircleCI. We mainly interact with the CircleCI cloud platform itself rather than directly managing the hosting layer.

The return on investment with CircleCI is strong. The biggest ROI comes from time savings, reduced manual effort, and faster release cycles. By automating builds, smoke tests, and regression checks, the team spends less time on repetitive tasks and more time on high-value testing. Earlier defect detection also contributes to ROI because catching issues during the CI stage is much cheaper and faster than finding them in staging or production.

I am not directly involved in pricing, setup cost, and licensing discussions since my manager handles those aspects. I do not have details about the pricing or setup costs that are required.

I was not involved in evaluating options before choosing CircleCI, so I have not had discussions with decision-makers. CircleCI was provided for me to use.

I rate CircleCI 8 out of 10 overall. It is a reliable and efficient CI/CD platform that significantly helps with automation, faster feedback, and improved release quality. It has strong capabilities such as parallel execution, integration, and scalable pipelines. I give it an 8 because there is still room for improvement in areas such as easier onboarding and smarter debugging.

I specifically chose 8 because the onboarding steps can be easier. Some areas still feel they can be more refined in day-to-day usage. For example, I once spent considerable time debugging failed pipelines longer than expected. For CircleCI to become a 9 or 10, I would appreciate more intelligent troubleshooting, simpler pipeline setup for new users, stronger analytics around test stability, and if they can provide some trends or a graphical interface, it would help significantly.

My advice is that it is easier to use CircleCI than traditional Jenkins. If anyone wants to simplify their pipelines, choosing CircleCI instead of overloading with Jenkins would be a smart move.

In summary, I have shared much about CircleCI according to my experience. I feel it is a faster tool compared to traditional Jenkins, and as a QA, I feel more tech-aligned and product quality-aligned using CircleCI. My overall review rating for CircleCI is 8 out of 10.

I have used CircleCI for my organization's website to build an automation pipeline for deploying our code from GitHub to our environment.

We integrated our environment variables into CircleCI, which get injected into our code. Whenever there is a new commit into our main branch, it triggers an action which CircleCI listens to. CircleCI builds our application in the background, injecting the environment variables which we have provided. After the bundle is created successfully, it deploys to an AWS EC2 instance. If there is a failure, it sends a notification to our Slack.

Automation and continuous integration is one of the best aspects I appreciate. The development process is smooth in terms of its integration. CircleCI can integrate with GitHub, Bitbucket, and other repositories, which makes it incredibly powerful and an amazing tool to work with.

Previously, we had the entire pipeline using a manual process. Whenever there was a deployment, we had to call our DevOps team to trigger and deploy the build and verify it. If there was a failure, we were notified manually. Now everything has been automated from the code in our repository to the environment. If there are any issues or successes, we get notifications to Slack, which is remarkable.

It saves a lot of time and works fast once the setup is done. The pipeline is created once and then it is available indefinitely unless specific modifications are needed. We receive notifications quickly regarding the previous build status, logs, and what failed or succeeded. This completely eliminates the manual effort of deploying our application from our GitHub repository to the EC2 instance on AWS.

As each time code is deployed onto the main branch, the build automatically triggers, saving us time. We have reduced our manual efforts significantly after the initial setup. We used to spend around four to five hours per week managing deployments and related processes, which has been reduced substantially.

CircleCI is fairly simple to use and set up. Sometimes the documentation is too in-depth. There are many features, but I think sharing the top ones would help end users set it up more quickly and efficiently. Simpler documentation and implementation highlighting the top features instead of presenting a huge bulk of information would make the experience perfect.

I have been using CircleCI for the last two years.

CircleCI is very stable and performs amazingly fast.

CircleCI is great in terms of scalability. It can integrate with multiple platforms and also with many multiple notification systems.

Customer support is amazing. Whenever we have had issues with initial setup or questions, both the customer support and technical support teams have been excellent.

We used Jenkins earlier and it seemed difficult in terms of integration. The UI was outdated. We had to switch from older systems to new ones, and CircleCI emerged as one of the best options to integrate.

CircleCI was recommended and we knew it was effective. Jenkins is what we switched from.

CircleCI is fairly simple to use and set up.

I did not directly interact with all those processes, but from what I hear from the team and the sales team, the implementation has been smooth. CircleCI is very cost-effective, so it was a great choice.

Time has certainly been saved in terms of reducing the manual effort of building and deploying. Regarding money, CircleCI came at a lower price than the products we had earlier. However, I do not have specific metrics because the sales team and purchase team handled that matter. As a developer, I did not go through the licensing and purchasing process.

CircleCI is an amazing tool. It is fast, modern, and integrates with most systems, whether repositories or notification systems.

CircleCI is a very powerful tool and you should at least try it once to see how powerful, amazing, and fast it is.

I believe CircleCI is one of the best platforms in its category due to how amazing, fast, and scalable it is.

This review process represents one of the most modern technical ways of gathering feedback. I gave this product a rating of nine out of ten.

My main use cases for CircleCI include automated testing, CI, continuous development, mobile app development, microservices orchestrations, and DevSecOps use cases.

We use CircleCI to build and deploy microservices on Kubernetes and OpenShift platforms, where we run unit tests, integration tests, and linting on every commit as part of our CI process. We also use it for continuous deployment, automating the deployment to different platforms such as AWS, GCP, Azure, as well as Kubernetes clusters.

For our primary use case with CircleCI, we handle complex pipelines with multiple repositories and dependencies in microservice orchestrations.

The best features CircleCI offers are its ease of use, YAML-based configuration, maintenance-free operation as a software as a service platform, and good speed.

The YAML configuration and maintenance-free setup in CircleCI help me daily because it uses a very straightforward YAML-based configuration, allowing us not to worry about other programming languages, and it has a very low entry barrier, making it helpful for all developers.

CircleCI helps with faster time to market and improved productivity by automating testing and deployments, which allows for frequent and reliable software releases and application deployments. From a developer productivity point of view, developers spend much less time on build troubleshooting and more time writing code due to its very simple YAML language, which is a human-readable language.

CircleCI has positively impacted my organization with faster time to market, improved software quality, cost efficiency, and increased developer productivity.

To improve CircleCI, I think some layers of optimized caching need to be implemented, it can monitor credit usage, and use insights for improvement to increase value.

I chose an 8.5 for my rating because there are still many areas that need to be increased and improved, such as leveraging orbs and replacing custom, complex scripts with pre-built, community-verified orbs to reduce maintenance overhead.

I have been using CircleCI for the last four years.

CircleCI is very stable.

From a scalability point of view, CircleCI allows us to easily configure active and passive clusters, making it very good in terms of scalability.

Customer support for CircleCI is very good.

I have seen a return on investment with CircleCI, as it saves money and time, requires fewer employees because it automates deployments easily, and enables us to complete all development tasks in much less time with limited employees.

My experience with CircleCI's pricing, setup cost, and licensing is very good.

We use CircleCI from scratch, but side-by-side we are also using Jenkins and Argo CD.

My advice for others looking into using CircleCI is that if anyone is using it for their CI/CD needs and wants good performance, they should definitely use CircleCI. I gave this product a rating of 8.5 based on my overall experience.

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.

Positive

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.

My main use case for CircleCI is automated software delivery. When we push code to a repository, CircleCI builds the application, runs the tests, and deploys the code to a staging or production environment. This is the only use case we have for CircleCI.

The best feature CircleCI offers is orbs, which are reusable configuration packages that can be reused. Instead of writing hundreds of lines of code to connect to AWS, we just use an orb for that and provide the correct information there. Aside from that, I appreciate the caching on the Docker layer. CircleCI is built for Docker, which we use, and this cache speeds up build times because it only rebuilds parts of the Docker images that actually changed.

Orbs allow us to not reinvent the wheel, and there are many existing orbs in the registry, so we usually check that before writing our own scripts. I also value SSH debugging, because when the build fails, I can SSH into the container to see exactly what went wrong. This saves us hours of guesswork.

CircleCI has positively impacted our organization by allowing us to improve our workflow and making parts of DevOps easier. It has made the application better by augmenting our speed of software delivery. We are faster to market, and it is easier to test on the UAT environment and later in production. CircleCI ensures that the code is of higher quality because we can apply tests, run static code analyzers, and catch bugs before they reach the customer. It also removes the boring parts of software engineering, allowing developers to focus on what matters—building things instead of working on routine tasks.

The pricing could be improved as it is pretty complex. There is a credit system, but it is hard to predict how much money you will actually pay for the use. It takes some time to predict, and it can get expensive quickly if it is not monitored. I think there is also UI clutter; with very complex pipelines running with hundreds of steps, it becomes difficult to navigate in the web interface.

I have been using CircleCI for four years since I joined my company.

CircleCI is stable and we have not had any issues with it. We are using this software as a service solution, and if it goes down, the whole engineering stops working almost—we cannot push anything, and building does not work at all. I am sure they have very high uptime because I do not recall us ever running into this issue. CircleCI is pretty stable.

In the cloud version, CircleCI allows you to go from running one job to 1,000 jobs instantly, so it is very robust. CircleCI handles the bursts of infrastructure perfectly. You just set up some rules, and it works.

At my company, we do not use a different solution because that is what we have. We also have the alternative SVN, which I do not prefer, or SVN with Jenkins, which I also do not prefer. However, I have used GitHub Actions and Azure DevOps pipelines, and both were also quite nice.

The metrics I can share are about cost per build and developer wait time. Build times are much faster now and run faster than other pipelines. For example, if our team of developers waits 20 minutes for a build three times a day, that saves us one hour per worker. With five workers in the team, we save five hours a day, and that is a lot of money because software developers earn significant salaries. CircleCI pays itself off because of that. It also has a credit system, so you pay for what you use, making it way cheaper than having a dedicated server running 24/7. It is only built for use, which is beneficial.

My experience with pricing, setup cost, and licensing feels like a utility bill, similar to electricity. You buy a bundle of credits, and different machine sizes consume credits at different rates. For example, a large server costs more credits per minute than a small one, but there is a risk that some scripts or an infinite loop can burn through $500 of credit in a weekend if you do not set up spending limits or alerts.

I evaluated other options before choosing CircleCI, including GitHub Actions and Jenkins, which we have also deployed.

I would advise others looking into using CircleCI to optimize YAML files. It is good to spend some time learning how to use caching and workspaces early on. If not used from the beginning, you will waste a lot of money on redundant credits. Use orbs, and do not reinvent the wheel. If something is already available, there is no need to do it from scratch, especially for AWS or integrations with Slack. Set up monitoring for credits by setting up mail alerts when it reaches 90% of your credit limit, so you are not surprised by the bill. Consider starting with the free tier, and once you reach the limit, update to a paid plan.

CircleCI is a leading continuous integration and delivery platform, and I would really recommend it. I consider it a gold standard for DevOps, especially if you prioritize speed. I would rate this product a nine out of ten.

My main use case for CircleCI is for our CI/CD platform, where we are automating our builds and then testing and deploying.

A specific example of how I use CircleCI in my workflow involves our test automation framework built in various tools like Playwright, where we are using CircleCI for building our releases integrated with GitHub and using it as an integrated environment. As soon as the final check-in is done, we are automating the building of the release and then deploying it and getting the test results.

This is the main use case for CircleCI that I would like to add.

The best features CircleCI offers include the ability to configure your configurations in config.yml, which helps make it variable-driven, allowing you to set your configuration at runtime. Being a SaaS tool, it allows us to use it on the cloud, making it easy to maintain. Its integration with GitHub and GitLab is very useful.

Integration stands out the most in my day-to-day work because it helps in building pipelines and workflows. Based on our product configuration, we have defined a few workflows, making it very easy to build, deploy, and test the application and get results much faster. It is integrated with different tools from our test automation perspective, such as a test management tool like TestRail, Jira for ticket tracking, and integration with GitHub, which are all really helpful.

CircleCI has positively impacted my organization by helping integrate across different projects and aiding in the building of pipelines that help us do validation quickly. With large integrations, we can use multiple products easily, and working on the cloud allows us to use the application from anywhere, which aids our distributed teams to access the application, do integrations quickly, and get results in a shorter duration.

I would suggest some advancement around AI, integrating it with CircleCI, as I see some initial changes happening, but it could help with Agentic AI workflows, allowing us to build our Agentic workflows within and with CircleCI, which would be really helpful as most applications are focusing on Agentic AI.

More features and usability around Agentic AI would be really helpful, but otherwise, things are good. I do not have anything else to mention as an improvement needed for CircleCI.

I have been working in my current field for 20 years.

CircleCI is stable.

CircleCI's scalability is good as we are able to upgrade and scale multiple projects as needed.

Customer support is good. Although we were not required to reach out much, whenever we did, the support team was very helpful.

Previously, we were using Jenkins for CI/CD, but we moved to CircleCI for optimization purposes, although there were no specific areas. We just wanted to try another tool, and CircleCI has proven useful with its integration features.

My experience with pricing, setup cost, and licensing is that they are fine. So far, we have been able to keep everything within our organization's budget.

We are a partner of CircleCI rather than just being a customer.

I have seen a return on investment demonstrated by a reduction in the overall development cycle and with faster build and deployments that allow us to execute multiple builds over time, which saves on overall cost and deployment cycle. Also, with the managed cloud, we save a lot on infrastructure costs, environment setups, and their management, making it very efficient. From a productivity standpoint, we have seen a 10 to 15% gain.

My experience with pricing, setup cost, and licensing is that they are fine. So far, we have been able to keep everything within our organization's budget.

We did not evaluate many options before choosing CircleCI but tried Jenkins and CircleCI for a while before moving to CircleCI.

I would rate CircleCI a nine out of ten.

I pick nine out of ten because most of the things are already there. It is very easy to use, easy to configure, integrations are available, and most of the time, most of the features are user-friendly.

For others looking into using CircleCI, I would advise they can definitely use CircleCI for CI/CD purposes, potentially doing a POC, identifying their use cases, and checking the integration features, which is a significant advantage. If everything goes well, they can try using CircleCI for their production environment.

We are using CircleCI on the cloud. My overall rating for this review is nine.

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.

I use CircleCI for my client at an organization where I work with multiple clients, and one of them is using CircleCI. I have a DevOps profile and work in an environment where I create modules in TerraForm and write playbooks and roles. For CircleCI, I create pipelines to automate these processes.

CircleCI is remarkably smooth, and I have not experienced any lag. I have used other tools such as GitHub Actions and Azure pipelines for various clients. In comparison to Azure pipelines, CircleCI is equal, and these two tools appear similar.

From my experience with CircleCI, I have not encountered any issues, so I am uncertain how I could suggest improvements. Since CircleCI is a SaaS-based service, installation is not required. We purchase the subscription and are ready to proceed. We are not responsible for the purchase because this is a client environment, and our responsibility is limited to maintaining the code, running the pipelines, and reviewing the pipelines.

The benefit I see from using CircleCI is that we work in a smooth environment, so everything functions well. From the client's perspective, CircleCI appears to be cost-effective, which is likely why they have chosen it.

Regarding flexibility, Azure pipelines has the ability to pass variables with greater flexibility than CircleCI offers. CircleCI has this feature, but the flexibility in Azure pipelines is something CircleCI does not match. We pass runtime values such as secrets or API values, and this capability could be improved.

I have been working with CircleCI for approximately four and a half years.

Because I have been using CircleCI for an extended period, I find it smooth with no issues regarding stability and reliability. It is most important for CircleCI to be stable and reliable because we run a production environment on it, making stability crucial. A stable environment for CircleCI is essential because it is used in a production environment as well.

CircleCI is scalable as I run different environments. I operate a small environment such as QA and a dev environment that is not large. For production, I have used a mid-level setup managing approximately one thousand servers across different categories, including some for Windows patching, some for Linux patching, and some for Ansible playbooks and TerraForm modules. Everything works together, and it is very scalable and performs well.

I have not communicated with CircleCI technical support because this is a client environment, and we do not have full access. If we face technical issues, we do not troubleshoot from our end; we contact the client and ask them to raise a ticket because they have their own owner who handles that.

I always follow the official documentation provided for CircleCI, and it is comprehensive. CircleCI's official documentation is sufficient and covers everything I need. As I mentioned, we are only users of CircleCI, so I am uncertain how to describe the specific benefits for the customer's organization in their environment. I have provided this review with a rating of 8.

We use CircleCI for CI/CD purposes, which involves continuous integration and deployment, including the integration of code in GitHub and deployment to the cloud.

We set up a pipeline for CI/CD by configuring a CircleCI configuration file with all necessary instructions for the code. CircleCI triggers and builds the code, and we use containerized applications, so it builds the Docker container, tests the test cases, and deploys to the AWS cloud. Everything is configured in the configuration file.

We configure the pipeline according to developer requirements for various branches such as prod, dev, and staging branches, as the main use case is for that purpose. We have automated all dev and staging environments with CircleCI, making it easy for testing and deployment to the cloud. For prod, we sometimes need manual intervention. Developers can easily integrate code and see changes without any manual intervention from DevOps or cloud platform engineers, as we write a configuration file that automates everything.

Traditionally, engineers used to manually integrate code into GitHub, after which the team would pull the code on the server and start the application. With CI/CD from CircleCI, we have eliminated those steps. We only push the code and the deployment is done, which is a very positive feature and automation for engineers.

CircleCI stands out by giving developers the opportunity to see changes easily, where the build, test, and deployment processes are automated once the code is pushed. This automation benefits DevOps engineers, cloud platform engineers, and developers alike, taking everything to a new level in the pre-deployment stage without requiring manual intervention. You only need to write the configuration file for CircleCI and everything gets done.

The deployment process has become significantly faster compared to traditional practices, where developers had to notify the DevOps team to pull the code before building, testing, and deploying. The whole process has been cut down, allowing developers to push code directly and have the deployment completed, increasing the speed by 100x.

Overall, everything about CircleCI is functioning with good automation, structure, and workflow of the build, run, test, and deploy processes.

Sometimes the application is complex, making the configuration file also complex to write for integrating everything on how to build, test, and deploy. This complexity can make debugging challenging if the build fails. However, when the configuration file is properly set up, tested, and working, it becomes excellent automation for the team, enabling them to monitor if the pipeline is successful.

I find that the plans for CircleCI become very expensive for large teams and pipelines, making it somewhat unaffordable for startup companies. I think there should be more suitable plans for them.

Pricing could be improved for startup companies, and the complexity of configuration files is a downside.

After using it for ten months

CircleCI is stable at this time in my experience.

CircleCI handles scalability well, accommodating increased workloads effectively, which has made it a great choice for our team.

I have experienced very good documentation and integrations, which have been helpful. The support team is also commendable, as one of my managers had a good conversation with them regarding support.

Although I have not interacted directly with CircleCI's customer support, I have heard positive feedback about their responsiveness from the documentation and integration assistance that my manager has received. It has been supportive.

Prior to CircleCI, we used GitLab CI/CD but switched because CircleCI provides a better workflow for building, testing, and deploying. GitLab's configuration was more complex, particularly for Kubernetes containerization applications.

The integration process is very simple to understand, and the user experience is also pleasant, making it easy to work with and set up CI/CD workflows.

We did not purchase CircleCI through the AWS Marketplace. We integrated it according to the provided documentation.

There has been a significant return on investment with CircleCI, as it has decreased the number of developers involved in deployment from two to three, which reduces costs and saves time by 100x due to the elimination of manual intervention.

The pricing varies depending on how we use the pipelines, which run frequently, leading to variability in costs. We find the pricing manageable overall.

I did not evaluate other options before choosing CircleCI because my manager directed us to use it and we integrated it without exploring alternatives.

I recommend using CircleCI because it has significantly reduced my workload, making it easier for DevOps engineers and cloud engineers to automate their tasks without manual intervention.

CircleCI has been a real benefit for my daily work, reducing my workload substantially, and I fully intend to keep using it. I gave this product a rating of eight.