- [Instructor] Welcome back. In this lecture, we'll provide a brief introduction to AWS CodePipeline and how it can be used to orchestrate the delivery of your software from source code to executable and deployable releases. We'll show you where AWS CodePipeline sits in a CICD setup. This lecture will familiarize yourself with AWS CodePipeline servers and insure you know when and where to use it within your own software projects. Okay, let's begin. AWS CodePipeline is a fully managed, continuous delivery system used to automate the building, testing, and deployment of your code. CodePipeline provides visualization tools that give you the ability to understand the high level steps involved and orchestrated by CodePipeline. The CodePipeline console allows you to see the current state of any release and whether the overall pipeline has succeeded or has been blocked by perhaps a failed test. AWS CodePipeline has many great features. Some of which include the ability for automation of build test and release stages, manual approvals, pipeline history reports and pipeline status visualizations. AWS CodePipeline is used to orchestrate the various phases within your CICD setup. It does so by using the concept of a pipeline. AWS CodePipeline has seamless integration into other AWS development services, such as CodeCommit, CodeBuild, and CodeDeploy. As an example, AWS CodePipeline can be used to create a pipeline which gets the latest code commit, runs it through a build phase then through a testing phase, then deploys the release to staging, followed by a manual approval process to push the release to production. Understanding how to set up automated build and release processes with CodePipeline requires familiarization with several concepts. Let's cover these now. A pipeline is constructed using one or many stages. Each stage can, itself, have one or many actions. Actions within a stage run either in parallel or sequentially. A transition exists between stages. CodePipeline has six action types. They are, in no particular order, approval, source, build, test, deploy, and invoke. Let's cover off each of these now. Approval, the approval action is used to add a manual approval step. This is useful when you want to insure that your software release is tested by somebody before deploying into production. Source, the source action is used to specify the location of the source code. This action type, for example, can be configured to pull the source from or from a CodeCommit repository or from a GitHub repository. Build, the build action is used to specify the build process. For example, how the source code gets compiled. This action type, for example, can be configured to perform the build phase using any one of the following build providers- AWS CodeBuild, Jenkins, or Solano CI. Test, the test action is used to specify the testing process. For example, how the release is to be tested before deployment. This action type, for example, can be configured to perform the test phase using any one of the following test providers- AWS CodeBuild, Jenkins, BlazeMeter, Ghost Inspector, and a few others as well. Deploy, the deploy action is used to specify the deployment process. For example, how the release is to be deployed. This action type, for example, can be configured to perform the deployment phase using any one of the following deployment providers- ECS, CodeDeploy, CloudFormation, or Elastic Beanstalk. Invoke, the invoke action is used to provide further integration options and flexibility by allowing you to implement custom lambda functions that can be called directly from within the pipeline via the section type. The steps to set up a new AWS CodePipeline build and release process are fairly simple. The AWS CodePipeline console provides a nice wizard driven approach for constructing your pipelines. The end result of stepping through the guided create pipeline wizard will be a pipeline configured with three stages- a source stage, build stage, and staging stage, assuming each of these stages was configured with an action. The resulting pipeline, having completed the creation process, looks like the following. From here, you can enter the pipeline and customize further by adding in extra stages, adding or removing actions within a particular stage, or perhaps updating the execution of order of actions from sequential to parallel or vice versa. Integration options within AWS CodePipeline are numerous, which is a good thing. Software projects come in all sorts of shapes and sizes and may be governed by different methodologies. With this in mind, CodePipeline and its many integration options provide you with the flexibility to be able to mold the perfect build and release process that works for your project. Let's cover off what options are available to you. As already mentioned, CodePipeline supports six action types- source, build, test, invoke, approve, and deploy. Each one of these action types has a set of different options allowing you to call out to the system or service of choice. In particular, the invoke action allows you to call out to a custom lambda function that may perform some custom activity. Next, AWS CodePipeline supports CloudWatch Events. You can use CloudWatch Events to detect and react to state changes within your pipelines. This capability allows you to model in notifications totopics, which can then kick off lambda functions that may perform some other feature within your build and release process. Pipelines created within CodePipeline are, by default, configured to use Amazon CloudWatch Events to be automatically started when a new commit is detected in CodeCommit. Alternatively, this behavior can be swapped for a polling mechanism where CodePipeline instead polls periodically for change undertaken within your source repository. Okay, that completes this introduction lecture on the AWS CodePipeline service. Go ahead and close this lecture and we'll see you shortly in the next one.