Creating a Full CI/CD for our Portal Application Using CodePipeline

The course is part of these learning paths

DevOps Engineer – Professional Certification Preparation for AWS
course-steps 35 certification 5 lab-steps 17 quiz-steps 2 description 3
Solutions Architect – Professional Certification Preparation for AWS
course-steps 45 certification 5 lab-steps 19 quiz-steps 5 description 2
Certified Developer – Associate Certification Preparation for AWS
course-steps 27 certification 5 lab-steps 22 description 2
AWS Developer Services for CI/CD
course-steps 9 certification 1 lab-steps 3
more_horiz See 1 more
Start course


In this course we’ll provide you with an introduction to AWS CodePipeline and how it can be used to orchestrate the delivery of your software from source code to executable and deployable artifacts. We’ll show you where AWS CodePipeline sits in a CI/CD setup. This course will familiarize yourself with the AWS CodePipeline service and ensure you know when and where to use it within your own software projects. We'll then provide a demonstration where we use AWS CodePipeline to orchestrate our build and deploy workflow for our web portal project.


- [Jeremy] In this demonstration, we'll use the CodePipeline service to set up a continuous delivery pipeline. Clicking on the create pipeline, we give our pipeline a name, WebApp pipeline. For source provider, we'll use AWS CodeCommit and select the repository we built earlier on. For branch name, we'll use master. Opening change detection options, we'll leave the default which is to use Amazon CloudWatch Events to kick off this pipeline. For build provider, we'll use AWS CodeBuild. And we'll create a new CodeBuild project. We'll give our project name the name web app build version 2. In terms of container, we'll use Ubuntu Base and we'll set the version to Ubuntu Base 14.04. We'll specify a role name that will be used for our AWS CodeBuild project. We'll click the save build project button and this will talk to the CodeBuild service and create this new build project. Okay, we're informed that our build project was created and saved. We'll click the next step and we'll set up our deployment provider. We'll use AWS CodeDeploy for this. We'll select WebApp as our application name. And WebApp deployment group as the deployment group. We'll create a role for our CodePipeline service. This takes us off through the one click role creation. We'll click on the allow button and the role is created in the background. Clicking on the next step, we get to review our pipeline. Notice the artifact settings. So this is a bucket that pipeline will automatically create and store the artifacts in. We'll click on the create pipeline button. And our pipeline is created. And we get this nice visualization that shows us the stages within our pipeline. So we have a source stage, build stage, and a staging stage. As you see, the source stage is already kicked in. So it is gone to AWS CodeCommit to our repository and grabbed the latest commit. After the source stage finishes, we transition to the build stage. So here, AWS CodeBuild is running through the build project and it'll be using the last commit that we committed into our repository. In this case, we made a minor update to the inbox.html file where we changed the user from John Doe to Jeremy Cook. So this is in the inbox.html file. So the CodeBuild project will keep running until it succeeds and creates our zip artifact, which it has succeeded just now. So we transition to the staging stage and this will run kicking off our CodeDeploy. We notice that between the stages we have the ability to disable the transitions if we need to. So our staging stage is still going, which is running our code deployment setup. And it's just succeeded, which is great news. So if we jump back into our browser and we refresh the URL, we'll change the URL to inbox.html. And if our build has worked, and it has, it's changed the username from John Doe to Jeremy Cook. So jumping back into Visual Code. Let's make another change. We'll select the index.html file. And we'll look for John Doe and again, we'll change this username to Jeremy Cook. We'll save the file. And then we'll commit this change into our CodeCommit repository. So we give it a commit message, update homepage username. We can see the differences. We commit it to master and then we push it to origin. Now, if all goes well, once this commit hits the repository it'll trigger the CodePipeline again. We can see here that indeed this has happened. So the source stage has kicked in to get the latest commit of the source code. We'll do a quick navigation to the index.html file and we can still see it's set to John Doe. So the source stage is finished and we're into the build stage. So clicking on the source, we can click on the commit ID and be taken directly into the latest commit within CodeCommit, which is quite a useful thing to do. So the build stage is still going and it has just succeeded. So we've transitioned now into the staging stage. And shortly this will complete as it has now. And again, if we go back into our WebApp and this time we refresh the page, we'll notice that the username John Doe has been changed to Jeremy Cook. So this is showing the full continuous delivery mechanism of CodePipeline. We can edit our pipeline, which we'll do now. So we'll click on stage and we'll add an extra stage called approval. Clicking on the action link, we'll choose the approval category and the approval type will be a manual approval. And for the action name, we'll specify deploy. We add the action. Unfortunately, we can't use question marks. So we'll update our action name. It'll be deploy WebApp. Click the add action. And we now have our deploy WebApp manual approval action added to our stage. We'll go up into the build stage and edit this. And we can see how we can add parallel actions that run at the same time as other actions in the same stage. In this case, we could select Jenkins as the build provider. But we'll cancel out of that and leave our only remaining change the new approval stage. So we click on save. And we now can see the addition of our approval stage to the pipeline. So we'll go back into Visual Code and we'll update the username again to kick off another run through our pipeline. In this case, we set the username to the white rabbit. We will again give it a message, updated user's name. Again, we commit it to master. Again, we push to origin. It sends our change back to our CodeCommit repository, which will then trigger our pipeline. So waiting within our pipeline view, we should shortly see the source stage kick in, which it has just now. And this will download the latest commit within our repository. And shortly this will complete, which it just has. The build stage kicks in. So again this is using CodeBuild to build the latest version of the source code. Again, if we click on the commit ID, we can go back into CodeCommit and see what the latest change was. It still looks like our build stage is running. But again that should complete soon as it just has now. So now we're into our new approval stage. And here we can see we're requesting an approval. So someone has to take action. We'll put on a comment, approved, and we'll click the approve button. Okay, that's done. Now shortly this should allow the pipeline to continue and transition to the staging stage, which users CodeDeploy to roll out the latest build artifact onto the servers that are configured. So that's running now. And again, very shortly that should succeed as per the blue and green bars on the side of the stages. So that's completed. We'll go back into our portal. We'll refresh the index.html page. Again, you can see our new username has flowed through. So that has all worked and shows you how effective CodePipeline can be for doing continuous delivery.

About the Author

Learning paths11

Jeremy is the DevOps Content Lead at Cloud Academy where he specializes in developing technical training documentation for DevOps.

He has a strong background in software engineering, and has been coding with various languages, frameworks, and systems for the past 20+ years. In recent times, Jeremy has been focused on DevOps, Cloud, Security, and Machine Learning.

Jeremy holds professional certifications for both the AWS and GCP cloud platforms.