This document discusses continuous integration (CI) and continuous delivery (CD). It defines CI as frequently integrating work and verifying it through automated builds and tests. It defines CD as ensuring every change can be released and any version can be deployed with the push of a button. The document outlines why organizations adopt CI/CD, advanced concepts like infrastructure as code, and provides recommendations for implementing CI/CD such as starting small, automating tasks, and forming cross-functional teams.

1. Continuous Integration (CI)
& Continuous Delivery (CD)
Rethink your software Delivery
EMEA PUG Challenge, 06-10-
2016
Joost van der Griendt

2. Who are we?
Flusso
• One of biggest OpenEdge consultancy firms in NL
• Progress technologies,
• Open Source (Java & ServiceMix, etc),
• Web Apps (Angular2, various app platforms)
• OutSystems
• CI/CD Consultancy

3. Who are we?
Joost van der Griendt
Java Developer since 2005, Automation Engineer since
2009
Flusso since 2011, currently CI/CD Consultant at ABN
AMRO

4. Overview
• What is CI/CD
• Why CI/CD
• Advanced concepts
• How can you implement it
4

5. Not discussed
• Automated tests & Test Pyramid
• Self testing code
• Trunk Based Development
• Branching strategies
• Engineering Effectiveness
5

6. Software Lifecycle & CI/CD
• How quickly can you get a single line of code into
production?
• Can you do this on a repeatable and reliable basis?
• Different for new product or an existing product?
6

7. Continuous Integration
“CI is a practice where members of a team integrate their
work frequently, preferably daily - leading to multiple
integrations per day. Each integration is verified by an
automated build (including tests) to detect errors as quickly
as possible.” – Martin Fowler
7

8. Continuous Delivery
"[CD] is an approach in which teams ensure that every
change to the system is releasable, and that we can release
any version at the push of a button. CD aims to make
releases boring, so we can deliver frequently and get fast
feedback on what users care about.“ – Thought Works
8

9. How do CI and CD relate
9
Build IntegrateCode Release DeployTest Operate
Agile Development
Continuous Integration
Continuous Delivery
Continuous Deployment
DevOps

10. Why Continuously Deliver
10

11. Key Principles
11
•The smaller the changes, the easier it is to integratethem
•Everyone is always up-to-date and you test the end result
Integrate Early & Often
•Automate repetitive and mundane tasks; let humans focus on what they do best
•If it hurts, do it more often, make tough tasks boring by doing them over and over
Automate
•Every change should be shippable to live, not live is no value
•Verify automatically it meets all requirements
Build Quality In
•We work on a Product/Value together, anything good or bad impacts all
•Enables "Boy Scout Rule“ & continuously improve the product
Shared Responsibility
•Work with metrics and facts, gather them at every step and use as input for the next iteration
•Make improvement of the Product and Build Pipeline core task of everyone
Continuous Feedback

12. Advanced Concepts
• Infrastructure As Code
• Configuration As Code
• Pipelines (as code)
• Maturity Model
12

13. Infrastructure As Code
“The enabling idea of infrastructure as code is that the systems and
devices which are used to run software can be treated as if they,
themselves are code.” - Kief Morris
13

14. Configuration As Code
Manual commands Hoard knowledge Manage items
individually
Write
documentation
Change Production
directly
Make it a
definition
Version everything Use Templates Live documentation Changes through
stages
14

15. “A deployment pipeline is a way to deal with this by breaking up your build into
stages.
Each stage provides increasing confidence, usually at the cost of extra time.
Early stages can find most problems yielding faster feedback, while later stages
provide slower and more through probing.
Deployment pipelines are a central part of ContinuousDelivery.” - Martin Fowler
15
Pipeline as Code

16. 16

17. Rome wasn’t built in a day
• It’s about People, Process & Technology
• It’s hard, really hard to do
• Conway’s Law
• Use a maturity model
• Identify low hanging fruit
17

18. 18

19. Deploy 10x a day
• Can you?
• Are you confident about it?
• Tell your team that tomorrow you will deploy 10 changes into
production!
19

20. 20

21. Do’s & Don’ts
Don’t
• form a CD team
• task one department to create a CD flow
• automate inside a CD tool
• add tools first, change the people/process later
from Victor Farcic
21

22. Do’s & Don’ts
Do
• form a multifunctional and autonomous team capable of delivering a service
• include someone with CD experience inside the team
• choose an easy target
• trust the team
• short iterations
from Victor Farcic
22

23. 23

24. Flusso & CI/CD
24
Download this presentation at:
www.flusso.nl/pug16-cicd/

25. Resources
• http://vfarcic.github.io/continuous-deployment-best-
practices/index.html#/cover
• http://www.gigamonkeys.com/flowers/
• https://medium.com/@aboodman/in-march-2011-i-drafted-an-article-
explaining-how-the-team-responsible-for-google-chrome-ships-
c479ba623a1b#.vmhahnczd
• https://www.thoughtworks.com/insights/blog/enabling-trunk-based-
development-deployment-pipelines
• https://www.thoughtworks.com/insights/blog/demystifying-conways-law
25

26. References
• http://www.stellarin.com/services/outsourced-development
• https://www.infoq.com/articles/Continuous-Delivery-Maturity-Model
26