CircleCI - Cloud-Hosted CICD - FREE TRIAL

My main use case for CircleCI  is primarily for the CI/CD pipeline.

I have used CircleCI  for my enterprise project, which has a very large code base with both monolithic code and microservices code. All of the code that we have incorporates extensive automation with respect to testing, including development testing such as unit testing, integration testing, and API automation testing. I have also used it for deployment-related code, infrastructure creation, and for building the code and the repository.

I am also using some of the AI features that CircleCI has, more specifically for validating what I am doing, asking the chat AI bot for configuration and running tests, fixing any tests, or checking the pull request for review purposes, which is also helping in that respect.

The best feature that CircleCI offers, in my opinion, is the AI bot called Chunk, which I think is the best feature right now, along with other really good features that CircleCI has.

The Chunk agent, which is essentially an AI chatbot, helps me in my daily workflow by allowing me to create different kinds of tasks for it. For example, if I want to make some changes in my existing code, I can give it a prompt, and it executes that for me. If there is a bug in my code, I can ask Chunk to fix it, and it does that based on the instructions I give. It is a very good AI service that automatically updates and assists me with live coding and AI-assisted coding, checking the pull request for potential review comments as well.

CircleCI has positively impacted my organization significantly, as it generates a lot of code very fast, saving a lot of time in what was otherwise a long process of understanding requirements and manually writing the code and unit tests. With CircleCI, a lot of the code creation, including unit tests and integration tests, is now automated, and it helps with the CI/CD process by providing insight into failures and their causes. This overall reduction has saved a lot of time and money in development, testing, and related activities.

CircleCI could be improved by enhancing the AI-generated pipeline, possibly with a self-optimizing CI/CD feature since it currently requires a lot of manual configuration. The failure diagnosis is also not very automated, so an automatically provided diagnosis for issues such as dependency mismatches or memory problems would be helpful. Furthermore, I have not observed much Kubernetes-related integration, such as GitOps integration or Helm automation, and the security-related automations could also be better, possibly with integration with GitHub Advanced Security .

I have been using CircleCI for almost five years.

CircleCI is stable.

CircleCI's scalability is very good.

The customer support I have experienced so far is good.

Previously, we were on Jenkins , which is not very cloud-native and requires extensive configuration, making it less efficient for our needs.

We chose a plan called Performance for our engineering team after using it initially for free for evaluation purposes, and we also utilized some free credits.

We have seen almost a thirty percent saving in development time.

I purchased CircleCI through the AWS Marketplace .

Before choosing CircleCI, we evaluated options such as GitHub Actions  and AWS  CI/CD, CodePipeline .

For others looking into using CircleCI, I would say it is a very cloud-native model that has all the capabilities any leading CI/CD or DevOps product would have, along with strong AI capabilities.

Regarding CircleCI's AI capabilities, I think its accuracy and reliability of output are good, as I mentioned with Chunk's capabilities. The AI in DevOps seems to be a future direction worth looking forward to, and Chunk's validations, coding capabilities, and how it proactively addresses issues are helpful.

I would rate the customer support an eight out of ten.

I chose a review rating of seven out of ten because of all the areas of improvement I just mentioned, especially regarding AI automation, live coding, and AI engineering, which are prevalent today with solutions such as GitHub  Copilot or Codex, providing intuitive help with code generation.

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 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.

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.