What Is DevOps?
DevOps is a professional, cultural movement. It not only aims at harmonizing collaboration between software development and operations, but has the broader goal of optimizing the whole software development process: from idea to delivery of a useful product or service.
DevOps tries to extend agile, which is now commonplace in software development, into the realm of operations. Lean principles, like continuous flow, build the foundation of DevOps. This is reflected in the adoption of practices like continuous delivery or infrastructure as code.
Continuous delivery enables the team to release software in small batches as soon as they're done. Immediate release of these small batches creates tight feedback loops across team boundaries which helps bring everyone together: development and operations act on shared knowledge about the current situation. This is one of the cornerstones for a successful DevOps culture.
The DevOps hype produces some strange effects. Not only do tool vendors try to jump on the DevOps band wagon by declaring their products “DevOps inside” or listing DevOps as a feature, but companies start to look for a “DevOp” in their job ads. Don’t be misled! Here’s what DevOps is really about:
Instead of escalating wars between departments by driving them to ever more ambitious, local goals, we need to break down the wall between development and operations. Defining overarching goals which resonate for both departments creates an environment where DevOps collaboration may thrive.
Without monitoring, server changes can’t be analyzed to see you’ve really made things better (or even worse). And without testing, every commit you make is a risk to the running site.
How do you see agile affecting application development and delivery?
The biggest impact is that application development teams are using agile to speed up their delivery of software changes and updates. This makes the developers happy as they can get through requests faster. However, releasing that software out to the organisation is different: small teams are responsible for their own releases, while larger organisations have dedicated staff that handle getting software out to the business.
Whatever size you are, the increasing number of releases will have an impact on the overall process. One customer I spoke to recently has taken up agile, and gone from 50 releases per year up to 350. That is a huge increase. While the amount of code might be smaller, the change procedure will be the same, and that puts pressure on the overall application delivery process and the staff who release the software. This introduces the risk of there being undiscovered errors in the release. And that might mean production outages.
It’s been a while since I talked about how we develop and deploy software at my current job. It’s come a long way from the “Good Ole Days”, when cowboy coders manually FTP’d their changes to the master server and rsync came along 5 minutes later to replicate the changes to the slaves *shudder*. Keep reading below for the details.
How hard could it be? Well, like with most engineering endeavors, it’s about 99% preparation and 1% implementation. Unlike Continuous Integration, however, continuous deployment (CD) involves business as well as technical considerations. Let’s outline them and see how close (or far) we are to the holy grail of DevOps.