Posted by: Alan Sharp-Paul
when relevant content is
added and updated.
You’re never safe in Enterprise IT. Just when you feel you’ve gotten a handle on the last hot topic you’re hit with another. SOA, BPM, Agile, ITIL; You feel like screaming “Enough!” but you know resistance is futile. Gartner have said it’s important so you know full well that you’ll be asked to “do” it by management.
The latest buzzword in IT is DevOps. DevOps is more philosophy than process. It is a recognition that the relationship between developers and operations staff was broken. Developers are expected to ship more code, more frequently. Change is their friend. Ops are expected to keep everything running smoothly, to protect uptime. Change is their enemy. Something had to give.
At its core, DevOps is simply about improving collaboration between development and operations teams. As an extension of Agile, it means including system administrators in the agile development process. In practice, DevOps has also come to be associated with various tools such as infrastructure automation, automated testing, CI/CD and monitoring tools.
You’re in the Enterprise though. Where do you start with DevOps? As most Enterprises these days run on ITIL processes, this is a pretty good place to start. Despite the rumours, DevOps doesn’t mean the end of ITIL. DevOps should be seen as a means of ITIL process improvement. By using ITIL processes as a basis for a DevOps initiative, you can greatly simplify and focus your efforts.
I recently wrote an eBook aimed at Enterprises explaining a methodology for using ITIL as a basis for their DevOps implementation. Here are some of the highlights:
If your change process is a bottleneck then chances are it’s because that’s all it is to your Enterprise, a process. You’ve followed all the advice of ITIL and have appropriate prioritizations, approvals and stakeholders, but guess what? You’ve taken the human element out. Email approvals are handy, but people are much more likely to reject approvals when they haven’t been consulted appropriately and are not face to face with the person responsible.
So, the best “DevOps” initiative we can implement within change may not really feel like DevOps at all. It’s simply good practice to improve collaboration between stakeholders in the process. The main goal is to make consultations between groups proactive, not reactive.
Release & Deployment Management
This is an area where the automation side of DevOps really comes into play. Automated deployment, automated testing and continuous integration are key.
When managing environments and moving applications through them, consistency is what you want. The first step towards that is consistent builds. Automated deployment tools are a must. No PM wants to hear that it will take 3 days to get UAT ready for testing. Tell them it will be deployed, validated and ready to go in a matter of minutes and you’ll be assured of a seat at the project completion lunch.
How about keeping it that way? Automated testing, both functional and configuration, will help maintain consistency (or prevent the promotion of issues in the case of functional testing). One sign of an advanced IT shop is the implementation of monitoring solutions earlier in the process. Proactive identification of problems and inconsistencies is the key.
Painful code merges and unecessary scheduling delays can be mitigated by the use of continuous integration tools, where all development branches are regularly merged into an integration branch. Also, automated tests are run with each merge to catch conflicts early and reduce regression testing requirements when it is time to go live.
Like the Change Management process, the Incident Management process will naturally receive flow on benefits in the form of reduced incident numbers when initiatives in other areas such as automated testing, deployment and continuous integration are put into action.
Perhaps the best example of how a DevOps mindset can assist the Incident Management process is the practice of making sure that development staff also go on call. The benefits from this are twofold. Firstly, seeing development staff playing their part and standing on the front line improves the camaraderie with the operations team. Secondly, an understanding of the impact their code has on supportability makes developers better coders as well
Automation is the key here. Whether a deployment, a test or an approval, each time you automate something you are effectively capturing knowledge. ITIL may disagree with this definition but it is the only practical one.
Get Started Today!
By using your ITIL processes as starting points for analysis of potential benefits, an Enterprise DevOps implementation is given greater focus. Identify pain points that could benefit from greater collaboration and automation. Prioritise them based on potential benefit and estimated effort. Get started today though. otherwise your business will most like certainly be left behind.
If you’re interested in reading more you can download the full ITIL Guide to DevOps eBook here.