AWS CodeDeploy - definition & overview

AWS CodeDeploy deploys application code from AWS S3, GitHub, or BitBucket to EC2 or on-premises instances. If you aren’t yet on AWS and instead manage your infrastructure using a private cloud, CodeDeploy can even deploy to your on-premises servers. With hybrid infrastructure becoming the norm for many large implementations, this is a necessary feature for a cloud deployment tool.

When managing infrastructure on the AWS cloud, you have control over your AWS EC2 instances so you can configure your storage, databases, and networking, depending on your workload. Every app runs on multiple AWS EC2 instances. Deploying code to each of them can require a lot of time. As your app scales, this can be a bottleneck. Knowing this, AWS launched CodeDeploy in 2014.

The AWS CodeDeploy application deploys application code from AWS S3, GitHub, or BitBucket to EC2 instances or on-premises instances. If you aren’t yet on AWS and instead manage your infrastructure using a private cloud, CodeDeploy can even deploy to your on-premises servers. With hybrid infrastructure becoming the norm for many large implementations, this is a necessary feature for a cloud software deployment configuration tool.

CodeDeploy is powerful enough to deploy code across numerous hosts with varying configurations.

DevOps includes two key processes— continuous integration (CI) and continuous delivery. In a rush to get on the DevOps bandwagon, some organizations set up a Git repository and a Jenkins server and call it DevOps. However, releases are still chaotic because Git and Jenkins do not fully automate the release process.

To complete your transition to DevOps, continuous builds and tests are needed. You need to go the last mile and continuously deploy, too. Continuous delivery is releasing an app in short cycles, up to multiple times a day, and requires building and testing code so that it’s release-ready from the start.

Here are the main benefits of CD:

• Shortens time to market: Today, apps compete to bring the most innovative features. Long release cycles cause a significant delay in launching new features and cost businesses real money.
• Lets user feedback guide development: As you release more frequently, you can get real-world user feedback faster and work on the right things first.
• Enforces better engineering practices: Getting code release-ready requires developing with stability in mind and building in QA practices like test-driven development (TDD).
• Reduces risk: Frequent releases mean each release will have a smaller set of new features and updates. More frequent releases also mean more minor failures and a more resilient app.
• Frees up time to build new features: Automating the deployment process makes it more predictable and frees your teams to spend more time building new features rather than firefighting deployment issues.

You can deploy your code in two ways with CodeDeploy.

1. In-place software deployments: CodeDeploy deploys your code to the same EC2 instances by taking them offline, running the scripts to deploy your code, and then taking the instances back online. This method involves some downtime and should be scheduled, which CodeDeploy lets you do. However, it uses fewer EC2 instances than the alternate method.
2. Blue-green deployment: Create two identical production environments that can handle production loads equally well. As one environment runs the live application in the blue environment, the release is pushed to the alternate green environment to be configured and tested. Once the green environment is stable, all it takes is a switch in the elastic application load balancer to route traffic from blue to green. While this option uses more EC2 resources, it eliminates downtime and is the preferred method for mission-critical apps. Once the deployment is complete on the green environment, you can destroy the blue environment until your next release is ready. CodeDeploy can automate this entire process.

Let’s examine how CodeDeploy handles software deployments. Here’s what the entire process looks like:

Before starting the code deployment, you need an IAM user to ensure each component — repositories, EC2 instances, and CodeDeploy — has access to each other.

There are two ways to deploy your app using CodeDeploy— either from the CodeDeploy console or the AWS CLI. Whichever you choose, you’ll follow these steps to deploy your app:

1. Launch and configure your EC2 instances

This is the first step to deciding how many EC2 instances your app needs and launching them. You can do this manually or through an AWS CloudFormation template, making it easy to create instances quickly. To know where to deploy your code, tag instances or have them belong to an auto-scaling group for CodeDeploy.

Other AWS services use tags to identify instances. You can specify any combination of key-value pairs, but use the correct one in your AppSpec file, or your CodeDeploy deployment will not execute. The instances must have the CodeDeploy agent installed and running inside each.

