I use the solution for making pipelines. I use it for deployments and CI/CD to make applications as required. I push code on CodeCommit. With the help of CodeCommit, I trigger the code to build and implement. Then, it will be deployed in Kubernetes using ECR and EKS.
We use AWS CodePipeline for agent deployments, Kubernetes orchestrations, and Argo deployments. We integrate it with multiple applications in the DevOps pipeline for software compression analysis purposes.
We use the solution to deploy different applications and connect third-party APIs to various projects. I commonly use the Jenkins CI/CD pipeline. I've used it to set up servers. The architecture is very complex and needs a lot of connections, storage, security, and network. We need CodePipeline to complete these processes faster.
When you do the microservices, you can build from the source code and package it to the docker image. After that, you can deploy the docker image to the container which is also situated in the AWS CodePipeline.
Senior ict specialist at Information& eGov Authority
Real User
Top 5
2023-01-06T17:02:42Z
Jan 6, 2023
Our primary use case for CodePipeline is speeding up our development process. The solution is highly automated and allows us to build and deploy code without any effort. It's automatically initiated once I commit my code. CodePipeline also helps me to find bugs quickly, increasing my release speed. On the other hand, it helps our customers receive our releases regularly and incrementally. CodePipeline helps us out with our delivery and our customers are happy to see our results in real time through it. The solution is a continuous integration and delivery mechanism that helps us a lot in delivering our software. This is the most powerful benefit we get from using CodePipeline. It's one of those DevOps concepts recommended for use within the software development lifecycle.
Virtualization and Cloud Architect at a transportation company with 10,001+ employees
Real User
2021-08-18T16:05:27Z
Aug 18, 2021
We use CodePipeline for deploying some of the applications that we have for AWS. Ours is a multi-cloud hybrid cloud approach. We have Azure, AWS, Google Cloud, and then we use CI/CD pipelines - our core pipeline tools - from each cloud. For example, on Azure, we use Azure DevOps that integrates with our GitHub on-prem. That's what we use for deploying anything on Azure. The same GitHub. It is also used on Google Cloud. We don't use the native tools from any of the clouds. For example, the CodePipeline from AWS or Deployment Manager from Google Cloud. We try to avoid those. We are moving towards Terraform with a GitHub integration as of our source code repository or pipeline, CI/CD pipeline. No matter what the cloud, we use our on-prem resources. We try to avoid using the cloud.
Build automation tools automate the time-consuming tasks inherent in creating a “build,” or usable version of an application. They automate and orchestrate the sometimes complex processes of compiling computer source code into binary code and packaging that binary code as well as running automated tests
Some PeerSpot members use build automation solutions. In reviews, they offer opinions on the most significant selection factors to consider when looking at this type of software. One theme...
I use the solution for making pipelines. I use it for deployments and CI/CD to make applications as required. I push code on CodeCommit. With the help of CodeCommit, I trigger the code to build and implement. Then, it will be deployed in Kubernetes using ECR and EKS.
I use the solution for my deployments.
We use AWS CodePipeline for agent deployments, Kubernetes orchestrations, and Argo deployments. We integrate it with multiple applications in the DevOps pipeline for software compression analysis purposes.
We use the solution to deploy different applications and connect third-party APIs to various projects. I commonly use the Jenkins CI/CD pipeline. I've used it to set up servers. The architecture is very complex and needs a lot of connections, storage, security, and network. We need CodePipeline to complete these processes faster.
We use the product for serverless integration AWS Lambda.
When you do the microservices, you can build from the source code and package it to the docker image. After that, you can deploy the docker image to the container which is also situated in the AWS CodePipeline.
I am using AWS CodePipeline to deploy our products for production.
Our primary use case for CodePipeline is speeding up our development process. The solution is highly automated and allows us to build and deploy code without any effort. It's automatically initiated once I commit my code. CodePipeline also helps me to find bugs quickly, increasing my release speed. On the other hand, it helps our customers receive our releases regularly and incrementally. CodePipeline helps us out with our delivery and our customers are happy to see our results in real time through it. The solution is a continuous integration and delivery mechanism that helps us a lot in delivering our software. This is the most powerful benefit we get from using CodePipeline. It's one of those DevOps concepts recommended for use within the software development lifecycle.
CodePipeline assists with the writing of code. It posts reports to our CodeCommit that is connected to our AWS source.
We use CodePipeline for deploying some of the applications that we have for AWS. Ours is a multi-cloud hybrid cloud approach. We have Azure, AWS, Google Cloud, and then we use CI/CD pipelines - our core pipeline tools - from each cloud. For example, on Azure, we use Azure DevOps that integrates with our GitHub on-prem. That's what we use for deploying anything on Azure. The same GitHub. It is also used on Google Cloud. We don't use the native tools from any of the clouds. For example, the CodePipeline from AWS or Deployment Manager from Google Cloud. We try to avoid those. We are moving towards Terraform with a GitHub integration as of our source code repository or pipeline, CI/CD pipeline. No matter what the cloud, we use our on-prem resources. We try to avoid using the cloud.