Recently I’ve worked with a number of clients who are enthusiastic to start introducing DevOps practices into their organisations. DevOps has definitely gained a lot of momentum and buzz in recent times, and it’s been interesting to assist as organisations approach its introduction in different ways.
Over the course of these engagements I’ve observed a few key themes and considerations that can really influence the success or otherwise of starting on the DevOps journey.
DevOps Permeates the Organisation
Thinking of DevOps as simply a bunch of clever automation put in place by geeky infrastructure guys is risky at best. As you’ll observe from a number of the other considerations I’ve listed, introducing DevOps can necessitate a shift in thinking from across the organisation, not just from traditional development and IT ops. I’m not suggesting your whole organisation needs to go on a “5-day DevOps fundamentals” course, but it’s equally important to appreciate that introducing DevOps can challenge traditional thinking and practices across the organisation. The more you can communicate and include other areas in the journey the better your outcomes are likely to be.
Process Doesn't Go Away
DevOps still relies on solid service management & operational principles. Processes such as IT change management, configuration management and release management are still as important as ever, and while you might be able to automate some aspects of them, unless you have a good starting point you may be automating less than ideal practices. You should also consider how any automation that you do put in place will interact with non-automated parts of any process, particularly where you’re integrating with traditional governance and authorisation entities like Change Advisory Boards.
Solid Requirements are Just as Important as Ever
Because DevOps spans development and operations for a product, there’s even more emphasis placed on having solid requirements not just for product features, but also on how the product’s expected to be operated. Even if you’re working in a more agile manner without heavy-weight up-front requirements, your backlog still needs to cater for non-functional and operational backlog items. In effect, your DevOps automation suite (whether it’s automating builds or tests or deployment or infrastructure or whatever) becomes another feature that you’re building and that needs solid requirements, or else you risk building the most amazingly automated wrong thing!
Packaging & Deployment Automation Needs to be Driven by Requirements (Just Like Product Features)
The design of your packaging and deployment mechanism (ideally automated via the DevOps tool chain) needs to be informed by requirements. It’s important to consider things like the anticipated types and frequency of change that will be made to the product being operated, and dependencies between products in an operational product set (if your service consists of more than one product). As a couple of examples of the impact this can have:
Types of change. If you have a monthly operational process for releasing change to information provided by your product, but the only way to deploy that change is by re-deploying the whole product, it can potentially create a larger operational process & testing overhead.
Granularity of deployment. Similarly, if you only design your deployment process so you can click a button to deploy the entire product set, what happens if you only want to (or need to) deploy a change to a single component?
Consider the Additional Testing Implications of More Frequent Deployment
DevOps can automate your deployment process to the point of deploying a new product version in seconds, but if you’re still relying on manual testing you may just be moving the overhead to your testing team. And if you’re in the fortunate position to be able to create a test automation suite to bring into the DevOps chain, consider the ongoing requirements to develop, test and maintain this test suite itself – it’s generally not a write-once, never-touch-again exercise. Test automation is about finding an appropriate balance between coverage versus risk of regression versus ongoing maintenance effort.
Can you Identify & Prove What's Changed?
Traditional IT change management & testing relies on the ability to be able to explicitly identify the components that have changed. If your DevOps deployment process relies on replacing running instances with new instances (even if the underlying component hasn’t changed), is this a change or isn’t it? Does it need to be tested or not? What’s required to prove that it hasn’t changed?
None of this is rocket science, but nonetheless it’s all important to take into consideration as you begin your DevOps journey. There are undoubtedly a raft of other considerations, and as with everything I expect for myself and Chamonix to continue to learn and grow as we assist our clients with their own journeys. Nothing in our industry ever stands still and every day is a fresh opportunity to re-evaluate what you knew yesterday!
