CircleCI - Cloud-Hosted CICD - ANNUAL PLAN

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.