23,99 €
Mehr erfahren.
- Herausgeber: Packt Publishing
- Kategorie: Fachliteratur
- Sprache: Englisch
Over the past few years, Continuous Delivery (CD) and DevOps have been in the spotlight in tech media, at conferences, and in boardrooms alike. Many articles and books have been written covering the technical aspects of CD and DevOps, yet the vast majority of the industry doesn’t fully understand what they actually are and how, if adopted correctly they can help organizations drastically change the way they deliver value. This book will help you figure out how CD and DevOps can help you to optimize, streamline, and improve the way you work to consistently deliver quality software.
In this edition, you’ll be introduced to modern tools, techniques, and examples to help you understand what the adoption of CD and DevOps entails. It provides clear and concise insights in to what CD and DevOps are all about, how to go about both preparing for and adopting them, and what quantifiable value they bring. You will be guided through the various stages of adoption, the impact they will have on your business and those working within it, how to overcome common problems, and what to do once CD and DevOps have become truly embedded. Included within this book are some real-world examples, tricks, and tips that will help ease the adoption process and allow you to fully utilize the power of CD and DevOps
Das E-Book können Sie in Legimi-Apps oder einer beliebigen App lesen, die das folgende Format unterstützen:
Seitenzahl: 412
Veröffentlichungsjahr: 2018
Ähnliche
Continuous Delivery and DevOps – A Quickstart Guide Third Edition
Copyright © 2018 Packt Publishing
All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews.
Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the author, nor Packt Publishing or its dealers and distributors, will be held liable for any damages caused or alleged to have been caused directly or indirectly by this book.
Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information.
Commissioning Editor: Gebin GeorgeAcquisition Editor:Rahul NairContent Development Editor:Deepti ThoreTechnical Editor:Varsha ShivhareCopy Editor:SafisProject Coordinator:Kinjal BariProofreader: Safis EditingIndexer:Pratik ShirodkarGraphics:Tom ScariaProduction Coordinator: Deepika Naik
First published: November 2012 Second edition: December 2014 Third edition: October 2018
Production reference: 2191118
Published by Packt Publishing Ltd. Livery Place 35 Livery Street Birmingham B3 2PB, UK.
ISBN 978-1-78899-547-4
www.packtpub.com
Mapt is an online digital library that gives you full access to over 5,000 books and videos, as well as industry leading tools to help you plan your personal development and advance your career. For more information, please visit our website.
Why subscribe?
Spend less time learning and more time coding with practical eBooks and Videos from over 4,000 industry professionals
Improve your learning with Skill Plans built especially for you
Get a free eBook or video every month
Mapt is fully searchable
Copy and paste, print, and bookmark content
Packt.com
Did you know that Packt offers eBook versions of every book published, with PDF and ePub files available? You can upgrade to the eBook version at www.packt.com and as a print book customer, you are entitled to a discount on the eBook copy. Get in touch with us at [email protected] for more details.
At www.packt.com, you can also read a collection of free technical articles, sign up for a range of free newsletters, and receive exclusive discounts and offers on Packt books and eBooks.
Contributors
About the author
Paul Swartout has spent over 2 decades working in the IT industry. He has worked across several different industries and sectors and within organizations of various sizes, from start-ups to multinational corporates. He is and always has been passionate about quality software and how it is delivered. Since first encountering Agile he has been committed to the adoption and implementation of Agile techniques and approaches to improve the efficiency, output, and lives of everyone involved in software development. He strongly believes that CD and DevOps add massive value to the way software is delivered, and he wants to ensure as many people realize this as possible. Paul lives in a small seaside town in the southwest of the UK.
About the reviewers
Mitesh Soni is an avid learner with 10 years of experience in the IT industry. He is an SCJP, SCWCD, VCP, IBM Urbancode, as well as IBM Bluemix-certified, and a certified Jenkins Engineer. He loves DevOps and cloud computing, and he also has an interest in programming in Java. He finds design patterns fascinating and believes that a picture is worth a thousand words. He occasionally contributes to the clean-clouds and eTutorials World websites.
He believes in the KISS principle. Yes, you read it right. The KISS (Keep It Simple Stupid) principle states that simplicity should be a key goal in design and unnecessary complexity should be avoided. Hence, he follows the KISS principle in life.
Max Manders is a recovering PHP developer and former sysadmin who currently works as Principal Engineer (DevOps) at FanDuel, the leader in online Daily Fantasy Sports. Max enjoys discussing distributed systems, availability and scalability, infrastructure as code, continuous delivery, and automation. With experience of managing large-scale distributed system configuration with Puppet and Chef, Max has started exploring containerization with Docker and Kubernetes.
Max was a co-founder and organizer of Whisky Web, a Scottish conference for the web development and ops community. When he's not writing code or tinkering with the latest monitoring and operations tools, Max enjoys playing jazz and funk trombone. Max lives in Edinburgh with his wife Jo, their cats Ziggy and Maggie, and their hedgehog, Pickle.
Sami Rönkä has a background in software business and has been a keen advocate of DevOps for years. After years of hands-on specialist work, he has moved more into the business and management side and is currently transforming an MSP business into a more agile and development-oriented company using DevOps practices. He has also been reviewing other DevOps-guides for Packt.
Packt is searching for authors like you
If you're interested in becoming an author for Packt, please visit authors.packtpub.com and apply today. We have worked with thousands of developers and tech professionals, just like you, to help them share their insight with the global tech community. You can make a general application, apply for a specific hot topic that we are recruiting an author for, or submit your own idea.
Table of Contents
Title Page
Copyright and Credits
Continuous Delivery and DevOps – A Quickstart Guide Third Edition
Packt Upsell
Why subscribe?
Packt.com
Contributors
About the author
About the reviewers
Packt is searching for authors like you
Preface
Who this book is for
What this book covers
To get the most out of this book
Download the color images
Conventions used
Get in touch
Reviews
The Evolution of Software Delivery
ACME systems – evolution phase 1.0
Software-delivery process flow Version 1.0
ACME systems evolution phase 2.0
Software-delivery process flow Version 2.0
An outsider's perspective from the inside
ACME systems evolution phase 3.0
Software-delivery process flow version 3.0
ACME systems beyond Version 3.0
The evolution in a nutshell
Where am I on the evolutionary scale?
Summary
Understanding Your Current Pain Points
Elephant in the room
Defining the rules
Including (almost) everyone
Identifying key people
Too many cooks
Openness, transparency, and honesty
Secrets hiding the truth
Location, location, location
It's all happy-clappy management waffle – isn't it?
The great elephant disclosure
Tools and techniques to expose the obvious
Timeline
Value stream mapping
Summary
Culture and Behaviors are the Cornerstones to Success
All roads lead to culture
Defining culture
Processes
Communications
Tools and techniques
An open, honest, and safe environment
Openness and honesty
Courageous dialogue
The physical environment
Encouraging and embracing collaboration
Fostering innovation and accountability at a grass-roots level
The blame game
Blame slowly, learn quickly
Building trust-based relationships across organizational boundaries
Rewarding good behaviors and success
The odd few
Recognizing how Dev and Ops teams are incentivized can have an impact
Embracing change and reducing risk
Changing people's perceptions with pudding
Being transparent
Summary
Planning for Success
Some common problems
Setting and communicating goals and vision
Standardizing vocabulary and language
A business change project in its own right
Dev + Ops + Org
The pros and cons of a dedicated team
The importance of evangelism
The courage and determination required throughout the organization
Understanding the cost
Seeking advice from others
Summary
Approaches, Tools, and Techniques
Engineering best practices
Source-control
The binary repository
Small, frequent, and simple changes
Automated builds
Test-automation
Continuous integration
Fail fast and often
Architectural approaches
Component-based architecture
Layers of abstraction
Never break your consumer
Open and honest peer-working practices
Incremental delivery of features
Using the same binary across all environments
How many environments is enough?
Developing against a like-live environment
CD and DevOps tooling
Automated provisioning
No-downtime deployments
Monitor, monitor, monitor
When a simple manual process is also an effective tool
Summary
Avoiding Hurdles
What are the potential issues you need to look out for?
Dissenters in the ranks
No news is no news
The change curve
The outsiders
Corporate guidelines, red tape, and standards
Geographically diverse teams
Failure during the evolution
Processes that are not repeatable
Bridging the skills gap
Changes in leadership
Summary
Vital Measurements
Measuring effective engineering best practices
Code complexity
Unit-test coverage
Commit and merge rates
Adherence to coding rules and standards
Quality metrics
Cycle and lead times
Quality gates
Where to start and why bother?
Measuring the real world
Measuring the stability of the environments
Incorporating automated tests
Combining automated tests and system monitoring
Real-time monitoring of the software itself
Monitoring utopia
Effectiveness of CD and DevOps
Impact of CD and DevOps
Measuring your culture
Summary
You Are Not Finished Just Yet
Reflecting on where you are now
Streaming
A victim of your own success
[P]lan, [D]o, [C]heck, [A]djust
Exit, stage left
Resting on your laurels (not)
Summary
Expanding Your Opportunity Horizon
What about me?
Performance and load-testing
Reducing feature-flag complexity
A/B testing
Blue-green deployments
Security-patching and bacon-saving
Order-out-of-chaos monkey
End user self-service
Thing as a service
Summary
CD and DevOps Beyond Traditional Software Delivery
CD, DevOps, and the mobile world
Expanding beyond software delivery
UX and design
Business process improvements
Business growth
Optimized feedback loops
What about me?
What have you learned?
Summary
Some Useful Information
Tools
People
Recommended reading
Retrospective games
StoStaKee
Vital measurements expanded
Code complexity – some science
Code versus comments
Embedding monitoring into your software
Other Books You May Enjoy
Leave a review - let other readers know what you think
Preface
Continuous Delivery (CD) and DevOps have been in the spotlight over the last decade or so. Much has been written about the technical aspects and tooling of CD and DevOps, yet a vast number of so-called IT experts don't really understand what they actually are. More worryingly, they don't seem to know what they are definitely not. Over the pages that make up this book I will be unpicking both CD and DevOps so that you will gain an understanding of what they are, how they came to be, and how they can bring true business value to your business. Strictly speaking, we should consider CD and DevOps as two complementary yet separate approaches:
Continuous Delivery, as the name suggests, is a way of working whereby quality products, normally software assets, can be built, tested and shipped in quick succession—thus delivering value much sooner than traditional approaches.
DevOps is a way of working whereby developers and IT system operators work closely, collaboratively, and in harmony towards a common goal with little or no organizational barriers or boundaries between them.
This book will provide you with some insight into how these approaches can help you optimize, streamline, and improve the way you work and, ultimately, how you ship quality software. Included in this book are some tricks and tips based on real-world experiences and observations; they can help you reduce the time and effort needed to implement and adopt CD and DevOps, which, in turn, can help you reduce the time and effort required to consistently ship quality software.
In this revised edition, you'll be introduced to the tools, techniques, and approaches that will assist you in the successful adoption of CD and DevOps. Included within are real-world examples to help you to understand what adoption of CD and DevOps entails from the early stage of preparation, through implementation and scaling, to extending beyond traditional uses, along with some real-world examples and tricks and tips that will help facilitate adoption. You will be provided with clear and concise insights into what CD and DevOps are all about and what quantifiable value they can bring to your business and everyone working within it.
Who this book is for
Everyone involved in traditional software delivery, whether they are IT professionals, C-level executives, product owners, developers, testers, project managers, or the ever inquisitive tech press, perceive a common problem at some point; delivering quality software can be very hard, very painful, and very expensive. It needn't be and it shouldn't be. This book has been written for everyone and anyone who wants to understand how to overcome these hardships and how CD and DevOps adoption can provide much-needed pain relief.
What this book covers
Chapter 1, The Evolution of Software Delivery, introduces you to a typical software-based business and details their evolution from a fledgling start-up, through the growing pains following acquisition, to the best of both worlds.
Chapter 2, Understanding Your Current Pain Points, introduces you to the tools and techniques that can be used to determine the current pain points within your software delivery process and where they stem from.
Chapter 3, Culture and Behaviors are the Cornerstones to Success, highlights the importance of the "human" factors that must be taken into account if you want CD and DevOps to succeed.
Chapter 4, Planning for Success, gives you some pointers on how a successful adoption of CD and DevOps can be defined and how this success can be measured.
Chapter 5, Approaches, Tools, and Techniques, introduces you to the various tools and techniques (some technical, some not so) that can help with the adoption of CD and DevOps.
Chapter 6, Avoiding Hurdles, gives you useful insights, tips, and tricks to help you overcome or avoid the bumps in the road during adoption of CD and DevOps.
Chapter 7, Vital Measurements, focuses on the various metrics and measures that can be used to monitor and communicate the relative success of CD and DevOps adoption.
Chapter 8, You Are Not Finished Just Yet, covers the less-than-obvious tasks that are important if you want to cement CD and DevOps into your day-to-day work.
Chapter 9, Expanding Your Opportunity Horizon, looks into how to evolve CD and DevOps once the adoption has taken hold.
Chapter 10, CD and DevOps Beyond Traditional Software Delivery, provides some insight into how you can reuse CD and DevOps tools, techniques, and approaches beyond software delivery.
To get the most out of this book
This book is not focused on a specific demographic or specific type of person. If you've never heard of CD or DevOps, this book will give you an insight into what all the fuss is about. If you have already set out to adopt CD and/or DevOps, then this book can help by providing some useful tips and tricks. If you know everything there is to know about both/either subject, then this book will help reaffirm your choices and might provide some additional things to chew over. All in all, the target audience is quite broad: anyone who wants to understand how to painlessly and regularly ship quality software.
Previous knowledge of DevOps practices, CD, or using DevOps tools is not necessary.
Download the color images
We also provide a PDF file that has color images of the screenshots/diagrams used in this book. You can download it here:http://www.packtpub.com/sites/default/files/downloads/9781788995474_ColorImages.pdf.
Conventions used
There are a number of text conventions used throughout this book.
Get in touch
Feedback from our readers is always welcome.
General feedback: If you have questions about any aspect of this book,mention the book title in the subject of your message and email us [email protected].
Errata: Although we have taken every care to ensure the accuracy of our content, mistakes do happen. If you have found a mistake in this book, we would be grateful if you would report this to us. Please visitwww.packt.com/submit-errata, selecting your book, clicking on the Errata Submission Form link, and entering the details.
Piracy: If you come across any illegal copies of our works in any form on the Internet, we would be grateful if you would provide us with the location address or website name. Please contact us [email protected] a link to the material.
If you are interested in becoming an author: If there is a topic that you have expertise in and you are interested in either writing or contributing to a book, please visitauthors.packtpub.com.
Reviews
Please leave a review. Once you have read and used this book, why not leave a review on the site that you purchased it from? Potential readers can then see and use your unbiased opinion to make purchase decisions, we at Packt can understand what you think about our products, and our authors can see your feedback on their book. Thank you!
For more information about Packt, please visit packt.com.
The Evolution of Software Delivery
As described in the preface, Continuous Delivery (CD) and DevOps are complementary ways of working. The former gives anyone who delivers customer value via software the ability to do so rapidly, consistently, and—as the name implies—continuously. The latter helps harmonize the teams that deliver and support said software. Both approaches can help you to optimize, streamline, and improve the way you work, and ultimately how you deliver value by shipping quality software.
It should be pointed out that the true meaning of these approaches have been blurred over the past decade—be that by tech press misunderstanding or recruitment businesses wanting to add 10% on salary rates, or software vendors and consultancies wanting to make their fortune by jumping on the bandwagon.
I have summarized what CD and DevOps are, but before we proceed, it may help if I highlight what they are not:
Continuous delivery and continuous deployment are not the same—the former focuses on business value and the latter is the mechanism of shipping software
A DevOps engineer is not a magical wizard. Software engineers and DevOps engineers are basically the same
—
the former creates text files that are used to create software assets and the latter creates text files that create environments and configuration to run said software
DevOps does not replace traditional system operations activities and approaches
—
it extends, complements, and enhances them
DevOps does not remove the need for ensuring your software, and the environments in which they run are highly secure
—
although this can ease the adoption and implementation of SecOps
CD and DevOps are not the silver bullet to remove all of your process and business issues, although they can help reduce the overall number
One thing you need to take into account is that almost all successful software businesses go through a number of phases of evolution. They normally start life as a small highly-focused team with good ideas, plenty of ambition, and some investment. As they build their market share, reach, and revenue, a period of rapid growth normally follows both in terms of workforce and spend. As the business matures and becomes established, they transition to the next phase of either continued and substantial growth to keep ahead of the competition, or make themselves a target for acquisition—this usually depends on how quickly investors want to see a return.
It's also inevitable that as a business goes through this evolution, the day-to-day business processes will become more complex, which in turn leads to complexity and pain in terms of how software is delivered.
The adoption of CD and DevOps can assist in reducing this complexity and pain; however, the effectiveness and benefits a business can reap are very much dependent on where the business sits on the evolutionary scale. If you are off the mark, then adoption can be more trouble than it is worth, and you may end up making things worse for the overall business. Not only that, but business, are strange and unique creatures—especially those whose raison d'etre is delivering software solutions—and no two are the same; therefore, the adoption needs to be uniquely tailored to fit.
The topics we will cover in this chapter are as follows:
A more detailed explanation of the various phases of the evolution of software delivery
The positives and negatives of each phase
How you can ascertain which phase you are in
The advantages
—
some unforeseen
—
that can come from a CD and DevOps way of working
To make it a little easier to understand what all of this actually means, we'll now dig a little deeper into these phases by following the evolution of a typical software-based business, called ACME systems.
ACME systems – evolution phase 1.0
ACME started out with a couple of things in common with the many thousands of small software businesses scattered around the globe: it had some good ideas and a saw gap in the market that it could exploit to make its fortune. It had a relatively small amount of cash so it needed to move fast to be able to survive and it needed to quickly entice, enlist, and retain customers at all costs. It did this by delivering what the customer wants just before the customer needs it. Deliver too soon, and it may have wasted money on building solutions that the customer decides they no longer want. Deliver too late, and someone else may well have taken the company's market share—and the revenue—away. The keyword here is deliver.
As a small start-up, in the early days, the going is slow and the work is hard: lots of R&D, frantically-built pre-sales prototypes, quick and dirty deliveries, and unrealistic deadlines. After many long days, nights, weeks, months, and weekends, things actually start to come together. The customer base starts to grow and the orders—and revenue—start rolling in. After a while, the number of employees are in double figures and the founders have become directors.
So, what has this got to do with CD or DevOps? Well, everything really. The culture, default behaviors, and engineering practices of a small software house are what would be classed as pretty good in terms of CD and DevOps. For example:
There are next to no barriers between developers and the operations teams—in fact, they are generally one and the same
Developers have full access to the production environment and can closely monitor their software
All areas of the business are focused on the same thing, that being to get software into the production environment a quickly as possible, thus delighting customers
Speed of delivery is crucial
If things break, everyone swarms around to help fix the problem—even out of hours
The software evolves quickly and features are added in incremental chunks
The ways of working are normally very agile
Communication and collaboration across the business is efficient and, for the most part, effective
There is a reason for stating that the culture, default behaviors, and engineering practices of a small software house would be classed as pretty good rather than ideal. This is because there are many flaws in the way a small software business typically has to operate to stay alive:
Corners will be cut to hit deadlines, which compromises software design, quality, and elegance
Application security best practices are given short shrift or even ignored
Engineering best practices are compromised to hit deadlines
The concept of technical debt is pretty much ignored
Testing won't be in the forefront of the developer's mind (even if it were, there may not be enough time to work in a test-first way)
Source-and version-control systems are not used religiously
With unrestricted access to the production environment, ad hoc and uncontrolled
tweaks and changes can be made to the infrastructure and environmental setup
Software releasing will be mainly manual and most of the time an afterthought of the overall system design
At times, a rough and ready prototype may become production code without the opportunity for refactoring
Documentation is scant or non-existent—any that does exist is probably out of date
The work-life balance for an engineer working within a small software house is
not sustainable and burn out does happen
Let's have a look at the software-delivery process for ACME systems Version 1.0, which, to be honest, shouldn't take too long.
Software-delivery process flow Version 1.0
The following diagram gives an overview of the simple process used by ACME systems to deliver software. It's simple, elegant (in a rough-and-ready kind of way), and easy to communicate and understand:
Let's move forward a few years and see how ACME systems is doing, and gain some insight into the benefits and pitfalls of being the leader of the field.
ACME systems evolution phase 2.0
The business has grown in both size and turnover. The customer base is now global and the ACME software platform is being used by millions of customers on a daily basis. ACME systems as a business is well-established, well-renowned, and recognized as being at the forefront in their area of expertise. However, the level of growth and investment has had an impact on profits—which are still pretty much non-existent.
The board of ACME systems are approached by a larger competitor with an acquisition offer. The board and investors feel this makes good commercial sense and that this will help stabilize the business for the future so the sale is agreed. On the whole, everyone is happy with the deal and most see this as positive recognition that they have at last reached the big time.
At first everything is good—everything is great, in fact. The ACME systems team now has the backing it needs to invest in the business and be able to scale out and obtain a truly global reach. It can also focus on the important things, such as building quality software, scaling out the software platform, investing in new technologies, tools, and R&D. The drier side of business—administration, program and project management, sales, marketing, and so on—can be passed to the new parent company that has all of this in place already.
The ACME engineering team moves forward in excited anticipation. The level of investment is such that the software engineering team doubles in size in a number of months. The R&D team—as it's now called—introduces new development tools and processes to enable the speedy delivery of quality software. Agile is adopted across the R&D team, and the opportunity to fully exploit engineering best practices is realized. The original ACME platform starts to creak and is showing its age, so further investment is provided to re-architect and rewrite the software platform using the latest architectural approaches and technologies. In short, the R&D team feels that it's all starting to come together and it has the opportunity to do things right.
In parallel to this, the ACME engineering team members who looked after the production environments are absorbed into the parent's global operations organization. On the face of it, this seems a very good idea; there are datacenters filled with cutting-edge kit, cloud capabilities, global network capabilities, and scalable infrastructure. Everything that is needed to host and run the ACME platform is there. Like the R&D team, the operations team has more than they could have dreamed of. In addition to the tin and string, the operations team also has resources available to help maintain quality, control change to the platform, and ensure the platform is stable and available 24 x 7.
Sitting above all of this, the parent company also has well-established governance, and program—and project-management functions to control and coordinate the overall end-to-end product delivery schedule and process.
On the face of it, everything seems rosy and the teams are working more effectively than ever. At first, this is true, but very soon things start to take a downward turn. Under the surface, things are not all that rosy:
It is getting increasingly difficult to deliver software—what took days now takes weeks or even months
Releases are getting overly complex and larger as the new ACME platform rapidly grows and more features are added and changes are made
Despite the advances in re-architecting the ACME platform, there still remain large sections of buggy legacy code deep within the bowels of the system, which refuses to die
The R&D team members are now so far removed from the production environment that they are ignorant as to how the software they are writing functions or performs, once it eventually goes live
The operations team members are now so far removed from the development process that they are ignorant to what's being delivered and how it's being developed
There are many corporate hoops to jump through and process hurdles to overcome before software changes can go anywhere near the production servers
Quality is starting to suffer as last-minute changes and frantic bug fixes are being applied to fit into release cycles
Technical debt amassed during the fast and loose days is starting to cause major issues
More and more R&D resources are being applied to assist in releases, which is impacting the development of new features
Deployments are causing prolonged production downtime—both planned and unplanned
Deadlines are being missed, stakeholders are being let down, and trust is being eroded
The once-glowing reputation is being tarnished
The main problem here, however, is that this attrition has been happening very slowly over a number of months and not everyone has noticed—they're all too busy trying to deliver.
Let's now revisit the process flow for delivering software and see what's changed since last we looked—it's not a pretty picture.
Software-delivery process flow Version 2.0
As you can see from the following diagram, things have become very complicated for the ACME team. What was simple and elegant has become complex, convoluted, and highly inefficient. The number of steps and barriers has increased, making it extremely difficult to get software delivered. In fact, it's increasingly difficult to get anything done. The following figure gives you an overview of the ACME Version 2.0 software-delivery process:
If I'm honest, the process as depicted is actually missing some additional detail in relation to the change-management hoops that can add more complexity, effort, and pain. Let's add this detail and look again:
As you can see, things are far from ideal. What was efficient and effective is now the exact opposite. More importantly, the dialogue, quality of the communication, and trust between all of those involved in delivering changes is at best fragmented and pretty much non-existent at worst. What used to be a five-minute chat over a coffee is now a 20-page email thread, meetings, and Skype chats. The ex-ACME engineering team members are less like colleagues and more like entrenched combatants.
Not only is the process long-winded, but the chances of a single change getting all the way through the process without issue is very slim—most of the time, changes have to go around the loop a number of times before they can be classed as shippable; for example, a defect found within any part of the process may push the change all the way back to the beginning of the process.
I mention dialogue, quality of the communication, and trust for a very specific reason—most of the things you read about and hear in relation to CD and DevOps seem to imply that some new tooling and best-of-breed architectural approaches will give you what you need. While this can help, it can also massively hinder—especially when trying to bring these changes on board whilst a business is going through organizational changes and/or growth. In the ACME example, too much was changing too quickly for everyone to understand what was going on and where the journey would end. This inevitably lead to human nature kicking in and people building up barriers and silos to add some stability within the chaos.
If you were to take all of this into account, from an outsider's perspective, the process(es) ACME systems uses to deliver software is now, for all intents and purposes,broken.
OK, so this may be a little over the top, but it just goes to highlight how having a relative chasm between those involved in the delivery of changes—especially the R&D team members (who are tasked with delivering much-needed changes and features) and the operations team members (who are tasked with supporting the live environment into which the changes will be applied)—can completely derail things.
An outsider's perspective from the inside
As was previously stated, not everyone noticed the attrition within the organization—luckily, a few observant souls did. A small number of the ACME team's members were aware things are not great and decided to step back and look at things from an outsider's perspective. They then started to see the issues within the overall process as clear as day and became determined to expose these issues for all to see. In addition, they decided to sort the issues out—there was just the small problem of how to do this while everyone was going at full pelt to get software delivered at all costs in their own silos with their own problems.
At first, they invested a vast amount of personal time into investigating and building rough and ready tools, including build and test automation, Continuous Integration (CI), a continuous-deployment pipeline, and system-monitoring solutions. The intention was to automate as many parts of the broken process as possible to reduce the pain. They also applied energies evangelizing within their technically-focused peer groups. Although their ideas and suggestions were welcomed by the majority, there was not the appetite to adopt these new-fangled tools—everyone was far too busy trying to ship software within the broken process. They needed another way.
They decided that they needed some assistance, so they sought out a like-minded manager with influence within the wider business who could help them get some much-needed traction. After much cajoling, discussions, and pleading, the manager agreed to help them to obtain budget to form a small team focusing on advancing the CD and DevOps tooling. The newly-formed team's members spent a few months identifying and breaking down the immediate and most painful issues, and built, installed, and implemented tooling to remove some of the pain—to ease the adoption, many of the tools are bespoke to fit into the existing processes.
This went some way to address the broken process but the reality is that the tools did not have the impact they envisaged. In fact, the tools themselves needed to be altered so much to fit the existing process that they started to become unreliable and too complex, so much so that those who were originally behind the approach started to question the validity of their decisions.
Ultimately, there is a much bigger issue that tooling cannot address—the culture of the organization itself, the behaviors of those within it, and the many disjointed methods of communication between the disconnected silos that had formed over the years. It became obvious that all the tools and tea in China will not bring pain relief; something more drastic was needed.
The team's members refocused and soon realized that it's not the tools that need to change to fit the process, but the process and ways of working that needs to change. If this was addressed, the tools could simply be taken off the shelf—so to speak—and used without extensive modification. The team's members have to drastically change their direction, become less technology-focused, and act more like agents for business change. They then highlighted this now-obvious fact to as many people as they can up and down the organization while the influential manager worked to obtain backing from the senior leadership to implement far-reaching business change. Luckily, their reputation and standing within the organization was such that getting backing was easy.
We're now going on to the third stage of the evolution, where things start to come back together and the ACME team regains their ability to deliver quality software when it is needed.
ACME systems evolution phase 3.0
Now that the CD and DevOps team has official backing from high up, its members start to address the broken culture and behaviors, and develop ways to overcome and/or remove the barriers. They are no longer simply a technical team; they are a catalyst for business change.
The remit is clear—do whatever is needed to streamline the process of software delivery and make it seamless and repeatable. In essence, implement what we now commonly refer to as CD and DevOps.
The first thing they do is to go out and talk with as many people across the business as possible to ensure they are also aware of the broken process and its root causes. Simply put, if someone is actively involved in the decision-making process of getting software from conception to consumer, or involved in supporting it when it's live, they are a chat target. This not only gathers useful information, but also gives the team the opportunity to evangelize and form a wider network of like-minded individuals.
The team has a vision, a purpose, that its members passionately believe in what needs to be done, and they have the energy and drive to do it.
Over the next few months, they embark on (among other things):
Running various in-depth sessions to understand and map out the end-to-end product-delivery process
Refining and simplifying the tooling based upon continuous feedback from those using it—where applicable, replacing in-house built solutions with off-the-shelf ones
Addressing the complexity of managing dependencies and the order of deployment
Engaging experts in the field of CD and DevOps to independently assess the progress being made (or not, as the case may be)
Arranging offsite CD and DevOps training and encouraging both R&D and Ops team members to attend the training together (it's amazing how much DevOps collaboration stems from a chat in the hotel bar)
Reducing the many handover and decision-making points throughout the software-release process
Removing the barriers to allow developers to safely deploy their own software to the production platform
Working with other business functions to gain trust and help them to refine and streamline their processes
Removing the us-and-them attitudes and behaviors, and reinforcing trust-based relationships
Working with R&D and operations teams to experiment with different agile methodologies, such as Kanban, scrum, and lean
Openly and transparently sharing information and data around deliveries and progress being made across all areas of the business
Replacing the need for complex performance-testing with the ability for developers to closely monitor their own software running in the production environment
Removing the need for downtime to release changes
Evangelizing across all areas of the business to share and sell the overall vision and value of CD and DevOps
This is by no means a walk in the park and it takes determination, steadfast focus, patience, and, above all, time to produce quantifiable, positive results, however after some months, the vision and benefits start to be realized. Now the process of building and delivering software has transformed to the extent that a code change can be built, fully tested, and deployed to the production platform in minutes many times per day—all at the press of a button and initiated and monitored by the developer who made the change, all with no downtime and little/no impact on the customers. The stakeholders have a trusted and reliable way of delivering value to their customers, the R&D team has the tooling and empowerment to deliver value as and when it is needed, and the Ops team has a stable and reliable platform that it can support and optimize.
Let's look again at the software-delivery process flow to see what results have been realized.
Software-delivery process flow version 3.0
As you can see from the diagram, the process looks much healthier. It's not as simple as Version 1.0, but it is efficient, reliable, and repeatable. Some much-needed checks and balances have been retained from Version 2.0 and optimized to enhance rather than impede the overall process:
This highly efficient process has freed up valuable R&D and operations resources so that they can focus on what they are best at—developing and delivering new high-quality features, and ensuring that the production platform is healthy and customers are delighted.
The ACME systems team has got back its mojo and is moving forward with a newfound confidence and drive. It now has the best of both worlds, and there's nothing stopping it.
ACME systems beyond Version 3.0
The ACME systems team's members have come through their challenges stronger and leaner but their story doesn't end there. As with any successful business, they don't rest on their laurels but decide to expand into new markets and opportunities—namely, to build and deliver mobile-optimized clients to work with and complement their core web-based propositions.
With all they have learned throughout their evolution, they know they have an optimal way of working to allow them to deliver quality products that customers want, when they want them, and they know how to deliver quickly, reliably, and incrementally. However, the complexities of delivering features to a hosted web-based platform are not the same as the complexities of delivering features to an end consumer's mobile device—they are comparable but not the same. For example, the process of delivering code to production servers many times per day is under the control of the ACME team, whereas they have little or no control over how their mobile clients are delivered to end customers, nor if and when the end customer will install the latest and greatest version from the various app stores onto which the mobile client is published. In addition to this, the production platform onto which the mobile client will be installed is pretty much an unknown in terms of spec, performance, and storage.
All is not lost, though—far from it. The members of the ACME systems team have learned a vast amount throughout their evolutionary journey, and decide to approach this new challenge as they had done previously. They know they can build, test, and deliver software with consistent quality. They know how to deliver change incrementally with little or no impact. They know how to support customers and monitor and react quickly to change. They know their culture is mature and that the wider organization can work as one to overcome shared challenges.
As the new venture progresses, they also discover another side-effect of their newly rekindled success: the amount of traffic and transactions start to grow very quickly. They therefore need to scale out their platform and they need to do it as soon as possible. Rather than rely on their own datacenters, they decide to move their entire platform to a globally-distributed cloud-based solution. This brings with it new challenges: the infrastructure is completely different, the provisioning tools are new, the tools used to build and deliver software are incompatible with the existing ACME tools. Again, the ACME systems team take this in stride and forge ahead with confidence using the highly collaborative ways of working, techniques, and approaches that are now part of their DNA.
Let's look at what this all means from a holistic point of view.
The evolution in a nutshell
Throughout this chapter, we have been following the evolution of ACME systems: where they started, the growing pains that came from success, how they discovered that rapid growth brings with it negatives as well as positives, how they overcame their near extinction by adopting CD and DevOps, and how they regained their mojo and confidence to move forward. All of this can be represented by the following simple diagram:
What they also learned—somewhat late in the evolution—was that CD, and DevOps-adoption has little to do with technical tools and everything to do with how people work together. Without the changes to the culture and behaviors of everyone involved in the end-to-end delivery process, it is almost impossible to realize and maximize the benefits that a successful adoption of CD and DevOps brings. It could be said that if they knew this simple, yet mostly overlooked, fact from day one, then the adoption would have happened sooner and the business would have been far stronger far sooner. Hopefully, this will provide some food for thought for you as you move through the rest of the book.
Where am I on the evolutionary scale?
At the beginning of this chapter, I stated that the effectiveness of adopting CD and DevOps is very much dependent on where a business sits on the evolutionary scale. We've been through ACME's evolution and the phases it went through. Please take into account that ACME is fictional and its story is pretty simplistic. A real-world business is not simple—far from it—and it is pretty difficult to ascertain where a given business sits on the CD and DevOps evolutionary scale. Without this information, it's hard to understand how receptive, responsive, and open to adoption a business actually is.
With that said, there are some simple ways of getting a clearer idea. For example, the following list of questions can help you get a rough idea. Looking at your business, ask yourself the following:
Option #1
Option #2
Option #3
Does your business favor process over people?
Process
People
We don't have any processes worth mentioning.
Do immovable deadlines in project plans take precedence over delivering quality solutions incrementally?
Yes, meeting deadlines is the only thing that matters.
