NoOps - beyond the DevOps frontier!

In his speak Lars takes DevOps one step beyond forming a happy collaborative relation between Dev and Ops. He advocates for an entirely elastic and automated R&D infrastructure, with the software developer in the driver’s seat. In his own words:

A glimpse into a very near future where quality is actually built into the software, as opposed to glued on after it’s finished. It’s a future where software developers aren’t dependent on IT Operations at all.

In a Continuous Delivery NoOps world queues have disappeared, resources are available at your command and everything is automated.

Transcript

1. Lars Kruse
 @lakruzz, lak@praqma.com NoOps Beyond the DevOps Frontier
2. Please Throw Delivery Over The Fence
3. What’s Behind the Wall?
4. The DevOps Movement
 framed by Gene Kim
5. All alone, or in two's,
 The ones who really love you
 Walk up and down outside the wall. Some hand in hand
 And some gathered together in bands. The bleeding hearts and the artists 
 Make their stand. And when they've given you their all
 Some stagger and fall, after all it's not easy Banging your heart against some mad bugger's wall. Outside
6. What Do We Get
 From Ops? • Architectual layout • Performance • Sizing • Provisioning • User management • "Iron and wire” • Quality gateways • Deployment • Database management • Job scheduling • Survelliance and monitoring • Incident management • 1st level support and dispatching
7. What Do We Want
 From Ops? • Architectual layout • Performance • Sizing • Provisioning • User management • "Iron and wire” • Quality gateways • Deployment • Database management • Job scheduling • Survelliance and monitoring • Incident management • 1st level support and dispatching
8. Configuration as code Infrastructure as code Test as code …and what have we as code
9. Agile Watergile? Agilefall? Processes Release Deployment Test Integration Development Iterative and Incremental Development → Integration → Test → Deployment → Release Development → Integration → Test → Deployment → Release Development → Integration → Test → Deployment → Release Development → Integration → Test → Deployment → Release Development → Integration → Test → Deployment → Release Release Deployment Test Integration Development → Integration → Test → Deployment → Release Development → Integration → Test → Deployment → Release Development → Integration → Test → Deployment → Release
10. Software As A Factory Waterscrumfall!
11. Unplanned Work Queued Work Software As A Factory
12. Unplanned Work Not important Very urgent Not important Not urgent Very important Very urgent Very important Not urgent Low High High Importance Urgency
13. Queued Work Little’s law W λ L q q =
14. The Andon Cord
15. Continuous Delivery Story-line
16. Verification vs Validation Software verification provides objective evidence that the design outputs of a particular phase of the software development life cycle meet all of the specified requirements for that phase. Software verification looks for consistency, completeness, and correctness… Software validation is to confirmation by examination and provision of objective evidence that software specifications conform to user needs and intended uses, and that the particular requirements implemented through software can be consistently fulfilled. General Principles of Software Validation; Final Guidance for Industry and FDA Staff
17. Individually Releasable Components
18. Software Inventory
19. “A project consist of a project manager and a header file”
20. Time master Development
 branches dev feat Integration branch maintenance Maintenance delivers to the release train automatically - like any other dev branch Tag 1.0 Promotion
 branches Branch maint/release Branch maint/stable Branch release Branch stable Maintenance branches mirror the release train. 
 Same process - same quality Promotions are 
 fast-forwards Permanent retrievable states must be labeled Permanent retrievable states must be tagged Tag 1.0.1 Tag 2.0 Origin: CoDe:U by Praqma Inspired by: @nvie (nvie.com) License: Creative Commons All integrations and promotions
 are automated Branch master stable release Feature for future release kept off the release train until due Branch maint/master Automated
 Git Flow
21. Time master Development
 branches dev feat Integration branch maintenance Maintenance branches mirror the release train. 
 Same process - same quality All integrations and promotions
 are automated Branch master Promotion
 branches stable release Maintenance delivers to the release train automatically - like any other dev branch Feature for future release kept off the release train until due Branch maint/release Branch maint/stable Tag 1.0.1 Branch maint/master Promotions are 
 fast-forwards Tag 1.0 Branch release Permanent retrievable states must be labeled Permanent retrievable states must be tagged Tag 2.0 Branch stable Automated
 Git Flow
22. Time master Development
 branches dev feat Integration branch maintenance All integrations and promotions
 are automated Automated
 Git Flow
23. Time master Development
 branches dev feat Integration branch maintenance Maintenance delivers to the release train automatically - like any other dev branch Tag 1.0 Promotion
 branches Branch maint/release Branch maint/stable Branch release Branch stable Maintenance branches mirror the release train. 
 Same process - same quality Promotions are 
 fast-forwards Permanent retrievable states must be labeled Permanent retrievable states must be tagged Tag 1.0.1 Tag 2.0 Origin: CoDe:U by Praqma Inspired by: @nvie (nvie.com) License: Creative Commons All integrations and promotions
 are automated Branch master Automated integration 
 (squashed or accumulated) Manual sync 
 (merge or rebase) Manual free-style merge 
 (edit, merge, cherry-pick or squash) Commit 
 (integration branch) Branch head
 (integration branch) Tag Fast Forward commits 
 (promotion branches) Commit 
 (development/maintenance branch) Legend Branch heads
 (promotion branches) stable release The Git Commitments The strategy is a release train The integration branch is master where developers continuously integrate Only trivial merges are allowed onto the integration branch All merges to the integration branch must run through an automated toll-gate A commit on a designated branch triggers an automated integration, when pushed to origin Every successful integration onto master kicks off the automated pipeline The integration branch is always aiming for the next release. Commits that aren’t meant for next release are kept out of the release train until they are due A promotion branch can only have one contributor branch - promotions are always Fast Forward merges All merges onto promotion branches are automated Maintenance branches mirror the behavior of the integration branch - duplicate setup, same process, same quality Read detailed flow description in Josra blog post: 
 http://www.josra.org/blog/An-automated-git-branching-strategy.html Automated by Jenkins CI Pretested Integration Plugin:
 http://wiki.jenkins-ci.org/display/JENKINS/Pretested+Integration+Plugin Automated
 Git Flow Feature for future release kept off the release train until due Branch off Branch maint/master
24. A LUCI Box
 Luci Understands CI LUCI: - Docker - Git - Jenkins - Artifactory - Gradle