from 0 to continuous delivery in 30 minutes

copyright 2015 Trainologic LTD
From Zero to
Continuous Delivery

2 copyright 2015 Trainologic LTD
• Continuous Delivery (CD) is a hot topic these days.
• Considered as a silver bullet for DevOps teams.
• In this session we’ll:
• Describe the Deployment Pipeline.
• Overview the tools.
• Describe best-practices.
Continuous Delivery
2
From Zero to Continuous Delivery

• The goals:
• Find bugs earlier
• Improve time-to-market
• Reduce manual work
• Dashboard (Monitoring)
Continuous Delivery
3

The Pipeline
4
Code
Committed
CI
Integration
Test
Deploy to
Staging
UAT
Deploy to
Prod

• The developers are responsible for writing Unit and
Integration tests (and the code of-course).
• And they commit their changes into the SCM.
• The SCM is a crucial tool in the process!
• (Branches, Labels, Diffs)
It All Starts From…
5

• Only hand-written code and configuration files should
reside in your SCM.
• Never store anything that is binary or generated there!
• Try to choose a tool which provides hooks that can
notify external applications on commits.
Important Practices (SCM)
6

• A good Continuous Integration
(CI) process stands at the
heart of a good CD pipeline.
• Your CI tool should start its
work (job) when it was
notified by the SCM over a
commit. (polling is also an
option).
The Beast (CI)
7

CI
8

• Your CI Tool should (in first phase):
• Compile your code and tests (if needed).
• Run Unit tests
• Run Static Code Analysis.
• Package
• Run Integration Tests
• Deploy to Binary Repository.
The “classic” CI Role
9

1
0
• Often, you’ll want to have several CI machines.
• For running resource intensive tests (load, security,
gui).
• Can be also used to parallelize tests.
Several CI Machines
10

1
1
• Never, ever, run the build with tests disabled!
• Failure of build should notify the committing developers.
• Build should be fast! (unit-tests).
• Build results should be visible to everyone.
Important Practices (CI)
11

1
2
• Very important to minimize the technical debt!
• There are many tools in the market: FindBugs, Sonar,
PMD, CheckStyle.
• It is important to take the time and adjust the rules of
these tools.
• It is important to minimize the noise (false positives) as
it will result in ignoring the reports.
• Fail the build if code quality is poor!
Code Quality
12

1
3
Code Quality
13

1
4
• Integration tests are very important.
• Keep the tests self-contained:
• Deploy the artifact to the container
• Initialize the DB
• Test
• Undeploy and clear after you’re done.
Integration Tests
14

1
5
• Holds the ‘artifacts’ of the build.
• Everything should be either in the SCM (hand-written
files) or in the binary repository (build artifacts).
• Everything should be versioned.
The Binary Repository
15

1
6
• Never, ever, allow for overriding release artifacts.
• Only the CI (automated) user should be allowed to
deploy a release artifact.
• Every artifact has to be linked to a SCM label!
• Make it HA (without it everything is down).
Important Practices (Repository)
16

1
7
• When moving towards CD, your CI process should also
start the distribution into the staging machines.
• CM tool is a must.
• Especially for cluster environments.
• Deployables should only be taken from the binary
repository!
CI and CD
17

1
8
• The ‘enabler’ of the CD.
• Main concern: sync the environments with the master
configuration!
The CM Tool
18

1
9
• Responsible mainly for:
• Orchestration
• Configuration Synchronization
• Deployments
CM Tools
19

2
0
Puppet – Deploy Web App
20
tomcat::war { 'sample.war':
catalina_base => '/opt/apache-tomcat/tomcat8',
war_source => '/opt/apps/bankapp.war',
}

2
1
• The Staging environment must be the same as the
production one.
• Everything that can be tested automatically should be in
the process.
• What about manual tests?
Staging
21

2
2
• User Acceptance Tests are an important part of a good
CD.
• Especially in a complex product.
UAT
22

2
3
• UAT is usually done by SME (Subject Matter Experts).
• Gather as much automated feedback as possible.
• Manual feedback should be gathered using a user-
friendly tool.
UAT
23

2
4
• In order to avoid multiple branches, you should use
feature toggles.
• “Just ‘if’s in your code”.
• Allowing for developers to even commit unfinished code.
• Can be a simple boolean, or even an enum or list.
• Now we can do a real ‘daily commit’.
Feature Toggles
24

2
5
• Everything should be monitored!
Monitoring
25

2
6
• You should monitor:
• System Resources (CPU, Memory, Paging,…)
• Container Resources (e.g.: Docker)
• Technology specifics (e.g.: GC)
• KPIs
• Logs
• Save aggregated output for baseline comparison.
Monitor
26

2
7
• Log monitoring is crucial.
• Not only for the application.
• Also for DBs, Mail Servers and Application Containers.
• There are tools that enable real-time log monitoring.
• E.g.:
• Logstash+ElasticSearch+Kibana+Graphite
Logging
27

2
8
• You can add a CD dashboard to Jenkins:
Dashboard
28

2
9
• Well, CD not necessarily the last step.
• Now that we have a trustable-deployable artifact, we
can optionally do continuous deployment.
• Again, we’ll use the CM tools to deploy to the production
machines.
• Keep in mind to monitor everything and rollback on
need!
The End (is near?)
29

3
0
• CD is important.
• But it must be done right.
• Not only tools (which are important).
• But mainly tests (unit, integration, regression, load,
performance, security, acceptance,…).
• Invest in Developers and DevOps culture!
END
30

from 0 to continuous delivery in 30 minutes

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (16)

Similar to from 0 to continuous delivery in 30 minutes

Similar to from 0 to continuous delivery in 30 minutes (20)

More from AgileSparks

More from AgileSparks (20)

Recently uploaded

Recently uploaded (20)

from 0 to continuous delivery in 30 minutes