DevOps seems to be the new cool kid on the block lately, especially in Agile circles. New user groups are popping up and it’s a fashionable topic to talk about at conferences; Many of the more leading edge consultancies are working hard to establish themselves as having creditable practices in the space. Right now DevOps feels like Agile did 10 years ago.
Here’s the first paragraph from the top hit in google, it is of course from Wikipedia …
“DevOps is a set of processes, methods and systems for communication, collaboration and integration between departments for development (applications/software engineering), technology operations and quality assurance (QA)”
… and it’s 100% wrong. DevOps isn’t a process; Unlike Agile, DevOps doesn’t have a neat set of rituals to build the habits and enable the right communication and feedback cycles – perhaps we need to invent some. There are definitely some things like co-location which help, and getting everyone coming along to one daily standup isn’t going to hurt. But, you can do those things and fail to create DevOps.
Here’s another thing it’s not, Continuous Deployment. Releasing your software regularly and having an automated build and testing pipeline is another good process, it creates good habits and it does create closer ties between your developers and your ops group; But it’s not essential to DevOps and it doesn’t ensure you’ll have DevOps.
So here’s what it really is:
- Developers caring about deployment and production systems.
- Ops caring about the development of new features.
- Developers with access to production systems, monitoring and deployment processes.
- Ops engaged with feature development from the start.
It’s about creating a team of engineers, rather than a team of developers and a team of operations folks.
DevOps is just a neat new word to describe how little companies have managed their development and deployment for years – If you don’t have many people and you don’t have lots of departments then your developers get involved in deployments, and if you’re lucky enough to have a dedicated ops person then you can be sure they will be working with the development team as well, usually on the database and back end parts of your system. In bigger companies it’s not as simple, bigger systems mean more complex platforms, more sophisticated network configurations and database clusters. As projects get bigger it’s only natural, even essential that within your engineering team there are specialist roles. UI/UX specialists, back end, API and model specialists and DevOps is about engaging staff who would have previously been part of your ops team.
Just like Agile, DevOps means taking a leap of faith and seeing how things work out. Here’s how to start, get a developer to sit and type all the commands to deploy one of your system with an ops person looking over their shoulder – I promise you they will be coming up with ways to automate your deployment by the end of the day. Next time you have a performance problem, get your ops folks to pair with the developer working on it, matching up data from your system logs and monitoring system with the active code.
Just today I enjoyed watching a ‘developer’ and an ‘admin’ working together to shave 20% off the run time of our full test suite in 30 min just by building a shared understanding of what was required and tuning the platform together.
“‘Devops’ is a movement of like-minded sysadmins and developers interested in bridging the artificial gap between our camps. It’s impossible for sysadmins to do their job without reading or writing code, and developers need intimate systems knowledge to scale their software.
The walls between us are being broken down — it’s time to start learning from each other.” – www.devopsdownunder.org
