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



• 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


• 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


• 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


• 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


Code Quality

13


1


• 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


• 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


• 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


• 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


• The ‘enabler’ of the CD.

• Main concern: sync the environments with the master

configuration!

The CM Tool

18


1


• Responsible mainly for:

• Orchestration

• Configuration Synchronization

• Deployments

CM Tools

19


2


Puppet – Deploy Web App

20


tomcat::war { 'sample.war':

catalina_base => '/opt/apache-tomcat/tomcat8',

war_source => '/opt/apps/bankapp.war',

}

2


• 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


• User Acceptance Tests are an important part of a good

CD.

• Especially in a complex product.

UAT

22


2


• 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


• 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


• Everything should be monitored!

Monitoring

25


2


• 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


• 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


• You can add a CD dashboard to Jenkins:

Dashboard

28


2


• 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


• 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

Software

continuous delivery

continuous delivery

ci tool

unit tests

important practices

ci integration test

ci machines

tests selfcontained