Where DevOps can make a difference
The positive change that DevOps brings for enterprise IT is becoming more and more obvious. And yet DevOps success doesn’t come easily. When it comes to implementing a DevOps approach together with Continuous Delivery, the key to success is trust and visibility.
DevOps – the development method that stresses communication, collaboration, integration, automation and co-operation between software developers and IT operations – has been a perpetual theme in the world of IT during 2015. DevOps may not be a new concept but it is starting to enter prime time usage. If Gartner’s prediction is correct, then around a quarter of the world’s top 2,000 organisations will be using DevOps by 2016.
This broadening of usage and realisation of the potential benefits of DevOps has driven innovation in a wide variety of technologies, including the rapid rise in popularity of Jenkins, Chef, Puppet and software-defined infrastructure. Almost coincidentally, but perhaps not completely independently, new application deployment models including microservices and containers such as Docker have become increasingly popular. All of these elements help to connect the developers and operations teams.
DevOps is certainly making a significant impact on how businesses can streamline their product development processes. Where maximum benefits can be achieved is when DevOps is considered in the context of a broader Continuous Delivery (CD) approach. According to Evans Data Research in 2014 CD was, even back then, already being adopted to some extent by two-thirds of all organisations surveyed, even if they did not use the CD label. The indications were that even those organisations that had not yet started CD adoption intended to do so, at least partially, in the near future.
DevOps and CD are a good match. Continuous Delivery is all about creating a more collaborative, cohesive and timely environment to take software projects from inception to deployment, with the software being ready for release into production at any time. Key to Continuous Delivery is the use of rapid feedback loops, from automated build and test systems and customers, back into the planning pipeline. Various techniques are useful for successful CD: ensuring products are always (at least theoretically) releasable; release cycles kept short to enable re-prioritising; adjusting plans based on feedback; and making releases in small, manageable chunks. After all, one of the major problems with traditional “waterfall” projects were those instances when releases were only made every 12 or 24 months. These longer release cycles often meant that they contained so many changes, so it was impossible to work out which actually worked or had errors. The chances of success were very low.
An extreme example of CD might be major web services such as Amazon or Facebook, who may be releasing updates into production many times per hour (or even per minute). That may not be a pattern that most companies would want (or could manage) but even getting releases out weekly or monthly is a challenge for many. If release cycles are to be as short as possible, it becomes clear why DevOps, executed in the right way, is a major enabler of CD success. The goal of DevOps is to remove those “speed bumps” that have traditionally interrupted the flow of change from developers to customers and have proved, too often, to be the biggest inhibitor to CD adoption.
Successful DevOps and Continuous Delivery
So far so good – at least in theory: turning that into an actual successful deployment is quite another. Building an appropriate tool chain is a good start. Developing a well-understood process is also needed. But perhaps the most influential factor is adopting the right culture. There is no simple “one size fits all” answer to solving the culture clash issues between Development and Operations, but fundamentally the keys to success are trust and, closely related to that, visibility. Developers should understand the needs of the Operations team; Operations teams should understand what Developers are building and work with them to create applications that will be easy to deploy and manage.
That’s not to say choosing the right tools is not important. Existing ones may hinder – even prohibit – successful adoption of DevOps and CD, so this might be the time for reassessment of your current tool set and processes. Regardless of the tools being used, some very clear “Best Practice” steps have evolved over the past couple years. Based on experience of working with customers, here are my top five areas to consider:
1. Think beyond code
All assets need to be controlled as part of the project – artwork, designs, documentation, configuration scripts, binaries and so on – otherwise there is a real risk of releasing incomplete or inconsistent applications, ultimately leading to customer dissatisfaction.
Automating processes helps reduce chances of error and reduces reliance on individual heroes. While not every aspect of the project can be automated, the more that can will enhance predictability and repeatability, thus supporting a faster and more productive release pipeline. Successful DevOps and CD depends on a unified, continuous pipeline that supports automation at every step of the process.
3. Test intelligently
Plan automated testing as part of the continuous integration (CI) pipeline. Careful planning is needed to ensure adequate coverage without being so slow that rapid releases become impossible. Picking the right tools and hardware are important factors, but so is doing the “right” amount of testing and not more than is needed. There is no easy way to predict what this means and needs to be considered within the context of each project. Feedback from the testing has to be quickly returned to developers to be addressed. Remember to also consider how security testing can be incorporated in the test plan and how security requirements are included in project planning in the first place.
4. Version everything
At the core of a good CD and DevOps marriage is a single, highly transparent repository of all assets or artifacts. This does not just mean having the ability to see what is happening now (and who is doing what), but also a “history” from creation through to deployment, with clear accountability and the option to “roll back” to a previous version if need be.
A high quality of tracking will mean that all changes and interdependencies are delivered as a complete release, making it easier to carry out any debugging. When choosing a version control engine for this purpose, think about whether it can handle all the different artifact types needed and if it can scale as the organisation’s products or distributed development environments grow. Is the version management tool fast enough to support rapid and frequent CI build and test?
It’s also important to consider security: after all, all the source code, designs and so on may represent your organisation’s most valuable intellectual property. Many existing version control systems may not have these capabilities and thus are not fit-for-purpose as far as DevOps and CD are concerned.
5. Tools and culture need to work together
Tools such as version control play an important supporting role, but cultural attitude is everything. As well as securing support from management level, successful adopters of CD and DevOps have also developed internal “champions” who educate and help their peers.
DevOps and Continuous Delivery both have vast potential to improve or even transform the production and release cycles within all kinds of organisations. Making sure that the right foundation of tools, process and culture from day one will help turn this promise into demonstrable improvements.