Team Guide to Software Releasability
Team Guide to Software Releasability
About the Book
Strong build & release engineering capabilities are key to rapid and reliable delivery of modern software systems. Learn how software releasability means not only being able to deploy faster, but also being able to quickly recover from disaster and adapt to changing technical and business challenges.
The ‘Team Guide’ collection is designed to help teams building and running software systems to be as effective as possible. Guides are curated by experienced practitioners and emphasise the need for collaboration and learning, with the team at the centre.
Manuel Pais is an independent DevOps and Delivery Consultant, focused on teams and flow.
With a diverse experience including development, build management, testing and QA, Manuel has helped large organizations in finance, legal, and manufacturing adopt test automation and continuous delivery, as well as understand DevOps from both technical and human perspectives.
Manuel is co-author of the Team Guide to Software Releasability book and lead editor for the remaining books in the Team Guide series.
Matthew Skelton is co-author of Team Topologies: organizing business and technology teams for fast flow. Recognised by TechBeacon in 2018, 2019, and 2020 as one of the top 100 people to follow in DevOps, Matthew curates the well-known DevOps team topologies patterns at devopstopologies.com. He is Head of Consulting at Conflux and specialises in Continuous Delivery, operability, and organisation dynamics for modern software systems.
- Team Guides for Software
- What is software releasability?
- What constitutes a delivery system?
- What does resilient delivery feel like?
- Warning signs of software delivery debt
- Why invest in software releasability?
- Relationship to Continuous Delivery
- What this book is (not) about
- How to use this book
- Feedback and suggestions
1. Treat your pipeline as a product for resiliency and fast feedback loops
- 1.1 Make your pipeline the single route to production
- 1.2 Your pipeline is now a product: invest in it
- 1.3 Avoid simply retro-fitting CD into a CI server
- 1.4 Measure delivery to visualize flow and identify bottlenecks
- 1.5 Design the delivery system to evolve with your needs
- 1.6 Apply monitoring and logging to minimize issues and downtime
- 1.7 Scale the infrastructure to avoid pipelines queuing up
- 1.8 Scale the practices and pipelines to support growing usage
- 1.9 Care for pipeline testability and usability to encourage adoption
- 1.10 Build security into and around the pipeline
- 1.11 Get started!
- 1.12 Summary
2. Regularly restore your delivery system to build resiliency
- 2.1 Investing in minimal recovery time pays off in engineering time
- 2.2 Store everything in version control
- 2.3 Store your pipeline definitions in source control
- 2.4 Treat your pipeline as code or configuration?
- 2.5 Repeatable Environment Provisioning
- 2.6 Rollback without (too much) pain
- 2.7 Include the delivery system in disaster recovery scenarios
- 2.8 Get started!
- 2.9 Summary
3. Ensure delivery system is operable to minimize downtime
- 3.1 Visibility and tracing
- 4. Ensure both practices and infrastructure can scale to meet usage growth
- 5. Care for pipeline testability and usability to encourage adoption
6. Measure delivery to visualize flow and identify bottlenecks
- 6.1 Plan and monitor build capacity to avoid queues
- 6.2 Build latency/throughput (?) / responsiveness
- 6.3 Monitor Code Repositories / Forensics
- 6.4 Monitor Your Builds and Environments
- 6.5 Aligning Agents with Delivery Tasks vs Generic Build Machines (it depends on cost of agent provisioning + running)
- 6.6 TODO: reference Steve Smith’s talk/book for further info
7. Treat your pipeline as a value stream to tackle largest bottlenecks first
- 7.1 Static (or Nearly) Value Stream Mapping
- 7.2 Dynamic Value Stream Mapping (in the Pipeline)
- 7.3 Pipeline stages, not environments
- 7.4 Single Pipeline, Single Binary
- 7.5 visualize (actual) workflow, pipeline = value stream map, identify non-technical bottlenecks, support global optimization instead of local optimization
- 7.6 Goal: Short and Wide pipelines, not long and narrow
- 7.7 Resources
- 7.8 Inclusive Pipelines
- 7.9 Choose your tools wisely - the hidden costs of “DevOps solutions” (e.g. Visual Studio)
8. Organize teams to promote build and release ownership
- 8.1 CDaaS
- 8.2 Clarify Build Team vs Product Team Responsibility (Build, Infra, Deploy)
- 8.3 Build Team
- 8.4 Knowledge Sharing in Product Teams
- 8.5 DVTs for Collaboration Between Product and Ops/Infra Teams
- 9. Appendix A: build security into and around the pipeline
References and further reading
- Chapter 1 - Treat Your Pipeline as a Product
About the authors
- Chris O’Dell
- Manuel Pais
- Conflux Books
The Leanpub 60-day 100% Happiness Guarantee
Within 60 days of purchase you can get a 100% refund on any Leanpub purchase, in two clicks.
See full terms
80% Royalties. Earn $16 on a $20 book.
We pay 80% royalties. That's not a typo: you earn $16 on a $20 sale. If we sell 5000 non-refunded copies of your book or course for $20, you'll earn $80,000.
(Yes, some authors have already earned much more than that on Leanpub.)
In fact, authors have earnedover $12 millionwriting, publishing and selling on Leanpub.
Learn more about writing on Leanpub
Free Updates. DRM Free.
If you buy a Leanpub book, you get free updates for as long as the author updates the book! Many authors use Leanpub to publish their books in-progress, while they are writing them. All readers get free updates, regardless of when they bought the book or how much they paid (including free).
Most Leanpub books are available in PDF (for computers) and EPUB (for phones, tablets and Kindle). The formats that a book includes are shown at the top right corner of this page.
Finally, Leanpub books don't have any DRM copy-protection nonsense, so you can easily read them on any supported device.