Skip to main content

Amazon CodeDeploy

Amazon CodeDeploy FAQs

Page topics

General

Open all

Amazon CodeDeploy is a service that automates code deployments to any instance, including Amazon EC2 instances and instances running on-premises. Amazon CodeDeploy makes it easier for you to rapidly release new features, helps you avoid downtime during deployment, and handles the complexity of updating your applications. You can use Amazon CodeDeploy to automate deployments, eliminating the need for error-prone manual operations, and the service scales with your infrastructure so you can easily deploy to one instance or thousands.

AmazonCodeDeploy is designed for developers and administrators who need to deploy applications to any instance, including Amazon EC2 instances and instances running on-premises. It is flexible and can also be used by anyone wanting to update software or run scripts on their instances.

Amazon CodeDeploy can be used for deploying any type of application. To use Amazon CodeDeploy, you specify the files to copy and the scripts to run on each instance during the deployment. Amazon CodeDeploy is programming language and architecture agnostic, so you can use scripts for any custom deployment logic.

Amazon CodeDeploy supports a wide variety of operating systems. Amazon CodeDeploy provides agents that have been tested on Amazon Linux, Red Hat Enterprise Linux, Ubuntu Server, and Microsoft Windows Server. If you want to use other operating systems, the Amazon CodeDeploy agent is available as open source software here. For more information on operating system support, see Amazon CodeDeploy Documentation.

Yes. Amazon CodeDeploy works with a variety of configuration management systems, continuous integration and deployment systems, and source control systems.

Amazon CodeDeploy is a building block service focused on helping developers deploy and update software on any instance, including Amazon EC2 instances and instances running on-premises. Amazon Elastic Beanstalk and Amazon OpsWorks are end-to-end application management solutions.

Yes. Amazon CodeDeploy supports any instance that can install the CodeDeploy agent and connect to Amazon Web Services public endpoints.

Concepts

Open all

An application is a collection of software and configuration to be deployed to a group of instances. Typically, the instances in the group run the same software. For example, if you have a large distributed system, the web tier will likely constitute one application and the data tier another application.

A revision is a specific version of deployable content, such as source code, post-build artifacts, web pages, executable files, and deployment scripts, along with an AppSpec file. The Amazon CodeDeploy Agent can access a revision from GitHub or an Amazon S3 bucket.


A deployment group is a set of instances associated with an application that you target for a deployment. You can add instances to a deployment group by specifying a tag, an Auto Scaling group name, or both. You can define multiple deployment groups for an application such as staging and production. For information on tags, see Working with Amazon EC2 Tags in the Console. For more information on deploying to Auto Scaling groups, see Auto Scaling Integration.


A deployment configuration is a constraint that determines how a deployment progresses through the instances in a deployment group. You can use a deployment configuration to perform zero-downtime deployments to multi-instance deployment groups. For example, if your application needs at least 50% of the instances in a deployment group to be up and serving traffic, you can specify that in your deployment configuration so that a deployment does not cause downtime. If no deployment configuration is associated with either the deployment or the deployment group, then by default Amazon CodeDeploy will deploy to one instance at a time. For more information on deployment configuration, see Instance Health.

There are three parameters you specify for a deployment:
  • Revision - Specifies what to deploy.
  • Deployment group - Specifies where to deploy.
  • Deployment configuration - An optional parameter that specifies how to deploy.
    •

    An AppSpec file is a configuration file that specifies the files to be copied and scripts to be executed. The AppSpec file uses the YAML format, and you include it in the root directory of your revision. The AppSpec file is used by the Amazon CodeDeploy Agent and consists of two sections. The files section specifies the source files in your revision to be copied and the destination folder on each instance. The hooks section specifies the location (as relative paths starting from the root of the revision bundle) of the scripts to run during each phase of the deployment. Each phase of a deployment is called a deployment lifecycle event. The following is a sample AppSpec file. For more information on an AppSpec file, including all the options that can be specified, see AppSpec File Reference.

    version: 0.0

os: linux

files: 

# You can specify one or more mappings in the files section.

  - source: /

    destination: /var/www/html/WordPress

hooks:

 # The lifecycle hooks sections allows you to specify deployment scripts.

ApplicationStop: 

# Step 1: Stop Apache and MySQL if running.

    - location: helper_scripts/stop_server.sh

BeforeInstall: 

# Step 2: Install Apache and MySQL.

# You can specify one or more scripts per deployment lifecycle event.

    - location: deploy_hooks/puppet-apply-apache.sh

    - location: deploy_hooks/puppet-apply-mysql.sh 

 AfterInstall: 

# Step 3: Set permissions.

    - location: deploy_hooks /change_permissions.sh

      timeout: 30

      runas: root

