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.

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.