Demo: Creating a Delivery Pipeline Using AWS CodePipeline

Whenever a developer commits a change to AWS CodeCommit, a build must be triggered immediately by AWS CodeBuild, producing build artifacts that AWS CodeDeploy eventually deploys. AWS S3 facilitates this mechanism by storing the output artifact from one stage and making it available as an input artifact to the next stage, as shown below:

Create a release pipeline using AWS CodePipeline

To create a release pipeline, launch the AWS Console and select the CodePipeline service. Start by giving the pipeline a name and choosing a “Service role.” The purpose of this service role is for CodePipeline to invoke other AWS services. We can create a new service role or reuse an existing one. In our case, we're reusing a current service role. To specify a previously existing service role, we must select the “Role ARN” (Amazon Resource Name), as shown below.

The next step is to create an S3 bucket used throughout the pipeline. Again, we have the option of using the pipeline’s default bucket or choosing a custom location. We'll choose a custom location and select the already created bucket. Since we don’t have any previously created keys, we'll use the default keys provided by the AWS CodePipeline.

Adding source to the release pipeline

Our first step is to select the “Source provider.” AWS CodePipeline provides several options like AWS CodeCommit, Amazon S3, GitHub, and Bitbucket. We'll choose AWS CodeCommit and select the repository name that contains the application source code. The fact we need to choose a branch should give us an indication that we need to create a separate pipeline for building code in developer branches. AWS CodePipeline recommends using AWS CloudWatch events to automatically detect any change to start the pipeline. Since AWS CodePipeline checks only periodically, it might result in build queue backlogs. By default, CodePipeline uses the default zip format for the output artifacts. As shown below, this option does not include Git metadata, meaning we might not have access to the Git commit history of the repository. If our project requires maintaining Git metadata, then we need to choose the “Full clone” option.

Adding build to the release pipeline

The subsequent step is to add the build stage to our release pipeline. AWS CodePipeline also supports Jenkins as another build option, but we'll choose AWS CodeBuild. By selecting a region from the drop-down, we confine our release pipeline to this specific region. We can create a project dynamically or reuse a pre-existing one, and we'll choose a previously built project. Some projects might not require this build step as code might instead be deployed directly from an S3 bucket. That's why AWS CodePipeline provides us with a “Skip build stage” option.

Adding deploy to the release pipeline

The deploy stage is the final step in creating the release pipeline. AWS CodePipeline offers many deployment options, including AWS Elastic Beanstalk, AWS CloudFormation, Amazon S3, Amazon ECS, and many more. We'll choose AWS CodeDeploy and select the previously created deployment application and deployment group.

Validate the pipeline

Now that the release pipeline has been built, let’s use the AWS CLI command to confirm that it was built successfully. We can achieve this using the list-pipelines command. Along with the pipeline name, it shows the version, created, and updated timestamp.

Try it yourself

Press the “Edit” button to add a value of your choice for the CodePipeline pipeline name in the PipelineName API key. Then, click the “Run” button to launch a live environment, and run the commands given in the setup.sh file in the following coding playground: