2. Eduards Sizovs
Founder & Consultant
... Interested in bringing Continuous Delivery to your
company?
No problem! Just let us know
Software development
& consulting
www.craftsmans.lv
@eduardsi
eduards.sizovs@gmail.com
14. Redefine «Done»
Coded Reviewed Checked-in Built Tested Demoed
Released to end-user.
According to the latest trends: removed from production
(A/B, experiments, backward compatibility)
15. How long would it take your organization to deploy a
change that involved just one single line of code?
Do you do this on a repeatable, reliable basis?
Mary & Tom Poppendieck
Implementing Lean Software Development
Determine cycle time
16. Reduce risk of release
« If it hurts, do it more frequently »
36. Avoid branches
- True Continuous Integration - work only in mainline
- No feature branches
- No release branches
37. «Feature branching is a
poor man’s modular architecture»
Dan Bodart
Build a modular platform of micro-services.
... Interested in bringing Micro Services to your company?
No problem! Just let us know
www.craftsmans.lv
46. Backward compatibility is a key.
State is pain in the ass, but remediable with redundancy
Dealing with backward compatible code:
http://goo.gl/MMEO70
59. noun
1 a feeling of fear or agitation about something that may happen: the
men set off in fear and trepidation.
2 trembling motion.
Embrace change
trepidation | trep·i·da·tion
61. Do not be afraid to fail.
Learn what doesn’t work first, then see how to make it better.
Engineering Velocity: Shifting the Curve at Netflix
http://goo.gl/D10wGH
62. Continuously improve
Japanese for "improvement", or "change for the better"
Refers to philosophy or practices that focus upon continuous
improvement of processes in manufacturing, engineering, and business
management.
Kaizen | 改善
When business come to you and say you’re releasing too frequently – you’re on the right way.
Short Lead time faster Feedback
Большинство – тормозы. Неэффективность процесса и ОПАСНОСТЬ.
The most complex task is push button.
Create environment where people get responsible for consequence of their action and they will care (DevOps phylosophy)
- Modules / services / entities / static content
Постоянно упускаем нужный момент. Как продать необходимость улучшений?
Lead time – from request to delivery
Cycle time – work started to delivery
Why branches? Parallelization. Multiple versions of the app. Unability to keep application stable during development.
One goal, extra care.
No merges.
One version, push up teams for synchronization
Brings pain forward, raises professionalism
Isolation illusion
If people have to use feature branch, something is wrong with your architecture.
Ask.fm way (Gradual releases)
Ask.fm way (Confiugration per node, per group)
(Aggregating change)
Code reviews, Pair Programming
Safety nets
Blameless culture, Team’s Responsibility
Reduce TTD (Time to detect), TTR (Time to recover)