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 creating a pipeline for continuous integration and continuous delivery, which is a CI/CD pipeline.

A specific example of how I use CircleCI for my pipelines is deploying infrastructures and applications for customers. I have also completed one integration project using CircleCI where I automated the customer onboarding process to remove manual effort.

In my opinion, the best features CircleCI offers include integrations with different tools such as GitHub and other version control tools, the ability to write or integrate your code with different platforms, the option to write your own testing, and the capability to create multi-staging pipelines and single-stage pipelines with jobs.

CircleCI's integration with GitHub and other platforms has helped my workflow by allowing me to integrate with CircleCI if my code is on GitHub or on different version control tools such as AWS GitHub or AWS version control tools. With the multi-stage pipeline, I can run my pipeline in a parallel manner, and for custom jobs, I can create and run ad-hoc jobs.

The multi-stage pipeline, custom job pipeline, and the integration with GitHub stand out most to me.

CircleCI has impacted my organization positively by removing most of our manual effort and human effort, increasing speed, and removing human error, which has improved our workflow, speed, and efficiency.

CircleCI can be improved with more integrations with different cloud platforms and by providing environment security features.

It could provide integration for secrets with Vault or other security tools.

I have been using CircleCI for one year.

In my experience, CircleCI is stable, but it can be improved.

CircleCI's scalability is increasing and growing well with our workloads.

I have not contacted customer support so far because we have not needed to.

Before, I was using Jenkins to see how it would perform, but CircleCI is more user-friendly and provides better structure and collaboration, which is why we chose CircleCI.

CircleCI compares favorably to other CI/CD tools I have used before, such as Jenkins or GitLab CI. Those tools are not as user-friendly, whereas CircleCI is user-friendly, good to use, and easy to use.

The learning curve for CircleCI was easy because it is user-friendly.

I have seen a return on investment as fewer employees are needed, and our time is saved.

Before we were using CircleCI, deploying and setting up architecture or deploying an application for our customers took one or two days, but using CircleCI, it only takes around half a day, so it has improved significantly.

My experience with pricing, setup cost, and licensing is that we are currently using the trial version and are considering purchasing another level of CircleCI, focusing on which tier would be best for our setup.

Before choosing CircleCI, I evaluated other options including Jenkins. CircleCI is a good solution, and after evaluating other internal options, we chose to use CircleCI.

My advice to others looking into using CircleCI is to use it if you want to collaborate with multiple teams and prefer structured, user-friendly solutions with more integrations with tools. CircleCI is a perfect solution for multi-staging and jobs. Regarding compliance or regulatory requirements in my organization, we are not currently focusing on that area, so I am not aware of those concerns. I would rate CircleCI an eight out of ten overall.

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.

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.