Using AWS CodeStar to Launch our full CI/CD Workflow

The course is part of these learning paths

DevOps Engineer – Professional Certification Preparation for AWS (2019)
course-steps 35 certification 4 lab-steps 17 quiz-steps 2 description 3
AWS Developer Services for CI/CD
course-steps 9 certification 1 lab-steps 3
Start course


Working with AWS Codestar


- [Instructor] In this last demonstration, we'll use AWS CodeStar to orchestrate the setup of our full CI/CD environment. So, clicking on CodeStar takes us into the Dashboard. We can see existing CodeStar projects. We click on create project and we get a list of templates that we can select from. So, these templates are preconfigured in specific to the type of software development required. On the left-hand side, we can narrow down our search. We can filter. So, here I've chosen Web application, Java, and EC2. I then select that template. That takes me to the project details page. I enter in the project name: javawebapp. I'll use AWS CodeCommit as the repository. And the repository name is specified here. Next, when we review the project details, we can see how CodeStar is going to use each of the AWS developer services to create some part of our CI/CD workflow. Clicking on the Edit Amazon EC2 configuration link, we can specify the instance type that our Java web app will be deployed to. Here we specified t2.micro and the network that it will go into. Clicking on the Create Project button requests us to select the Amazon EC2 Key Pair, which we do. We then click the create button on this dialogue and that starts the spin up process. Next, we're given the option of specifying the tools that we'll use to edit our code. So, we'll select AWS Cloud9 but we could also have selected Command line tools, Eclipse, Virtual Studio. We'll stick with Cloud9 and click the Next button. Here we specify the instance type, t2.micro, to host our Cloud9 environment. Again, we can check the Cost-saving settings but we'll leave it as the default. So, it will shutdown after 30 minutes of inactivity. We can look at the environment name and description and, again, the network settings. We'll leave those as defaults and click the Next button. This kicks off the provisioning process for both the javawebapp instance which will host our Java web app as well as the Cloud9 IDE instance. The provisioning time for this normally takes a few minutes. We'll skip ahead. So, we're back on the Dashboard, now, and we have successfully spun up both our IDE and the instance that will host the Java web app. In the Dashboard, we get a number of tiles representing pieces of information for our CI/CD workflow. Let's take a look around. On the right-hand side, we can see the CodePipeline workflow that has been created for us. And then it's already gone to CodeCommit and downloaded the source code. So, clicking into CodeCommit, we can see that CodeStar has prepopulated our repository with some sample project code. This includes an appspec, buildspec, and pom configuration files. Which will drive both the CodeBuild and CodeDeploy phases. So, the CodeBuild phase is completed, and, now, we're into the deploy phase. As per the Application stage within our Pipeline. So, we'll give this a little bit of time, and this will complete very soon. Towards the top, we can click on the Application endpoint. Which is the URL for our Java web app. And, here, we can see that, indeed, the CodeDeploy has actually already completed. So, we've gone through the full CI/CD workflow within our Pipeline. Back within CodeStar. If we click on the IDE. We can see our Cloud9 integrated development environment. If we open it, we're taken into the code base. So, on the left-hand side, we can see the code that CodeStar generated and populated into our repository for us. If we have a look around, we can see the various files. Let's open up one of the Java class files. We'll do that by navigating into the Java folder. And we'll open up the file. What we can see here is that we get some text highlighting. So, all the keywords within the Java file have been highlighted. Next, we'll take a look at some of the static web asset type files. The CSS and the Java script files. And, finally, let's update one of the views. We'll update the home view. So, opening the index.jsp file, we'll navigate down and we'll update the congratulations message. We'll change it to congratulations 2018. We'll change the message below it as well. Just so that we can be clear that the changes have come through. So, we change this to Version 2. Okay, we'll save the file and then we'll jump into the terminal session in the bottom pane. We need to configure git to use our username and email address. I'll specify Jeremy Cook for the user name and then for the email address. Before I do the git commit, I'll run aws iam get-user to see who the indicated user is. Here, we can see that we're logged on as I perform a git status. I change into the right directory. So, I'm now in the javawebapp directory on the master branch. I run git status again. I can see the modified file. I'll add that to my change commit. I do a git status again. And, now, I'm ready to do a git commit. So, I specify a message: updated home page. And, now, I push that out to the code commit repository. Now, if everything's gone well, that should kick off the Pipeline. So, first thing: CodeCommit. We'll check that our commit arrived, as it has. And then, back within CodeStar, we'll jump back onto the Dashboard and examine the Pipeline. And, here, we can see that the Source stage has, again, kicked in, as we expect it to do so. So, we get this unified view, within the Dashboard, of all the various components of CI/CD workflow. Which is brilliant. We can see the Commit history. We can click on the commit ID and be taken directly into CodeCommit. We can see CloudWatch metrics for our instance. In this case, it's showing CPU utilization. On the left-hand side, we have navigation menu items into the various other services. So, here, we're gonna navigate into CodePipeline. And we can see our Pipeline that was created for us by CodeStar. We can click on the Team menu item. And, here, we can manage team members. So, we can add additional member who may want to collaborate on our code base. So, here, we'll select one of our iam users. In this case, the BasicUser. Here, we can see the three project roles: Viewer, Contributor, and Owner. Depending on which project role we would want to give this user, we would select one of these three. For now, let's just cancel this and go back to our CodeStar Dashboard to see how the current Pipeline is progressing. So, here we can see that the Source stage is completed and we're currently in the Build stage. And we'll skip ahead and, now, we can see that all three stages have completed. So, if we go back to our Java web app frontend and, we reload it, we should see the new message. Excellent, there we go. So, that has shown that our full CI/CD workflow has been utilized. Going back into our Cloud9 IDE, let's take a look at the buildspec file. The buildspec file drives code build. So, here we can see that we're using Maven to do a clean compile and test. We then package it and, then, we specify the artifacts as a zip file and populate it with a number of our files out of project directory. Taking a look at the appspec file, this is used by CodeDeploy. We can see that we have a source file, which is our ROOT dot web archive, and we deployed in a, into a particular destination. We then run a install_dependencies script and, finally, a start_server script. So, let's take a look at each of these. So, the install dependencies is downloading Apache Tomcat. It makes a directory, it then extracts the tar file into that directory. The start_service script, basically, calls CDs into the Tomcat directory and calls the file. Having a look at the pom file, this has all the declarations that drive Maven to do the various phases of clean build test. Okay, so, as we have seen, AWS CodeStar is a fantastic service for provisioning full CI/CD workflows. It takes care of all of the plumbing and configuration between each of the AWS developer's services. And, as an end result, provides a unified view across each of those services within the Dashboard.

About the Author

Learning paths9

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.