In this video, you’ll see how to streamline your software release process using AWS CodePipeline.
With this continuous delivery service, you can model each step in your software release process,
automate the process from beginning to end, and approve software changes for production.
AWS CodePipeline is a fully managed continuous delivery service used in conjunction
with other AWS development services to store, build, and deploy applications in an automated fashion.
To get started, let’s navigate to Amazon Elastic Compute Cloud (Amazon EC2) to create a build environment.
For the purposes of this example, we already have an EC2 instance running,
which was provisioned when we created our AWS Cloud9 development environment.
This environment has the code for the sample application we will deploy
and will be the environment from which we will commit that code to the CodeBuild repository.
Let’s launch a new instance that CodeDeploy will deploy our sample web application to.
We’ll select the Amazon Linux 2 template.
Next, we’ll configure the instance to allow the CodeDeploy agent to run on it.
To do so,
we need an AWS Identity and Access Management (IAM) role with a policy that allows it access.
Let’s navigate to IAM and take a look at the roles.
Let's take a look at AWSCodeDeployRole, which is an AWS managed role for CodeDeploy.
The policy attached to this role allows AWS CodeDeploy to access any EC2 instances
that have this policy attached to them.
Let’s return to the Roles screen and look at CodeDeployEC2InstanceProfile.
This profile enables any EC2 instance with this role attached
to access resources from Amazon Simple Storage Service (Amazon S3).
This allows CodeDeploy to retrieve artifacts built with CodeBuild and deploy them to the instance.
Let’s return to EC2 and finish configuring the instance for the build environment.
Attach the CodeDeployEC2InstanceProfile role to the instance.
In this case, let’s specify a set of commands to be run upon initialization of the instance.
These commands will install some necessary dependencies for the web application to run
when instantiated by CodeDeploy, as well as the CodeDeploy install script.
Proceed to the tag configuration step.
Let’s add a simple key-value tag pair to identify the instance so that it can be targeted in CodeDeploy.
Next, let’s add a rule to the security group created for the new instance
that will allow inbound traffic on the application’s specified port.
Review the settings and launch the instance.
For the purposes of this example, a key pair has already been created specifically for this instance
in case we need to access it over Secure Shell (SSH).
The instance is launching. Let’s drill down into it.
Now that the instance has finished provisioning,
there is one more prerequisite necessary for CodePipeline to function.
You must have an S3 bucket accessible from CodePipeline services
where build artifacts can be created and retrieved.
Let’s head to the S3 console.
As you can see, in this case a bucket has already been created for this purpose.
Let’s switch to Cloud9 to view the sample application before deploying it to AWS CodeCommit.
Note that we are using Cloud 9, but you can just as easily use a local development environment.
This is a simple Java web application that uses the Spring Framework.
As you can see, it contains a buildspec.yml file to configure the CodeBuild build process,
as well as an appspec.yml file to configure the CodeDeploy deployment process.
For the purposes of this example,
we are running this Cloud9 environment as a user who has an SSH key associated with CodeCommit.
This key allows Git operations to successfully push and pull changes from CodeCommit repositories.
Let’s navigate to CodeCommit now.
Let’s create a CodeCommit repository to host the sample web application’s source code.
Specify a name and create the repository.
Next, copy the HTTPS URL,
and then return to Cloud9 to push the web application’s source code into the repository.
For our purposes,
the application has already been initialized with a Git repository in the Cloud9 development environment.
The files have also been added and committed to that local repository.
Let’s use the URL we copied to add the CodeCommit repository as a remote source to the local repository,
and then specify it as the origin source.
Next, let’s push the local application code to the remote origin repository’s master branch.
Now let’s head back to CodeCommit to verify that the code has been pushed to the remote repository.
As you can see, the application’s source code successfully pushed to CodeCommit.
Now let’s navigate to CodeBuild to create a build project for the application.
Specify a name for the build project.
Next, specify the source provider so that CodeBuild can retrieve the source code to start the build.
We’ll specify the CodeCommit repository.
Other sources, such as GitHub or S3, can also be specified instead of CodeCommit.
Branches other than the master branch can be specified as build sources for a CodeBuild build project.
In this example, we are using the master branch.
Next, let’s configure the build environment that will run the build steps
and any specified tests for the sample application.
For our purposes, select Amazon Linux 2 and specify the most recent image running CodeBuild.
If you wish, you can specify an existing service role with custom permissions
to allow CodeBuild to access other AWS services in order to run the build.
In this case, let’s just create a new service role.
You can also add advanced configuration for the environment, with options to specify networking,
environmental variables, and file system variables.
For our purposes, let’s move on.
AWS CodeBuild requires either a buildspec YAML file or manually entered build commands
that enumerate the steps and commands to be run when the build is executed.
Let’s take a look at the buildspec file that has been created for this project.
As you can see, this buildspec file specifies the phases of the build,
build artifact locations, and a directory for the cache.
Since buildspec.yml is the default filename CodeBuild looks for, we won’t specify an alternate filename.
Next, specify the artifact output location.
Select Amazon S3 and provide the path of the bucket we saw earlier.
Let’s also provide a name for the output build artifact that will be written to the bucket.
You can optionally provide a path to a directory within the S3 bucket
to separate the artifacts from the other resources in the bucket.
For our purposes, let’s move on.
Let’s specify that our artifact output should be uploaded into a .zip file
so that it can be easily used by other CodePipeline services later.
By default, the option to upload build output logs to CloudWatch logs is enabled.
Let’s retain this setting and create the project.
Now that the build project has been created, let’s start the build to ensure that the configuration is correct.
Notice that some parameters specified in the initialization of the build project
can be customized for a specific build.
Let’s retain the default settings and begin the build.
The build has successfully started.
Let’s take a look at the build logs to see a detailed step-by-step picture of the build process.
The build has now completed.
Next, let’s take a look at the S3 bucket to ensure that the build artifact was successfully outputted.
Here’s the output build artifact produced by CodeBuild.
Let’s copy the artifact S3 path for later use and return to CodeBuild.
The next step of configuring CodePipeline is to create a CodeDeploy deployment configuration for the project.
We’ll create a CodeDeploy application.
Specify a name for the application.
For our purposes, we’ll configure the CodeDeploy application for EC2 on-premises.
Now that the CodeDeploy application has been created, let’s create a deployment group
to target the EC2 instance we created at the beginning and build our application.
Specify a name for the group.
Specify the AWSCodeDeployRole we saw earlier.
This allows CodeDeploy to access the target EC2 instance.
You can choose between two deployment types.
“In-place” simply updates the instances in the deployment group with the latest application revisions.
“Blue/green” replaces the instances in the deployment group with new instances
and deploys the latest application revision to them.
In this case, let’s use in-place deployment.
For environment configuration, you can select any combination of Amazon EC2 Auto Scaling groups,
EC2 instances, and on-premises instances.
Let’s specify only the EC2 instance we created earlier to be part of the deployment environment.
To target the instance, we’ll specify the tag we added to it during creation.
Additional tags can be added to target different groups of instances as well, if desired.
Here, AWS Systems Manager can be configured to check for updates
to the CodeDeploy agent installed to the instance.
Let’s retain the default value, which installs the agent and checks for updates every two weeks.
You can also configure CodeDeploy to deploy to one instance at a time,
half of the instances at a time, or all instances at once.
Since we are deploying to a single instance, we’ll specify “all at once.”
You can also configure load balancing to manage incoming traffic for deployments.
Since this web application is not public, uncheck this option.
Create the deployment group.
Now that the deployment group is successfully created, we are ready to deploy.
Like CodeBuild, CodeDeploy requires instructions during execution to successfully deploy the application.
Let’s return to Cloud9 to review the appspec file that has been created to specify the deployment instructions.
As you can see,
this file specifies the source on the host machine that should be copied to the deployment environment.
It also specifies a number of “hooks,”
which correspond to named events in the CodeDeploy deployment process.
These hooks execute the specified shell scripts when the named event takes place.
Different appspec files can be used for different deployments if necessary,
as long as the correct YAML file is specified in CodeDeploy.
Let’s return to CodeDeploy.
Specify the location of the CodeBuild output build artifact to be used for deployment.
Other deployment behavior settings such as deployment group overrides
and rollback config overrides can also be specified for the deployment.
In this case, let’s continue and create the deployment.
Now that the deployment has been successfully created and deployed,
let’s return to EC2 to get the URL of the web application.
Here, we can see that the application is running on the EC2 instance
we provisioned using the port we specified.
Let’s take a quick look at it.
As you can see, the sample web application is running successfully.
Next, let’s return to CodeDeploy and build the pipeline for the application.
A pipeline is a workflow construct that describes how software changes go through a release process.
Specify a name for the pipeline.
Let’s allow CodePipeline to create a new service role so that it can access the other S3 services that CodeBuild
and CodeDeploy were able to access in order to build and deploy the application.
Instead of creating a new S3 bucket for the pipeline,
let’s specify the bucket we have been using for the output build artifacts.
Each pipeline is made up of a series of stages.
For the source stage, let’s once again select CodeCommit as the source provider,
and specify the previously created repository as the source code location.
By default, CodePipeline uses CloudWatch Events to start the pipeline when changes are detected,
but you can configure CodePipeline to periodically check for changes in the source code.
Let’s continue with the default.
For the build stage of the pipeline,
we’ll use the same configuration we specified in our earlier CodeBuild build project.
Notice that you have the option to use third-party build automation tools such as Jenkins.
For the deploy stage, we’ll use the same CodeDeploy project we created earlier.
Review the configurations and create the pipeline.
Once the pipeline has been successfully created, it can take several minutes for each stage to execute.
Let’s skip ahead to when execution is completed.
You can view logs detailing the build, including any potential errors
that occurred during the pipeline build or deploy process, by clicking on the pipeline execution ID.
Our pipeline is configured to detect any new commits pushed to the repository
and restart whenever changes are detected.
Let’s make a small change to the application to test the pipeline.
Let’s change the “Hello world!” welcome message on the home page to “Hello CodePipeline!”
Next, let’s track our changes, commit them, and push them to the CodeCommit repository.
Now let’s return to the pipeline.
As you can see, the pipeline restarted after we pushed our changes to the repository.
Let’s make sure the change was made.
As expected,
the deployed application now displays the new message we added to the code and pushed to the repository.
You’ve just seen how to streamline your software release process using AWS CodePipeline.
Thanks for watching. Now it’s your turn to try.