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.
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.
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.
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.
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.
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.
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.
Managing Technical Consultant - Solution Architect at NTT DATA
Real User
Top 10
Jan 24, 2026
The main use case for CircleCI is to have build pipelines and to execute the pipelines, tests, and deployments while using it to get results and obtain a dashboard.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.
SRE coordinator at a financial services firm with 201-500 employees
Real User
Top 10
Dec 2, 2025
CircleCI is used primarily as the pipeline for application deployment. When a pull request is created in GitHub, it triggers a CircleCI pipeline because of the GitHub integration. During the CircleCI pipeline, the application goes through building and deployment to the appropriate destination, which can be a Lambda or AKS microservices.
Our use cases are very generic use cases, such as any kind of integration and pipeline code, the pipeline run, and any kind of information. We use the solution to send the information to the respective service owner via any channel. So, these are the generic features that everyone is using of CircleCI. Whatever business needs or requirements we have, CircleCI provides all those types. So, we are also integrating with our incident management tools. Integration is straightforward. For example, CircleCI integration to our GitLab pipeline and hardly takes five to ten minutes.
CircleCI is a continuous integration and delivery platform that automates software development, streamlining the process for engineers and developers. It's valued for its ability to enhance development speed while maintaining high software quality. Known for its robust CI/CD capabilities, CircleCI supports a wide range of programming languages and integrations, allowing teams to build and deploy code with efficiency and reliability. Its flexibility and automation features help teams quickly...
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.
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.
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.
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.
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.
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.
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 main use case for CircleCI is to have build pipelines and to execute the pipelines, tests, and deployments while using it to get results and obtain a dashboard.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.
CircleCI is used primarily as the pipeline for application deployment. When a pull request is created in GitHub, it triggers a CircleCI pipeline because of the GitHub integration. During the CircleCI pipeline, the application goes through building and deployment to the appropriate destination, which can be a Lambda or AKS microservices.
Our use cases are very generic use cases, such as any kind of integration and pipeline code, the pipeline run, and any kind of information. We use the solution to send the information to the respective service owner via any channel. So, these are the generic features that everyone is using of CircleCI. Whatever business needs or requirements we have, CircleCI provides all those types. So, we are also integrating with our incident management tools. Integration is straightforward. For example, CircleCI integration to our GitLab pipeline and hardly takes five to ten minutes.