This course provides detail on the AWS Developer Tool services relevant to the Developer - Associate exam.
- Introduction to AWS CodeCommit and how it can be used to manage your source code
- Learn where AWS CodeCommit sits in a CI/CD setup
- Understand when and where to use CodeCommit within your own development solutions
- Introduce you to AWS CodeBuild and how it can be used to compile, build, and test your source code
- Learn where AWS CodeBuild sits in a CI/CD setup
- Familiarize yourself with the AWS CodeBuild service and ensure you know when and where to use it within your own software projects
- Understand what AWS CodeDeploy is and when it should be used
- Learn from a demonstration where we use AWS CodeDeploy to deploy our web portal project onto EC2 infrastructure.
- Learn the fundamentals of AWS CodePipeline
- Understand where CodePipeline the service sits in a CI/CD setup
- learn how you can use AWS CodePipeline to orchestrate, build and deploy a workflow for a web portal project
- Understand the key aspects of AWS CodeStar, its benefits, and its use cases
Provision a full CI/CD workflow using AWS CodeStar
- Introduce the AWS X-Ray service and the functionality that it provides.
- Explain the functions of the AWS X-Ray service and how to use AWS X-Ray with other AWS services.
- Demonstrate how to use the AWS X-Ray Console - highlighting key areas such as the Service Map and Tracing windows
- Demonstrate how to implement a Docker-based Node.js application using the AWS X-ray SDK.
- [Instructor] In this next demonstration, we'll use CodeBuild to build our web application. We do so by clicking the create project button to create our build project. We'll give it a project name. In this case, WebApp. For source provider, we'll use our repository we created in the previous demonstration. We'll need to choose the repository. And we'll enable the build badge. We'll come back to this later. In terms of the container that we'll use, we'll select Ubuntu, base for runtime, and in the runtime version we'll choose Ubuntu base 14.04. We'll specify that the build spec file is in the root of our project directory. Let's list the contents. Here you can see the build spec file. Let's take a look at the contents of this file. This has the commands that will be used by CodeBuild during the build. It has several phases- install, pre-build, build, and post-build. The only one of significance that we use is under the build phase. And what we're doing here is doing a scan across one of the directories looking for all of the html files and then doing a search and replace for a particular string token. In this case, company_token is replaced with the string CloudAcademy space Demo. Right. Next, we'll take a look inside the directory. In particular, the index.html file as an example of one of the files that we'll search for. Here you can see the token that we'll replace during the build phase. And again, it is in another place within the same file. Okay, jumping back into CodeBuild. We'll continue with the configuration. For artifacts, we'll choose Amazon S3. We'll give it a name. We'll call it WebApp.zip. This is the artifact. This is the output of our build. And we'll place it in a bucket called catestbuild. Next we highlight the IAM service role that will be created for our CodeBuild project. We expand advanced settings and for our artifact packaging, we choose zip for our output. And then, finally, we click the continue button. We get to review our settings. We simply click save and build. And that sets up our build project. Before we kick off the build, let's take a look at our S3 bucket and see what it contains before we kick off the build. Back within the AWS console, clicking on S3, we'll then search for the bucket that we're configured with in our build, catestbuild. Opening up this bucket, if we refresh the contents we see that it's empty as expected. Okay, we now kick off our build. But before we do, we need to specify the branch and the source version. So, in this case, we'll choose master and we'll use the source version for our last commit. So we kick off the build and we can see that the build started as per the phase details. Right now, it's provisioning the container that will be used for the build. Under build logs, we can see finer details of how our build is progressing. Right now, we've downloaded the source. We've done the install, the pre-build, the build and the post-build. The artifacts have been uploaded and the full build project has completed successfully. So again under build logs, we can scroll up and down and see the detail of the build. We'll jump back over into our S3 console and we'll do a refresh within our bucket. In here we can see indeed our artifact has been stored successfully, WebApp.zip. We can now download this file and then take a closer look at the packaging that was undertaken by the build. So we'll do that. So we're downloading the file and within our finder we'll double-click on the file which will unzip it and then we can look at the folder structure within. Okay, opening up the folder we can see that we have a webpage directory. This directory contains all our assets for the WebApp, our front end assets. Okay, let's move on. Recall earlier that we enabled build badges on our build project. Let's complete this configuration. So we'll jump into Visual Code and create a new file called README.md. This will be our README markdown file. We'll place it in the root of our project. This is equivalent to the README.md file that you'd see typically in a GitHub repository. So, adding new file. We call it README.md for markdown. And we move this file into the root of our project. Next, we'll paste in our content for our README file. And you'll notice at the top, we have this placeholder for our code build badge. So now we need to determine the URL. And the only way we can do this at the moment is to use the AWS CLI. So within our terminal, we'll make a call to AWS CodeBuild and batch-get- and we'll double tab to see the completions and its projects. So batch get projects. And we'll consult the help. So we need to pass in a names parameter. So we go back and we add in the names parameter. And the name will be the name of our build project. Here we use WebApp build and we set the region to be the region that our build project was in, which is Oregon. So we commit this. And we notice that we get an error. The reason being is that we haven't set up our profile within the terminal session. I set our profile. I'll rerun the command. And, unfortunately, it comes back as empty because we've used the wrong build project name. So let's go back to CodeBuild and double-check the name of our project. And here we see it's WebApp, not WebApp build. So going back to our terminal session, we'll rerun the command but change the name to WebApp. Clicking enter and we correctly get back our response. Now down towards the bottom, we have a badge request URL. So this is the URL we'll copy and we'll take this and paste it back onto our README.md file. Save the file changes. And then finally, we'll commit this back into our repository. Next, we set a commit message and then we commit to master and then push to origin. So this is pushing our latest change, which is the README file back into our CodeCommit repository. So this shouldn't take too long. And very shortly, we complete. Excellent, so that's worked. Let's jump back into CodeCommit. And, if we do a refresh, we should now see a new README markdown file. And now we see the README as well as it being rendered by the CodeCommit console. If we click on use, we should now see, if all goes well, our build badge. So here we can see the build badge for our build project that has done a build on this particular version of the source code within our repository. This is another great tool and another great integration between CodeCommit and CodeBuild.
Jeremy is a Content Lead Architect and DevOps SME here at Cloud Academy where he specializes in developing DevOps technical training documentation.
He has a strong background in software engineering, and has been coding with various languages, frameworks, and systems for the past 25+ years. In recent times, Jeremy has been focused on DevOps, Cloud (AWS, GCP, Azure), Security, Kubernetes, and Machine Learning.
Jeremy holds professional certifications for AWS, GCP, and Kubernetes.