A new service named AWS CodeDeploy was announced last week at AWS re:Invent in Las Vegas!
AWS CodeDeploy is an exciting new service that we had the opportunity to be involved with during the private beta test. Allow me to tell you about how cool it is…
What is AWS CodeDeploy?
AWS CodeDeploy is a fully managed, high-scale deployment service that lets developers quickly and simply automate the process of deploying and updating applications on Amazon EC2. Another component of AWS CodeDeploy is the agent software that enables instances to act as clients to the AWS CodeDeploy service. This client is available for both Linux and Windows.
How does AWS CodeDeploy work?
I’ll explain the basics of how the AWS CodeDeploy service operates. As previously noted, the agent must be installed on instances that you’d like to use with the service. This means that it’s a good idea “bake” a new Amazon Machine Image (AMI) that has the agent already installed. For details regarding installation of the client, visit Configuring an Amazon EC2 Instance to Work with AWS CodeDeploy.
Instances are configured into a set called a deployment group. Deployment groups contain instances specified by tags and/or auto scaling groups.
AWS CodeDeploy has the concept of creating revisions of application code that are deployed to your deployment groups. Appropriately named, a revision contains a copy of the code that you want to deploy. The revision also includes an “application specification file,” or AppSpec file.
The AppSpec File:
The AppSpec file is a YAML document that includes details about the deployment operation. The AppSpec file contains the following sections:
version – Version of your code
os – The OS that AWS CodeDeploy is operating on (e.g. “linux”)
files – The files that you’re deploying (code) and their source/destination
permissions – Permissions given to the files that are being deployed
hooks – Scripts that can be executed at different AWS CodeDeploy life cycle events
The hooks section is particularly interesting, in that you can specify scripts that are to be executed during the following AWS CodeDeploy life cycle events:
ApplicationStop and BeforeInstall scripts can be used for stopping applications and performing any operations that may be required before deploying a new set of code (e.g. stopping the web server and moving existing code). AfterInstall and ApplicationStart are used similarly, but they execute after your revision has been deployed. ValidateService is the final event that is run before the code deployment process ends. This is for running sanity checks or a series of unit tests to confirm that things are working as expected.
It is worth noting that at any point during your life cycle events scripts you can exit with a non-zero status and halt the rest of the AWS CodeDeploy process. This is great if, for instance, during the ValidateService event things go awry, as you can stop the deployment process to the rest of your fleet.
Application revisions are deployed to deployment groups according to the deployment configuration specified. The deployment configuration refers to the rate at which AWS CodeDeploy should deploy to instances (i.e. one at a time, all at once, etc.).
After these facets are addressed, you can run a deployment and watch it go! All of these steps can be performed using the AWS CLI, which is exactly what we used to work with AWS CodeDeploy. We also set this up with our existing Jenkins service so that we can run build and deploy jobs at our leisure. Speaking of which, AWS also released a Jenkins plugin that can run the entire push and deployment process for you!
AWS CodeDeploy has its own dashboard in the AWS Management Console. The dashboard can be used to create applications and run deployments, and provides information regarding the health and history of your deployments. This includes displaying the success rate, and if and where something went wrong.
Have you used AWS CodeDeploy? Tell us what you think about this AWS service.