Book Image

DevOps Culture and Practice with OpenShift

By : Tim Beattie, Mike Hepburn, Noel O'Connor, Donal Spring, Ilaria Doria
Book Image

DevOps Culture and Practice with OpenShift

By: Tim Beattie, Mike Hepburn, Noel O'Connor, Donal Spring, Ilaria Doria

Overview of this book

DevOps Culture and Practice with OpenShift features many different real-world practices - some people-related, some process-related, some technology-related - to facilitate successful DevOps, and in turn OpenShift, adoption within your organization. It introduces many DevOps concepts and tools to connect culture and practice through a continuous loop of discovery, pivots, and delivery underpinned by a foundation of collaboration and software engineering. Containers and container-centric application lifecycle management are now an industry standard, and OpenShift has a leading position in a flourishing market of enterprise Kubernetes-based product offerings. DevOps Culture and Practice with OpenShift provides a roadmap for building empowered product teams within your organization. This guide brings together lean, agile, design thinking, DevOps, culture, facilitation, and hands-on technical enablement all in one book. Through a combination of real-world stories, a practical case study, facilitation guides, and technical implementation details, DevOps Culture and Practice with OpenShift provides tools and techniques to build a DevOps culture within your organization on Red Hat's OpenShift Container Platform.

Related Content you might be interested in

Current Title:

Small book image
DevOps Culture and Practice with OpenShift
Tim Beattie | Mike Hepburn | Noel O'Connor | Donal Spring | Ilaria Doria
Aug, 2021 | 812 pages
Small book image
The Agile Developer's Handbook
Paul Flewelling
Feb, 2018 | 398 pages
Small book image
The Professional Scrum Master (PSM I) Guide
Fred Heath
Jul, 2021 | 174 pages
Small book image
SAFe® for DevOps Practitioners
Robert Wen
Dec, 2022 | 330 pages
Table of Contents (30 chapters)
Preface
Preface
About DevOps Culture and Practice with OpenShift
1
Acknowledgements
Acknowledgements
On a personal level:
Free Chapter
2
Section 1: Practices Make Perfect
Section 1: Practices Make Perfect
3
1. Introduction — Start with Why
1. Introduction — Start with Why
Why — For What Reason or Purpose?
Why Should I Listen to These Folks?
Where Did This Book Come From?
Who Exactly Is This Book For?
Conclusion
4
2. Introducing DevOps and Some Tools
2. Introducing DevOps and Some Tools
The Value Chain
The Gaps
People, Process, and Technology
The Mobius Loop and the Open Practice Library
Conclusion
5
3. The Journey Ahead
3. The Journey Ahead
A Story about Telling a Practice
PetBattle – the Backstory
What about Legacy Systems?
Borrowing Brilliance
What to Expect from the Rest of This Book?
Conclusion
6
Section 2: Establishing the Foundation
Section 2: Establishing the Foundation
7
4. Open Culture
4. Open Culture
Why Is It Important?
Information Radiators
Culture
Motivation
Social Contracts
Stop the World
Real-Time Retrospective
Team Identity
Radiate Everything
Team Sentiment
Inspect and Adapt
PetBattle — Establishing the Cultural Foundation
Conclusion
8
5. Open Environment and Open Leadership
5. Open Environment and Open Leadership
The Kodak Problem
Learning from History
Open Leadership
Changing an Organization
Leading Sustainable Change
Achieving Greatness
Priority Sliders
The Space
Conclusion
9
6. Open Technical Practices – Beginnings, Starting Right
6. Open Technical Practices – Beginnings, Starting Right
Green from Go!
Pair Programming and Mob Programming
Containers and Being Container-Native
Pipelines — CI or CD or CD²?
Everything-as-Code
Developer Workflows
Conclusion
10
7. Open Technical Practices — The Midpoint
7. Open Technical Practices — The Midpoint
The Big Picture
GitOps
Testing Testing Testing!
Emerging Architecture
Observations from the Field
Conclusion
11
Section 3: Discover It
Section 3: Discover It
12
8. Discovering the Why and Who
8. Discovering the Why and Who
The North Star
Impact Mapping
Human-Centered Design
Conclusion
13
9. Discovering the How
9. Discovering the How
Event Storming
Emerging Architecture
The Non-Functional Map
Discovering the Case for Continuous Delivery
Conclusion
14
10. Setting Outcomes
10. Setting Outcomes
What Is an Outcome?
Differentiating between Primary Outcomes and Enabling Outcomes
Creating a Discovery Map
Conclusion
15
Section 4: Prioritize It
Section 4: Prioritize It
16
11. The Options Pivot
11. The Options Pivot
Value Slicing
Design of Experiments
Impact and Effort Prioritization Matrix
How-Now-Wow Prioritization
The Design Sprint
Forming the Initial Product Backlog
Prioritization
Product Ownership
Advanced Deployment Considerations
Research, Experiment, Implement
Creating an Options Map
Conclusion
17
Section 5: Deliver It
Section 5: Deliver It
18
12. Doing Delivery
12. Doing Delivery
Waterfall
The Birth of Agile
Decision-Making Contexts
The Definition of Ready
Scrum
The Definition of Done
Bad Agile Smells
Conclusion
19
13. Measure and Learn
13. Measure and Learn
Metrics-Driven Transformation
Where to Measure and Learn
What to Measure?
Visualize Measurable Outcomes
Creating a Delivery Map
Conclusion
20
Section 6: Build It, Run It, Own It
Section 6: Build It, Run It, Own It
21
14. Build It
14. Build It
Cluster Resources
Existing PetBattle Architecture
Running PetBattle
Argo CD
Trunk-Based Development and Environments
The Anatomy of the App-of-Apps Pattern
Build It – CI/CD for PetBattle
Jenkins–The Frontend
Tekton–The Backend
Which One Should I Use?
Conclusion
22
15. Run It
15. Run It
The Not Safe For Families (NSFF) Component
Pipelines and Quality Gates (Non-functionals)
Advanced Deployments
Conclusion
23
16. Own It
16. Own It
Observability
Metadata and Traceability
Alerting
Service Mesh
Operators Everywhere
Conclusion
24
Section 7: Improve It, Sustain It
Section 7: Improve It, Sustain It
25
17. Improve It
17. Improve It
What Did We Learn?
Did We Learn Enough?
"Just Enough" Leads to Continuous Everything
Improve the Technology
Long Live the Team
Conclusion
26
18. Sustain It
18. Sustain It
The Journey So Far
Infectious Enthusiasm
More Teams, More Application Products
The Power of Three Iterations in Enablement
Bolster the Foundations
Sustaining the Technology
The Double Mobius Loop – Platform and Application Product
Conclusion
27
Index
Index
Appendix A – OpenShift Sizing Requirements for Exercises
Appendix A – OpenShift Sizing Requirements for Exercises
How To Resize Storage in Your CRC Virtual Machine
Appendix B – Additional Learning Resources
Appendix B – Additional Learning Resources

Pair Programming and Mob Programming

Pair programming and mob programming help us deal with a phenomenon that people term Unicorn Developers. It has various names across different regions and companies, such as the Hero Developer or the Rockstar Developer. But we all can identify who they are when we see them.

For those who don't know; the Unicorn Developer is the one who has all the knowledge and keeps it to themselves. They're the person who writes the most magnificent code, and the code that is usually the least understood. They have all the keys and secrets in their head, including all the ideas and knowledge. They are often the one producing so much new work that they don't have time to document it, meaning no one else can continue on the work in their absence. At this point, you can probably identify if your team has a Unicorn; it may even be you!

Figure 6.2: The Unicorn

So why do we have a problem with the Unicorn?

The Unicorn...

Previous Section
End of Section 3
Next Section