Agile, Continuous Delivery & DevOps in perspectief
1. Title | Plaats| Datum | 1
Continuous Delivery
Agile, Continuous Delivery & DevOps
in perspectief
Dave van Herpen
2. Title | Plaats| Datum | 2
►Drivers
►Wat is:
● Agile
● Continuous Delivery
● DevOps
►Sogeti & Agile/Continuous Delivery/DevOps
To do
3. Title | Plaats| Datum | 3
►Drivers
►Wat is:
● Agile
● Continuous Delivery
● DevOps
►Sogeti & Agile/Continuous Delivery/DevOps
To do
4. Title | Plaats| Datum | 4
Het speelveld
Service Management
Functioneel
beheer
Applicatie
beheer
Technisch
beheer
Project Management
Incidenten
service req.
RfC’s
Beheer
requirements
Transitie
naar beheer
Changes &
releases
Voortschrijdend Voorschrijvend
Project Onderhoud
Beheer
5. Title | Plaats| Datum | 5
Agile & DevOps business drivers
Customer Satisfaction
Business
driven
Business
driven
Optimal value & risk
Feedback
loops
Feedback
loops
Short TTM
Fast flowFast flow
Efficient operations
Multidiscipl.
teams
Multidiscipl.
teams
@daveherpen
7. Title | Plaats| Datum | 7
►Drivers
►Wat is:
● Agile
● Continuous Delivery
● DevOps
►Sogeti & Agile/Continuous Delivery/DevOps
To do
8. Title | Plaats| Datum | 8
►Continuous Delivery:
● Integratie binnen de deployment pipeline
►DevOps:
● Beweging tbv samenwerking Dev, Ops, QA & business
►AgileBeheer:
● Sogeti visie op waarmaken agile belofte via
samenwerking in gehele IT keten, van project tot beheer
CD - DevOps - AgileBeheer
9. Title | Plaats| Datum | 9
CD - DevOps - AgileBeheer
Continuous
Delivery
DevOps
Basis = principes
Naam = gewenste resultaat
Basis = organisatie
Naam = implementatiewijze
Agile
Beheer
Basis = wendbaarheid
Naam = resultaat & domein
10. Title | Plaats| Datum | 10
Agile =
Scrum
XP
DSDM
FDD
Crystal
Kanban
DevOps
11. Title | Plaats| Datum | 11
Agile Manifesto (Salt Lake City 2001)
Mensen en hun onderlinge interactie boven processen en tools
Werkende software boven allesomvattende documentatie
Samenwerking met de klant boven contractonderhandelingen
Inspelen op verandering boven het volgen van een plan
12. Title | Plaats| Datum | 12
Agile: Scrum
Operations & SupportOperations & Support
Operations & MaintenanceOperations & MaintenanceDevelopment
Klant interactieKlant interactie
Anticiperen
changes
Anticiperen
changes Snel leverenSnel leveren
@daveherpen
Product
Owner
Scrum
Master
Team
Members
13. Title | Plaats| Datum | 13
►Jezz Humble
►Continuous Delivery: matchen van het verandertempo van
beheer (ops) met ontwikkeling (dev) door:
● Alles in deployment pipeline: gehele value stream in
versiebeheer, van code check-in tot productie (incl
omgevingen)
● Geautomatiseerd:
○ Testen
○ Builds
○ Integratie
○ Deployments
○ Creatieproces (OTAP) omgevingen
Continuous Delivery
Continuous Delivery
“DevOps”
14. Title | Plaats| Datum | 14
►Ontstaan in 2009 vanuit:
● Flickr dev & ops samenwerking (“10+ deploys a day”)
● Agile Infrastructure
● Lean Startup movement
● Continuous Delivery
● Cloud (PaaS) services
► Must reads
● Whitepaper “DevOps Distilled” (Kim)
● The Phoenix Project (Kim, Behr, Spafford)
DevOps origine
15. Title | Plaats| Datum | 15
►Een beweging
● Gene Kim, Damon Edwards, Patrick Debois, John Willis, ...
►Uitgangspunten:
● Samenwerking Dev + Ops (Lite) + QA + business
● Shippable code + omgevingen
● Snelle flow planned work, kleine batch size
● P = betrouwbaar, stabiel, veerkrachtig, bedrijfszeker
DevOps = ...
16. Title | Plaats| Datum | 16
DevOps: relaties
Continuous
Build
Integration
Deployment
Delivery
......
17. Title | Plaats| Datum | 17
►Culture
● Verandermanagement
►Automation
● Release mgt, config & versiebeheer, integration, monitoring
►Measurement (metrieken)
● Performance (#deploys)
● Process (#handovers)
● People (#people/deployment)
►Sharing
● Feedback
● Co-locatie
DevOps dimensies: CAMS
18. Title | Plaats| Datum | 18
DevOps: The Three Ways
1. Systems thinking
2. Verbeteren feedback loops
3. Cultuur van voortdurend experimenteren & leren
Resultaten:
•Known defect gaan nooit downstream
•Geen suboptimalisatie
•Zoek altijd naar verbetering flow
•Begrijp altijd het volledige systeem
Resultaten:
•Begrijp en reageer op alle klanten
•Verkort en verbeter alle feedback loops
•Borg kennis waar je het nodig hebt
Resultaten:
•Tijd continue verbetering dagelijks werk
•Rituelen om team te belonen voor risico´s
•Introduceer fouten in systeem > veerkracht
19. Title | Plaats| Datum | 20
►Shippable code + herbouwbare omgeving om naar te
deployen
►IT ops: geautomatiseerd bouwproces OTAP (lage variantie)
►Eén shared repository (CMDB)
►Security monitoring controls
DevOps & Agile
20. Title | Plaats| Datum | 21
DevOops
►Vooral focus op:
● Standaardisatie
● Automatiseren
● Nieuwe technologieën
►Te weinig focus op:
● Functioneel Beheer
● IT support
● Complexe systemen & processen
● Portfolio Management >>
DevOps focus:
First, there’s the happy customer. Here we need to stop focusing on SLA’s and service reports with availability percentages of 99,5%, which the customer couldn’t care less about. Agreeing and measuring on customer satisfaction (like NPS) is a nice first step. In Agile principles the close collaboration with the business is essential to all Agile practices, where the business (by means of the Product Owner) is IN the team, not shouting from the other side of the river. Second, your business changes its portfolio, its priorities, its goals while you’re brushing your teeth. Short iterations of distinctive value are crucial here to support the changing organization, where constant feedback is also crucial to keep everyone on board and minimize the long term business risk. Third, IF your organization requires changes, through legislation, or competition, or new market opportunities, these changes are needed yesterday. Only an agile development team is not enough to reach a short time to market. If it halts at test, or production, or the business itself, there will never be a fast flow here. And the last business driver is about delivering quality in a reliable, repetitive and sustainable manner. Working in splendid isolation, whether you are at a Service Desk, or a developer, teams need to be compressed with all required disciplines to deliver quality at the required pace. This is a big challenge in large companies with considerable legacy environments.
As said, Scrum is the best documented Agile approach worldwide. This approach is based on only a few roles. The Product Owner is representing the business IN the team. Constantly involved, especially with regard to explaining business needs (in the form of use cases or user stories, all available in the Product Backlog) and ensuring the team is acting according to the actual business priorities. Based on the PBL, the team breaks down the total list into limited parcels, which we call sprints. Within the sprint the sprint backlog is picked up by the team, which deliver ready products every 2-4 weeks, using daily standups to ensure short and constant feedback loops. The Scrum Master is safeguarding the Scrum process and facilitating the team members in doing their jobs. The Team Members are the people engineering the product, which for Scrum is usually a particular piece of software, but can in fact be any product or service you’d like. So the main characteristics of Scrum are the tight interaction with the customer, the iterations and feedback loops to deal with constant change, and the short time to deliver ready products. Now especially this item is a growing pain as well. After all, Scrum ends at the Potentially Shippable Product, it does not deal with the actual release, transition to production, knowledge transfers to support, documentation, etc. Now, to prevent the actual waterfall to sustain at the end of the product development and still hamper the delivery, operations & support need to be involved continuously during the Scrum process. I will come back to that later.
"Lean Startup" is a largely theoretical methodology for developing businesses and products first proposed in 2011 by Eric Ries. Based on his previous experience working in several US startups, Ries claims that startups can shorten their product development cycles by adopting a combination of business-hypothesis-driven experimentation, iterative product releases, and what he calls " validated learning ". Though still largely unsubstantiated, Ries' overall claim is that if companies, especially startups, invest their time into iteratively building products or services to meet the needs of early customers, they can sidestep the need for large amounts of initial project funding and expensive product launches