1. Create your first revision

Create an empty root folder on your development machine where you store the text files, binaries, and packages that make up your app. Next, you need to create the AppSpec file in the same folder. You can use a template to include information about your code. You can include file names and their destinations, permissions as needed, and “Hooks” that inform CodeDeploy which scripts to run in what order during a deployment. You bundle all these files to form your first revision.

1. Upload to S3, GitHub, or BitBucket

Once your revision is ready, upload it to S3, GitHub, or BitBucket. From here, the CodeDeploy agent reads the AppSpec file—and from the “Hooks” section of the AppSpec file, it knows which scripts to run on the EC2 instances.

1. Deploy your app

CodeDeploy automatically deploys your app every time you upload a revision. It lets you define how to deploy your app. You can deploy your app on one instance at a time, on just half the instances first and the second half later, or on all instances. For large clusters, opt for a phased-out deployment. For smaller deployments, deploy all at once.

1. Monitor your deployment using CloudWatch

Once deployed, you can monitor your continuous deployment using AWS CloudWatch, which integrates with CodeDeploy. Ensure you’ve set the appropriate IAM access permissions for CloudWatch to track CodeDeploy events.

1. Rollback or redeploy as needed

If a continuous deployment fails, you can automatically set CodeDeploy to roll back to the previous revision. This automation is critical to ensuring uptime despite deployment errors. You can then troubleshoot errors and redeploy the revision when it’s fixed.

AWS is the most mature public cloud computing vendor. It has integrations with every possible IT vendor and cloud service to meet every niche requirement. CodeDeploy integrates with other DevOps tools.

• Amazon CodeDeploy – integrates with other AWS services like:
• Amazon CloudWatch – sets up rules for code deployments based on events and alarms. CloudWatch also collects log data for application deployment.
• Amazon CodePipeline – to visually manage your entire development pipeline
• Amazon CloudFormation – to create a large number of EC2 instances quickly
• Amazon Simple Notification Service – to receive SMS or email notifications for events like failed deployments

It has integrations with third-party tools that manage the workflow across the entire development lifecycle, including:

• GitHub and BitBucket, from where it pulls revisions to deploy
• Continuous Integration tools like Jenkins, CircleCI, and Atlassian Bamboo
• Configuration management systems such as Chef and Puppet

While configuration management tools focus on provisioning and managing instances, CodeDeploy focuses exclusively on deploying code to AWS EC2 instances once created. With these integrations, AWS has made it easy for CodeDeploy to be added to your development stack, no matter what mix of tools you use across your development pipeline.

CodeDeploy assigns a health status to every revision and EC2 instance. The revision status can be either “current,” “old,” or “unknown.” A “current” revision is when the revision on the EC2 instance matches the most recent revision in S3, GitHub, or BitBucket. “Old” revisions are when a revision on an instance matches an older revision in S3, GitHub, or BitBucket. “Unknown” is when there isn’t a match.

Similarly, for EC2 instances, CodeDeploy assigns a status of “healthy” or “unhealthy.” Successful deployments mean a healthy state, but deployment fails mean the instance is “unhealthy.”

Using these checks, you can set rules to deploy revisions only if there are a minimum number of healthy EC2 instances. These rules ensure your deployment doesn’t break even more instances.

You can set up alerts for your failed deployments using AWS SNS (Simple Notification Service) via CloudWatch alarms. Stopped or failed deployments can be monitored by looking at the CodeDeploy logs. These logs are stored for seven days by default. You could do basic log searching and filter from inside Amazon CloudWatch logs.

CodeDeploy is an essential tool for AWS dev shops moving to continuous delivery. Whether you perform in-place or blue-green deployments or host your app exclusively in AWS’ public cloud or a hybrid environment, with the need to integrate with other DevOps tools, CodeDeploy has you covered. It is invaluable to DevOps teams that want to speed up application delivery and not compromise on high availability.

Click here to learn more about AWS Monitoring with Sumo Logic.