Today I would like to tell you about a trio of new AWS tools
that are designed to help individual developers, teams of
developers, and system administrators store, integrate, and
deploy their code on the cloud. Here is the lineup, in the
order that you’d generally put them to use:
- AWS CodeDeploy –
This service efficiently deploys your released code to a “fleet” of
EC2 instances while taking care to leave as much of the fleet online
as possible. It can accommodate fleets that range in size
from one instance all the way up to tens of thousands of
- AWS CodeCommit –
This is a managed revision control service that hosts
and works with all Git-based tools.
You no longer need to worry about hosting, scaling, or
maintaining your own source code control infrastructure.
- AWS CodePipeline –
This service will help you to model and automate your software
release process. You can design a development workflow that
fits your organization’s needs and your working style and use it
to shepherd your code through the staging, testing, and release
process. CodePipeline works with third-party tools but is also
a complete, self-contained end-to-end solution.
We are launching AWS CodeDeploy today and you can start using it right away. I’ll share
additional information on the launch plans for the other two tools as it becomes
available. These tools were designed to work well independently and to provide
even more functionality and value when used together.
Let’s take a closer look at each of these tools!
CodeDeploy was designed to help you to deploy code at scale, with a
focus on rapid development and rapid deployment in mission-critical
situations where the cost of failure is high. As I mentioned
earlier, it was designed to update an EC2 fleet without the need for any
down time. CodeDeploy will automatically schedule
updates across multiple Availability Zones in order to maintain high
availability during the deployment process.
The fundamental unit of CodeDeploy work is
a Deployment. It copies an Application revision (a
collection of files) to a set of EC2 instances (a Deployment Group)
and can also run designated scripts throughout the deployment
process. YAML-formatted files are used to describe Applications and
Deployment Groups. A Deployment Group identifies a set of EC2
instances by tag name, and can also reference an Auto Scaling Group.
Each instance must be running a copy of the CodeDeploy Agent. This
is a small, open source (Apache 2.0 licensed) app that knows how to
copy and validate files, set up permissions, and run scripts on
Linux and on Windows. You can also configure it to run at startup on
your custom AMIs, and you can even install it manually on running instances.
You can use CodeDeploy from the AWS Management Console, the
Command-Line Interface, or through a set of APIs. For example, you
can initiate an entire deployment with one API call. CodeDeploy can
also be used in conjunction with your existing Chef recipes and Puppet scripts.
Let’s walk through the process of setting up and deploying an Application.
The CodeDeploy Console includes a handy demo option that I’ll use to get
started. While there are a lot of screens below, most of this is setup work
that you’ll do one and benefit from for a long time!
The demo uses a AWS CloudFormation template to launch three
EC2 instances, all tagged as
I begin by creating an Application:
Then I create a versioned Revision for deployment. My sample revision
is stored in S3, but it could also come from CodeCommit or GitHub:
I need to tell CodeDeploy which IAM role to use when it interacts with other AWS services
like EC2 or Auto Scaling (I can create a new one or use an existing one):
Now I need a Deployment Configuration. I can pick one of the defaults or I can create
one from scratch. Here are the three default Deployment Configurations (these
should be self-explanatory):
Here’s how I would create a custom Deployment Configuration:
Now I can review the settings and perform my first deployment:
The Application is deployed per my Deployment Configuration and the Console
updates as the work proceeds:
Once I have taken care of the setup work, I can easily create more Deployments and
deploy them with a couple of clicks:
Your application’s source code is a concrete representation of your
intellectual property. It is also the most visible artifact of the
hours that you spend slaving away at the keyboard! AWS CodeCommit is
designed to keep it safe and sound. As I have already mentioned, it
is a managed revision control service that hosts Git
repositories. Your existing Git skills, tools (command line and
IDE), and practices will continue to be applicable.
You (or your organization’s Cloud Administrator) can simply create a
CodeCommit repo, assign permissions, and open it up to
commits. CodeCommit will store code, binaries, and metadata in
redundant fashion with high availability. You will be able to
collaborate with local and remote teams to edit, compare, sync, and
Because CodeCommit runs in the AWS Cloud, it will work
really well in situations where your development team works from
multiple locations or involves collaboration with vendors or other
partners (no more punching holes in corporate firewalls). You don’t
have to worry about running out of space (go ahead, check in those
images and videos). CodeCommit encrypts your files at checkin time
and uses IAM roles to control developer and administrative access.
Here’s a sneak peek at a preliminary version of the CodeCommit Console:
I’ll publish a more detailed blog post at launch time, so stay tuned.
Presumably, your release process is more complex and more robust than
“run a smoke test and ship it if nothing explodes!” As the process becomes
more complex, automation becomes more and more valuable.
AWS CodePipeline will help you to codify and automate your release process. It
should make your entire process more robust and more efficient. You’ll spend
more time on features and less time on infrastructure. You will be able to
test each code change as you make it, with the assurance that it will
have pass through whatever test gates that you define before it is released to
You will be able to use the CodePipeline user interface to construct a
graphical model of your release process using a combination of serial and
parallel actions. The workflow can include time-based or manual approval gates
between each stage. For example, you could choose to deploy new changes to
staging servers only during weekday working hours in your own time zone.
CodePipeline watches your source code repo for changes and triggers the
appropriate workflow. A release workflow could build the code in a
production build tree, run test cases, and deploy tested code to a
staging server. Upon final approval (a manual gate), the code can be
promoted to production and widely deployed.
Here’s a sneak peek at the CodePipeline Console:
CodeDeploy is launching today and you can start using it now. Please stay tuned for more
information on CodeCommit and CodePipeline!