It's the Ranger4 #DevOpsFriday5 series - today's contributor is Mark Roberts. He's DevOpstastic!
1) How would you describe the relationship between DevOps, Agile and ITIL?
Agile is often thought of as operating in a very narrow scope - just within the confines of the main software creation activity. When implementing Agile practices many organisations have improved the interaction with the business users through story elaboration and frequent feedback. What DevOps needs to do is extend those same practices into the operational areas of an organisation so that there is more frequent delivery of smaller packages of change. This lowers risk due to the scale of change and it also exercises the deployment and release processes more frequently. ITIL is often looked upon as a process for managing the software delivery process and overlaps with what the DevOps team would often refer to as release management. Clearly there are a lot of documented processes and procedures that ITIL brings to an organisation and within that there are specific activities of deployment such as the update of an application. In terms of a layer of an onion Agile is in the centre, DevOps wraps around Agile and ITIL wraps around DevOps. Clearly these three different practices can have different objectives : creativity and rapid change of agile, compared to procedural rigour of ITIL. The organisations performing DevOps well are able to reconcile these differences and work in harmony.
2) Can you describe what DevOps looks like when it’s ‘done’?
A good measure of DevOps 'done' is traceability. Can you point to a release of software running in production and then quickly and easily trace right back to the lines of code changed for that release and the change management tasks, requirements and business drivers ? Can you trace from a requirement to deliver functionality and identify exactly when that was released into production? Another measure of DevOps 'done' is the singular processes. Do you have a standard way to deploy each specific technology that is the same across all environments. Do you have a clear adit trail, a separation of responsibility and a security model that controls who can do what and when ?
3) What do you think are the key metrics for DevOps?Operational cost and risk are two measures that organisations focus on today. The costs associated with many web applications have spiralled out of control, often due to the number of people with hands on keyboards performing deployment operations by hand. This had a natural impact on risk due to human error. So it follows that lowering operational cost with automation increases the repeatability of processes and the consistency across the route to live. A natural by product of this is a reduction in risk. If you lower the cost of doing something then you are happy to do that task more often. This allows the size and complexity of change to reduce which again lowers risk and makes the organisation more reactive. So while some are measuring the number of deployments, the percentage roll-backs and the time taken for deployments, those at the top of the organisation simply want to know how risk and cost have been lowered.
4) What attributes constitute a culture embracing DevOps?
A flattened organisational structure shows a company that embraces DevOps. When I was a developer on safety critical, real-time embedded systems products in the 1990's I had a project manager who made sure everyone understood the architecture of the system being developed. There were no isolated silo's, and everyone knew where their specific part of the jigsaw fitted in. The consequence of this was great awareness and better engagement to solve problems. The DevOps culture should be similar to that in that everyone is aware of the scope and architecture of the application under development and everyone understands the broad challenges of business analysis, requirements, development and deployment. Breaking down silo's and ensuring there is no 'throwing content over the wall' to the next team is a sign of a DevOps culture. If you have little awareness of what your peers are doing you will throw applications and problems over the wall to them.
5) Is Continuous Delivery the ultimate goal of DevOps? How do other ‘Continuouses’ (continuous deployment, testing, improvement etc) contribute in a DevOps transformation?
One of the aims of DevOps as a practice is to be able to continually delivery new versions of software and configuration changes to an operational environment. Since requirements, development, testing and deployment are all cogs in the same gearbox then it follows that they all need to move continuously too. Agile development teams creating builds every 30 minutes that were consumed at a rate of 1 a week by a deployment team is a classic example of the gears now working together and the continuous feed of change being broken.
Mark holds a Bachelors Degree in General Engineering and a Masters Degree in Distributed Systems Design, has over 20 years experience in a wide variety of computer systems and is a Member of the British Computer Society and a Chartered Engineer. Mark was a senior Engineer at ALSTOM T&D where he was responsible for the creation of software solutions using ‘C’, Assembly code, PERL and Fortran for PC, mainframe and real-time embedded platforms.
Mark joined Rational Software in 1999 and after focussing on change and configuration management solutions has expanded the coverage of the software development lifecycle to include requirements, test automation and deployment. During his IBM career Mark has worked in roles covering technical consultancy, product management, marketing and services management. He is currently serving another term of pre-sales consultancy focussing on the Rational collaborative application lifecycle management solutions.
Follow Mark:Do you have something you'd like to say about DevOps? If you would like to be featured on #DevOpsFriday5 click the button below.