# Step 4: Start the server.

    - location: helper_scripts/start_server.sh

      timeout: 30

      runas: root

    A deployment goes through a set of predefined phases called deployment lifecycle events. A deployment lifecycle event gives you an opportunity to run code as part of the deployment. The following table lists the different deployment lifecycle events currently supported, in their order of execution, along with examples of when you may want to use them.

    Deployment Lifecycle Event Description
    ApplicationStop

    This is the first deployment lifecycle event that occurs even before the revision gets downloaded. The AppSpec file and scripts used for this deployment lifecycle event are from the last successfully deployed revision.  

    You can use the ApplicationStop deployment lifecycle event if you want to gracefully stop the application or remove currently installed packages in preparation of a deployment.
    DownloadBundle During this deployment lifecycle event, the agent copies the revision files to a temporary location on the instance. This deployment lifecycle event is reserved for the agent and cannot be used to run user scripts.
    BeforeInstall You can use the BeforeInstall deployment lifecycle event for preinstall tasks such as decrypting files and creating a backup of the current version.
    Install During this deployment lifecycle event, the agent copies the revision files from the temporary location to the final destination folder. This deployment lifecycle event is reserved for the agent and cannot be used to run user scripts.
    AfterInstall You can use the AfterInstall deployment lifecycle event for tasks such as configuring your application or changing file permissions.
    ApplicationStart You typically use the ApplicationStart deployment lifecycle event to restart services that were stopped during ApplicationStop.
    ValidateService ValidateService is the last deployment lifecycle event and is an opportunity to verify that the deployment completed successfully.

    Getting started

    Open all

    You can sign in to the Amazon Web Services Management Console and start using Amazon CodeDeploy. If you are looking for a quick overview of the service, see Getting Started, which includes a step-by-step tutorial.

    Using Amazon CodeDeploy

    Open all

    The Amazon EC2 instance must be associated with an IAM instance profile and should be running a supported operating system. For more information, see Use an Existing Amazon EC2 Instance.

    The following diagram shows the typical steps during a deployment. Creating an application and deployment group (see the Concepts section for an explanation of these terms) are typically one-time setup tasks per application. The recurring actions are uploading a revision and deploying it. For a detailed explanation, including step-by-step instructions for each of these tasks, see Deployments.

    You can access Amazon CodeDeploy using the Amazon Web Services Management Console, the Amazon SDKs, and the Amazon CodeDeploy APIs.

    You don’t need to make any changes to your code. You simply add a configuration file (called an AppSpec file) in the root directory of your revision bundle that specifies the files to be copied and scripts to be executed.

    If you are using GitHub, you can deploy a revision in a .zip, .tar, or .tar.gz format from your repository directly to instances. For other source control systems, you can bundle and upload the revision to an Amazon S3 bucket in a .zip, .tar, or .tar.gz format and specify the Amazon S3 location when doing a deployment. If your application needs a build step, make sure that the GitHub repository or the Amazon S3 bucket contains the post-build artifacts. For more information on using Amazon S3 for storing revisions, see Push a Revision.

    You can invoke your configuration management tool from any deployment lifecycle event hook in the AppSpec file. For example, if you have a Chef recipe that you want to run as part of a deployment, you can do so by specifying it in the appropriate deployment lifecycle event hook in the AppSpec file. In addition, you can leverage your configuration management system to install the Amazon CodeDeploy agent on instances.

    Yes. You can integrate Amazon CodeDeploy with your continuous integration and deployment systems by calling the public APIs using the Amazon SDKs.

    Deploy the latest revision to the deployment group for the newly added instances to get your application. Except for Amazon EC2 instances that are launched as part of an Auto Scaling group, Amazon CodeDeploy doesn’t automatically deploy the latest revision to newly added instances.

    You can associate an Auto Scaling group with a deployment group to make sure that newly launched instances always get the latest version of your application. Every time a new Amazon EC2 instance is launched for that Auto Scaling group, it will be first put in a Pending state and a deployment of the last successful revision for that deployment group triggered on that Amazon EC2 instance. If the deployment completes successfully, the state of the Amazon EC2 instance is changed to InService. If that deployment fails, the Amazon EC2 instance is terminated, a new Amazon EC2 instance is launched in Pending state, and a deployment triggered for the newly launched EC2 instance. For more information on Auto Scaling group instance lifecycle events, see Auto Scaling Group Lifecycle.

    You can track the status of a deployment using the Amazon Web Services Management Console, the Amazon SDKs, and the Amazon CodeDeploy APIs.You can see the overall status of a deployment and drill down further to see the status of each instance and the status of each deployment lifecycle event for the instance. You can also see the log entries corresponding to any failure, making it easy to debug deployment issues without having to log into the instance.

    Yes. When you stop an in-flight deployment, the Amazon CodeDeploy service will instruct the agent on each instance to stop executing additional scripts. To get your application back to a consistent state, you can either redeploy the revision, or deploy another revision.

    To roll back an application to a previous revision, you just need to deploy that revision. Amazon CodeDeploy keeps track of the files that were copied for the current revision and removes them before starting a new deployment, so there is no difference between redeploy and roll back. However, you need to make sure that the previous revisions are available for roll back.

    Yes. You can use a versioned Amazon S3 bucket and specify the version ID to uniquely identify a revision.

    For information on the service limits, sew Limits. To increase your service limits, submit a request through the Amazon Web Services Support Center in the Management Console.

    Yes. To receive a history of Amazon CodeDeploy API calls made on your account, you simply turn on Amazon CloudTrail in the Amazon Web Services Management Console.

    Security

    Open all

    Yes, but the Amazon CodeDeploy agent installed on the Amazon EC2 instances must be able to access the public Amazon CodeDeploy and Amazon S3 service endpoints. For more information, see Amazon Web Services Endpoints for China Regions.

    Yes. Amazon CodeDeploy supports resource-level permissions. For each Amazon CodeDeploy resource, you can specify which user has access and to which actions. For example, you can set an IAM policy to let a user deploy a particular application but only list revisions for other applications. You can therefore prevent users from inadvertently making changes to the wrong application. For more information on using IAM with Amazon CodeDeploy, see Access Permissions Reference.

    Regions

    Open all

    Please refer to Regional Products and Services for details of CodeDeploy availability by region.