Thank you for joining us for Course 2 in our DevOps Series, focusing on Release and Deploy. This reading provides a recap of the previous course, DevOps on AWS: Code, Build, and Test. The previous course focused on processes and practices you would use in a software development team.

Code

Usually, writing the code is the first thing you might think about when doing software development. In the previous course, you looked at answers to four frequently asked questions, which are: Where is the code? Where should I be committing updates? How often should I be committing and integrating? When do changes get deployed for end users? We also highlighted AWS CodeCommit as a secure, highly scalable, managed source control service that hosts private Git repositories. CodeCommit makes it easy for teams to securely collaborate on code, with contributions encrypted in transit and at rest. CodeCommit reduces the need for you to manage your own source control system or worry about scaling its infrastructure.

Build

A build is going to take your source, compile it, and retrieve dependency packages from a repository—like Node package manager (npm) modules or an Apache Maven artifact in Java. A build will usually include automated testing to check the quality of the code, and unit tests to exercise the code and make sure it does what you expect it to. AWS CodeBuild is a fully managed continuous integration service that compiles source code, runs tests, and produces software packages that are ready to deploy. You don’t need to provision, manage, and scale your own build servers. CodeBuild scales continuously and can process multiple builds concurrently. A branch in Git is a pointer to a commit. When you make commits in a branch, the pointer automatically moves forward. The main idea behind the Feature Branch Workflow is that all feature development takes place in a dedicated branch. This workflow makes it easy for multiple developers to work on a feature without disrupting the main code base. When working in source control, you and your team need to agree on a convention that allows you to work on features and keep code out of the main branch until you are confident that it is ready for production.

Test

Next, we talked about testing—and how testing fits into a continuous integration and continuous delivery (CI/CD) pipeline. By performing testing at different stages of your development cycle, you are creating a measure of quality. When you write code, that code is going to do exactly what you tell it to do. The important question is: Are you telling it to do the right thing? At this point, the application is under source control and you have automated tests to make sure the code is in a good state. Because you want to run these tests each time you commit code, you will receive immediate feedback whether the code committed still works. AWS CodePipeline is a fully managed, continuous delivery service that helps you automate your release pipelines for fast and reliable updates to your application and infrastructure. Based on the release model you define, CodePipeline automates the build, test, and deploy phases of your release process each time there is a code change. You can use CodePipeline to deliver features and updates both rapidly and reliably. The previous course worked with serverless compute, but this course will be server-based. The readings will have information about deployments using serverless technologies, if you’re interested in learning more. Code repositories—and tools for build and test—are still relevant for server-based workloads. Note: The labs for this course will not build on the labs that were created for the previous course. For more information about our other two courses in this series, see: Course 1 - DevOps on AWS: Code, Build, and Test Course 3 - DevOps on AWS: Operate and Monitor