The first keynote of the Agile Development, Better Software & DevOps Conference West was Why DevOps Changes Everything, by Jeffery Payne. There are definitely tools and processes that can help streamline a DevOps shift, but Jeff said that fundamentally, building a culture where everybody can communicate and collaborate effectively is key.
The first keynote of the Agile Development, Better Software & DevOps Conference West was Why DevOps Changes Everything, by Jeffery Payne. Jeff is the founder and CEO of Coveros Inc., a consulting firm that has been implementing DevOps solutions since before the movement was even officially called DevOps.
As anyone who has dipped a toe into DevOps knows, there are many different definitions. Jeff addressed this, but he stressed that what it really comes down to is a culture shift toward collaboration and communication among everyone at every point in the software lifecycle.
The goal is to reduce downstream errors, find bugs earlier in the process when they're cheaper to fix, and replace costly manual efforts involved in setting up and maintaining environments with automated processes as much as possible. There are definitely tools and processes that can help streamline a DevOps shift, but Jeff said that fundamentally, building a culture where everybody can communicate and collaborate effectively is key.
Of course, this is not always easy. The conflict in DevOps is the push-pull between development’s need for change, in order to deliver a rapid rollout and provide value to customers; and operations’s fear of change, because they want stable conditions to ensure secure and predictable production systems. The purpose of DevOps is to get these two very different camps to work together so that quality products can be delivered faster without jeopardizing the efficient environment.
The ultimate use case to aspire to here is continuous integration. Developers and testers can continually build, integrate, and test software without breaking other features, and make sure it deploys and runs downstream. In order for this to work properly, you need a mature code-branching and merging strategy with versioning for each integrated build. With a healthy system, you can make sure your code works downstream in every preproduction environment, preferably virtually in the cloud. This is not always possible, but as much as you can, you want to try to test all code change in every conceivable environment.
Another important use case is continuous delivery: You can continuously deliver working code to downstream environments for testing and verification. You want to make this as automated and seamless as possible so that you can do it whenever you want. For that, you’ll need quality gates—definitions of "done" for each step of your deployment and delivery process—and artifact repositories to control application flow and control, tag, and version each build you make. Testing activities for each stage in this process depends on your environments, but they should be ensured to pass through the established quality gates.
So, how does DevOps change everything? First of all, it’s good for business. Automating environment setup and maintenance frees teams to be more productive and smart elsewhere, and automating application delivery and configuration reduces the number of costly mistakes.
Jeff also said that in his opinion, DevOps is the best thing to ever happen to testing. He introduced a new acronym, GIGAD: garbage in, garbage automatically deployed. Testing has to be integrated into the whole process, pulling development into quality and testing earlier in the lifecycle and putting quality gates at every point in the lifecycle. Testers are always viewed as the naysayers, Jeff said. DevOps can help move testers away from the stigma of “quality police” because the builds and gates act as the watchdogs. Testers become part of the solution.
A big way DevOps changes everything is that it forces collaboration. Most of our issues in software are not technical—they’re interpersonal. People aren’t communicating effectively with each other. DevOps tears down barriers and makes everyone part of the same process. Strong collaboration among everyone in the software supply chain builds new culture and spurs change.
DevOps also drives improvement. Agile used to drive DevOps, but Jeff said that his experience now when he consults for businesses is that they first want to implement DevOps. As they undergo that process, they realize they have to become more agile, too. Jeff also pointed out that he thinks the name “DevOps” is unfortunate because it makes people think it only involves development and operations. Really, he said it should be called “Dev to Ops” because it’s for everyone along the pipeline.
Lastly, DevOps is what Jeff called “blinky”—referring to the phenomenon that management loves things that blink. Cool machines with lots of lights going on and off are impressive! DevOps also “blinks”: It’s easy to show, and it’s easy to see the benefits. Integrated dashboards provide progress reports and visibility easily, so the higher-ups understand what it’s doing. (Plus, it’s the hot new acronym. Management loves new acronyms, too, he joked.)
There are things you can do to move toward a good DevOps process. First, start simple. Begin by inviting other people along the supply chain to your standup meetings, and eventually they’ll understand what you do and contribute ideas also. Jeff also said to “use the power of blinky.” Show what DevOps can do and get management’s attention. He also recommended embracing the skeptics. Explain the benefits to them, and when other coworkers see that the notoriously disbelieving person is on DevOps’s side, it will get more people on board.
Jeff closed by saying, “You started with a dream, and I gave you reality. It’s time to get to work.” Go forth and implement DevOps!