5. What To Expect from This Session
• Review continuous integration, delivery, and deployment
• Using Docker images, Amazon ECS, and Amazon ECR for
CI/CD
• Deployment strategies with Amazon ECS
• Building Docker container images with AWS CodeBuild
• Orchestrating deployment pipelines with AWS CodePipeline
• Demo
9. How can we quickly and reliably
deliver good ideas to our
customers?
10. Learnings
• Frequency reduces difficulty
• Latency between check-in and production is
waste
• Consistency improves confidence
• Automation over toil
• Empowered developers make happier teams
• Smaller batch sizes are easier to debug
• Faster delivery improves software
development practices
11. Source Build Test Production
• Version Control
• Branching
• Code Review
• Compilation
• Unit Tests
• Static Analysis
• Packaging
• Integration Tests
• Load Tests
• Security Tests
• Acceptance
Tests
• Deployment
• Monitoring
• Measuring
• Validation
19. Best Practices
• Pin external dependencies to specific
versions for reproducibility
• Package only the runtime requirements for
production
• Minimize changes in each layer to maximize
cache-ability
• Maintain a .dockerignore file to exclude
unneeded files from the image
22. AWS CodeBuild
Build and test code with continuous
scaling with pay-as-you-go pricing
• Build and test projects across platforms and runtimes
including Java, Ruby, Python, Android, Docker, etc.
• Never pay for idle time
• Fully extensible to other platforms through custom build
environments
23. Build Specification – Phases
Phase Description Examples
install Installation of packages into the
environment
Install testing frameworks
e.g. RSpec, Mocha
pre_build Commands to run before the build
such as login steps or installation of
dependencies
Log in to Amazon ECR.
run Ruby bundler or npm
build Sequence to run the build such as
compilation and/or running tests
Run go build, sbt, Mocha,
RSpec
post_build Commands to run after a build on
success or failure
Build a JAR via Maven or
push a Docker image to
Amazon ECR
25. Best Practices
• Tag output artifacts to source control
revisions (e.g. git SHA, semantic version)
• Avoid using a “latest” or “production” tag
• Optimize for build speed
• Collocate build process with its artifact
repository
30. Deployment – In Place – Doubling
Availability Zone Availability Zone
Scenario
Service’s task definition is
updated to a new revision with
parameters:
Desired Count = 2
Minimum Healthy Percent = 100%
Maximum Percent = 200%
These settings permit the service
to grow to double its desired size
during deployment
EXISTING EXISTING
31. Deployment – In Place – Doubling
Availability Zone Availability Zone
Two new tasks are started
growing the number of tasks to
200% of its desired count which is
the maximum permitted
EXISTING EXISTINGNEW NEW
Desired Count = 2
Minimum Healthy Percent = 100%
Maximum Percent = 200%
32. Deployment – In Place – Doubling
Availability Zone Availability Zone
After the new tasks are verified to
be healthy by the Elastic Load
Balancer health check, the two
previous tasks with the older task
definition are drained and stopped
NEW NEW
Desired Count = 2
Minimum Healthy Percent = 100%
Maximum Percent = 200%
33. Deployment – In Place – Rolling
Availability Zone Availability Zone
Scenario
Service’s task definition is
updated to a new revision with
parameters:
Desired Count = 2
Minimum Healthy Percent = 50%
Maximum Percent = 100%
These settings constrain the
service to not exceed its desired
size but allows it to halve the
number of tasks during
deployment
EXISTING EXISTING
34. Deployment – In Place – Rolling
Availability Zone Availability Zone
First, an existing task is stopped
which brings the healthy
percentage of the service to 50%
and makes room on the cluster for
new tasks
EXISTING
Desired Count = 2
Minimum Healthy Percent = 50%
Maximum Percent = 100%
35. Deployment – In Place – Rolling
Availability Zone Availability Zone
A task using the new task
definition is started bringing the
service back to 100%
EXISTING
Desired Count = 2
Minimum Healthy Percent = 50%
Maximum Percent = 100%
NEW
36. Deployment – In Place – Rolling
Availability Zone Availability Zone
After the new task is verified to be
healthy by the Elastic Load
Balancer health check, the next
existing task with the older task
definition is drained and stopped
Desired Count = 2
Minimum Healthy Percent = 50%
Maximum Percent = 100%
NEW
37. Deployment – In Place – Rolling
Availability Zone Availability Zone
The second new task is started on
the cluster bringing the service
back to 100%
NEW NEW
Desired Count = 2
Minimum Healthy Percent = 50%
Maximum Percent = 100%
38. Deployment – Canary
Availability Zone Availability Zone
Scenario
The new revision runs as a small
subset of production by deploying
a canary service in the same
target group
Deployment is completed by
updating the primary service’s
task definition and scaling down
the canary service. EXISTING EXISTINGEXISTING
39. Deployment – Canary
Availability Zone Availability Zone
A standalone service with the new
task definition is deployed using
the same Application Load
Balancer target group of the
existing service
EXISTING EXISTINGEXISTING CANARY
40. Deployment – Canary
Availability Zone Availability Zone
After some period of monitoring
the metrics from the canary
instance, the existing service’s
task definition is updated to the
new revision
NEW NEWNEW CANARY
41. Deployment – Canary
Availability Zone Availability Zone
After the deployment, all tasks are
running the same task definition
with the new revision of the
application and the canary can be
destroyed
NEW NEWNEW
42. Deployment – Blue/Green – DNS Swap
Availability Zone
EXISTING EXISTING
www.myproduct.com
Scenario
Two services are defined each
with their own Application Load
Balancer
Deployment is completed by
swapping the Route 53 alias
record between the two
Application Load Balancers
Availability Zone
43. Deployment – Blue/Green – DNS Swap
Availability Zone
EXISTING EXISTING
www.myproduct.com
An identical Application Load
Balancer and a service with a task
definition using the new revision is
deployed
Availability Zone
NEW NEW
next.myproduct.com
44. Deployment – Blue/Green – DNS Swap
Availability Zone
EXISTING EXISTING
next.myproduct.com
After automated or manual
testing, the deployment is
completed by swapping the Route
53 alias record between the two
Application Load Balancers
Availability Zone
NEW NEW
www.myproduct.com
45. Deployment – Blue/Green – DNS Swap
Availability Zone
The previous service and its
Application Load Balancer can
then be destroyed
Availability Zone
NEW NEW
www.myproduct.com
46. Deployment – Blue/Green – Target Group Swap
Availability Zone
EXISTING EXISTING
Scenario
Two services are defined each
with their own target group
registered in the same Application
Load Balancer using Host-based
routing
Deployment is completed by
swapping the listener rules
between the two target groups
Availability Zone
47. Deployment – Blue/Green – Target Group Swap
Availability Zone
EXISTING EXISTING
The second service is deployed
with a new target group and
registered to the same Application
Load Balancer
Using Host-based routing, requests
to www.myproduct.com are
directed to our blue service while
requests to next.myproduct.com
are directed to our green service NEW NEW
Availability Zone
48. Deployment – Blue/Green – Target Group Swap
Availability Zone
After automated or manual testing,
the deployment can be completed
by swapping the listener rules on
the Application Load Balancer and
sending traffic to the green service
NEW NEW
Availability Zone
EXISTING EXISTING
49. Deployment – Blue/Green – Target Group Swap
Availability Zone
The previous service and its target
group can then be destroyed
NEW NEW
Availability Zone
50. Best Practices
• Use Elastic Load Balancing health checks to
prevent botched deploys
• For higher confidence, integrate automated
testing against a new environment or
monitoring of a canary before cutover
• Ensure your application can function against
the same backend schema for adjacent
releases
54. AWS CodePipeline
Model deployment pipelines through a visual workflow
interface which build, test, and deploy new revisions on
code changes
• Integrates with AWS services, open source and third
party tools for building, testing, and deploying code
• Extend deployment pipelines with custom logic through
AWS Lambda functions or custom actions
• Allows operators to block transitions to “stop the line”
and manual approval steps
