The document discusses deploying code changes quickly through continuous integration, delivery, and deployment practices. It advocates for having a single code repository ("one trunk"), automated builds and testing on every commit, deploying to staging frequently, and aiming to deploy changes within hours or less. This allows for early feedback, catching issues early, and responding quickly to change requests from customers through incremental and frequent deliveries.

1. @paul_boocock paulboocock@codeweavers.net
One Trunk, One Pipeline, One Truth

2. Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

3. Question
How long would it take your business to safely deploy a change that involves
one line of code to the production environment?
Within Six Months?

4. Question
How long would it take your business to safely deploy a change that involves
one line of code to the production environment?
Within Three Months?

5. Question
How long would it take your business to safely deploy a change that involves
one line of code to the production environment?
Within One Month?

6. Question
How long would it take your business to safely deploy a change that involves
one line of code to the production environment?
Within One Week?

7. Question
How long would it take your business to safely deploy a change that involves
one line of code to the production environment?
Within One Day?

8. Question
How long would it take your business to safely deploy a change that involves
one line of code to the production environment?
Within One Hour?

9. Question
How long would it take your business to safely deploy a change that involves
one line of code to the production environment?
Within 30 Minutes?

10. Question
How long would it take your business to safely deploy a change that involves
one line of code to the production environment?
Within 15 Minutes?

11. Question
How long would it take your business to safely deploy a change that involves
one line of code to the production environment?
How Low?!?

12. Cycle Time
Lowering Cycle Time is something to strive for
Can be achieved through automation
Creating a reliable, predictable, visible and largely automated process
with well understood risks.

13. Caveats
Co-located team (works best)
SaaS Platform perhaps makes this easier?
Unknown how well it scales beyond mid sized development teams
Will probably require some time upfront
No branching (and no merging!)

14. Lets talk about Version Control

15. One Trunk

16. Continuous Integration
Source Control (Centralised)
Commit Frequently
Automatic Builds
Automated Tests
Staging Environment
Build Fast
Build Every Commit
Make it visible

17. Commit & Deploy Frequently
Date Commits
Staging
Deploy
Production
Deploy
Monday 0 0 0
Tuesday 154 119 115
Wednesday 220 70 56
Thursday 236 123 157
Friday 79 47 51
w/c 1st May 2017
Bank
Holiday!

18. The Pipeline
So with all these features in place, how does it all stitch together?

19. The Truth
This means our local environment is only a few commits ahead of live
This effectively gives us one truth for our entire codebase
We’re always in sync with one another

20. A few extra ideas for you…

21. Early Feedback
The build and tests should be fast – go parallel if possible
Test coverage should be high – aim for 75%+
If it breaks we cannot continue
Prevents defects getting to production

22. Every commit can be released
Every commit should be safe enough to be deployed to production
Commits should be as small as possible – single file?!?
Our statistics shows fewer failures with smaller commits

23. Every commit can be released
Usually leads to better code quality and maintainability
Can use feature toggles if required but try to avoid
Blue Green Deployments are a nice way to avoid these

24. Working software over comprehensive documentation

25. Deploy Frequently
Every commit should be deployable
So deploy them!
Get early feedback on feature from clients
Allows customers to change the direction
Ensure any issues can be found earlier

26. Done when released
Deliverables are not done until they are at least in production
Kanban board reflects this
Only done when delivering value to the customer
Customer should be involved!

27. Customer collaboration over contract negotiation
Responding to change over following a plan

28. CI Essentials
Unable to check in when build is broken
Run all tests before committing
Never go home on a broken build
Be ready to revert
Don’t comment out failing tests
Take responsibility

29. Everybody is responsible
Ensure that everybody is involved in deploying their commits
Take ownership of your own work
Fail early / feedback fast so you can fix it quickly
No one person responsible for deployment
Remove the barriers in your teams

30. Pair Programming
Not doing it? Start! Or at least try it.
Our statistics shows fewer failures when pairing
Your quality will increase
You will go faster

31. Individuals and interactions over processes and tools

32. Your computer is disposable
Imagine a world where your computer gets re-imaged every evening
A clean slate to work from every morning
How would your way of working change?

33. To summarise…
Iterate & delivery quickly
Reduce bottlenecks
Increases visibility
Work Sustainably
And occasionally…
Break things (but we can fix them quickly!)

34. Thank you!