In this video, get a high-level overview of CodeDeploy concepts and use cases.
- [Instructor] We've looked at a few different methods that AWS provides for both deployment and provisioning application servers. Next up is CodeDeploy, which provides less automation than the other methods, but does provide more manual control than, say, Elastic Beanstalk. CodeDeploy is designed to give you tools and get out of the way. You write your own deployment scripts using a light framework. CodeDeploy provides hooks for certain deployment events, so you can be sure to execute certain actions at the right time. It allows deployment from S3 or from Git.
Finally, unlike Beanstalk or OpsWorks, CodeDeploy is a deployment tool only. You will need to build and provision infrastructure yourself in advance of using CodeDeploy. However, CodeDeploy can deploy to many instances at once, as we'll see. There are a few concepts with which you need to be familiar before using CodeDeploy. First, the application. As with Beanstalk and OpsWorks, you start by defining your application. The application contains a reference to a deployment group. Deployment groups specify which instances CodeDeploy should deploy code to.
Applications also specify a deployment configuration, which is a simple directive for how to roll out new code. Options are one at a time, half of your fleet at a time, or every instance at once. From there, you create deployments. Each deployment represents a push of one application revision to a deployment group. Deployment groups are one of the unique features of CodeDeploy. A deployment group can be defined as any combination of Auto Scaling groups, EC2 instances identified by tag values you specify, or even local, on-premises, non-AWS instances.
Local instances must be manually registered with CodeDeploy before they can be added to a deployment group. You have multiple options for deployment sources. App revisions can be defined either by specifying a location in S3 or by supplying the commit ID of a Git revision in a remote Git repository, such as GitHub or Bitbucket. This means that, unlike with Elastic Beanstalk, you are required to have a remote repository when you want to use CodeDeploy to deploy applications from Git. Whether they're in AWS or on premises, instances must be configured to work with CodeDeploy by installing the CodeDeploy agent software.
AWS maintains installers for the agent in publicly accessible S3 buckets. The location differs per region, so you'll have to reference the documentation. After installation, the agent runs as a service, meaning that it starts itself up automatically when the instance starts. The CodeDeploy agent polls the AWS CodeDeploy service to check for new deployment jobs, meaning CodeDeploy doesn't push code. Rather, the instance's agent pulls jobs and executes the deployment itself. Remember that CodeDeploy does not handle any infrastructure for you, so you'll want to consider some of the many other building and provisioning options, such as CloudFormation, to help.
How does the agent know what steps to take to perform a deployment job? The deployment job specifies an application revision. The revision will be in either S3 or Git, and it contains all application code, configuration files needed by the app, such as server configuration files, and a special file called appspec.yml. The appspec.yml file features some configuration management like functionality. It has sections for moving files around, setting file permissions, and executing scripts that you provide.
It also contains tags for each major event in the CodeDeploy lifecycle so that you can make sure that your operations execute when you need them. Finally, there are a few things you should keep in mind about CodeDeploy. First, as I've mentioned, there's no infrastructure management. You'll need to bring your own method for dealing with servers, load balancers, and databases. Second, the development loop can be slow. There's no way to test an appspec.yml file locally. You must execute a deployment each time you want to test a change to the appspec.yml, and that can get frustrating, especially if you accidentally push a typo.
There's no built-in support for immutable deployments. Changes will always propagate through your deployment group. Finally, registering instances with load balancers must be handled by your deployment code. CodeDeploy's strength is the lightweight and unopinionated nature of its tool set. Beanstalk and OpsWorks provide more structure and can be more prescriptive about how you run things. If you have a unique environment or existing deployment scripts that you use on premises, CodeDeploy can be a great way to make that deployment more automated and integrate it with AWS.
- Understanding AWS EC2
- Creating an EC2 instance
- Provisioning with CloudFormation
- Architecting apps for horizontal scaling
- Creating an Elastic Beanstalk environment and app
- Using OpsWorks
- Deploying apps with CodeDeploy
- Working with the Cloud9 cloud-based IDE
- Quickly setting up coding projects with CodeStar