I was fortunate enough to catch the live stream of DevOpsDays, held at the tail end of the Structure 2013 conference in San Francisco a couple of weeks ago. There were many really good presentations, and I picked up on a common theme. It appears, and I have seen it first hand, that there is still a lot of confusion about what DevOps really is. Some companies think it is an IT role, like some kind of super systems administrator who can also magically code like a stud programmer. These companies create a new silo called “DevOps” and defeat the whole purpose of what DevOps is intended to do. One by one, presenters at DevOpsDays stomped their feet and said “DevOps is not a role, it is a culture shift!”
What is DevOps?
DevOps is a culture shift or a movement that encourages great communication and collaboration (aka teamwork) to foster building better quality software more quickly with more reliability.
Many IT shops practice some form of an agile methodology, but often the methodology focuses more on the features and not enough on architecture and operations. Developers take all kinds of shortcuts to hit their dates, and operations is brought in late to stand up environments and get the application deployed in the final hours. The operations team also has to take shortcuts in order to get a product that they only partially understand out the door. This worst practice results in new software loaded with technical debt. It is like building legacy software! This is the art of Fragile.
The DevOps movement started as a grassroots effort by a few practitioners who were tired of the “fragile methodology” and were seeking a better way. These early pioneers were kicking around the concept of “agile infrastructure”, but it was a presentation at the 2009 Velocity conference by the Flickr team called 10+ Deployments Per Day: Dev and Ops cooperation at Flickr that shifted the movement into high gear. Suddenly, DevOpsDays meetups started forming around the world and the term DevOps was born from the use of the Twitter hashtag #DevOps, short for DevOpsDays (see Damon Edwards’ post called The History of DevOps for the full story).
No more silos
DevOps takes a page from lean manufacturing and sets out to maximize the flow of work by finding and eliminating waste. Silos are flow killers. When we have silos, people within the silos do not have full visibility into the entire flow of work, which leads to a lack of understanding of the system as a whole. Silos also create artificial hand-offs between groups, and as projects approach due dates, the silos towards the end of the flow are forced into fire drill mode to get product out the door. Silos create fragile systems.
DevOps fosters a system thinking mindset for the software development life-cycle. Any step that is repeatable should be automated. What types of things are repeatable? Builds, deployments, provisioning environments, etc. But to make these repeatable, it takes a team effort. Automating builds, deployments, and infrastructure takes great collaboration between developers and operations. Sure, an operations person can write a script to provision an environment, but that environment is not useful to the developer until the developer configures it to meet the needs of the application. The solution is for dev and ops to collaborate on the environment specs and together build the appropriate automation scripts that can provision environments with a single touch of a button without the need of additional configurations. That is how you eliminate waste.
From Fragile to Agile
Companies that have a fully automated deployment process enable their company to release software more frequently, thus making their business more agile. The thought of releasing daily or even multiple times a day can be scary to those who are used to the big monolithic deployments that many of us have experienced in our lifetimes. Often these big deployments are at least partially manual, if not totally manual, and they depend on a critical resource to pull off miracles in the early morning. This can lead to hiccups along the way, and a group of people who drew the short straw must scramble to put out fires before the sun comes up in the morning.
In a DevOps culture, fragile is not in the vocabulary. A heavy dose of continuous integration and continuous delivery is used to prevent the 4am scramble that we all dread so much. In the old model, software is considered erroneous until someone in QA tells us otherwise, usually late in the process. With continuous integration, software is considered valid until the build tells us it’s not. That is because continuous integration forces constant check-ins of code that must pass a set of automated tests. If the code does not pass the tests it does not get in the build. The end result is a build that has working code all the time.
Continuous delivery takes it one step further. Where continuous integration enforces execution of test harnesses for a given piece of code (unit testing), continuous delivery forces automated builds and deploys code into an environment like QA or stage so that the code can be tested within the entire system (system testing). The thought process here is that developers get faster feedback on defects and correct them earlier in the life cycle, as opposed to the legacy method where late in the project large amounts of defects are discovered and then go through a prioritization process to figure out which ones can be fixed with the time remaining in the project. With continuous delivery, the mindset is to fix issues immediately and not carry them forward. The end result is better quality software.
Continuous deployment is the process for releasing code into production as soon as it is ready. Companies that practice continuous deployment often let their developers deploy their code themselves. Sounds crazy doesn’t it? But think about it. If code can only make it into a build if it passes automated testing, and finished code can immediately be delivered to a clean automated environment that matches production where it gets validated within the entire system, why wait to deploy it? Why wait for other features and create dependencies? Isn’t that just creating waste?
If you work with fragile systems, pick up the book The Phoenix Project and give it a read. You can blast through it in a week. The book is a fictional story about a guy who gets put in charge of a very chaotic environment with very fragile systems. See how over time he applies lean thinking and eventually digs his team out of the fire drill culture into a DevOps culture.
Summary
The next time somebody tells you they work on the DevOps team, slap them in face (not literally!). DevOps is not a role or a group of administrators on steroids. DevOps is a mindset of moving away from fragile systems that take too long to deploy to reliable software that can be deployed quickly. DevOps requires great collaboration and teamwork, not just within IT, but also with management and product. Join the DevOps movement and turn fragile into agile.
Thank you for the interessting post – we use agile in pratice and I can say that it really makes the work much more productive and comfortable both for client and for dev elopers. Think now all IT companies need to implement agile, if you do it – you’ll see the reasult really soon!
“Software is considered erroneous until someone in QA tells us otherwise, usually late in the process.”
Well yeah, but erroneous in what way?
There are multiple ways of getting that Quality feedback and the time between the delivery of software as short as possible.
Agile and Scrum are fairly successful in reducing the feedback time period.
The way I’m used to testers is up front with the Development Team getting the specs (User Stories) right. Answering the question “Is this what you want us to build/assemble?”. The tester will then develops test (either automated or manual ones) that will test if the output is according to specs and some performance metrics. And then it becomes a business decision to Go Live with the piece of software with the test report attached stating a quality (or lack thereof).
The point I want to make is that testers have a big part in addressing the quality of the functionality and that there are other ways with for example CI / CD with the technical quality.