So, you want to do DevOps? OK, but before you start, let’s have a look at some of the things you shouldn’t do.
In the good old days, we just called them ‘bad ideas’, but along came diplomacy and political correctness. Out went the ‘brainstorm’ and in came the ‘idea shower’, and with it came the ‘anti-pattern’.
If the ‘pattern’ is the right way of doing something, then inherently the ‘anti-pattern’ is the wrong way. And so, to stop you going wrong, we’ve compiled this list (with a little help from the DevOps community).
1. DevOps is a Process
Not exactly. It’s a philosophy. It’s a way of thinking. DevOps is supported by process and tools.
According to DevOps author and enthusiast Gene Kim, DevOps is underpinned by three core principles known as the Three Ways:
- The First Way emphasises the performance of the entire system – the value stream.
- The Second Way is about shorting and amplifying feedback loops.
- The Third Way is about creating a culture that fosters continual learning and understanding.
(Find out more here)
2. Agile Equals DevOps?
If you’re asking this question, then you’re probably running some agile process. That’s good. You’ve got a software development process that complements DevOps, but agile doesn’t mean you’ve adopted DevOps.
DevOps is an agile enabler allowing operations to collaborate, supporting a more continuous flow of work into IT operations and out into production where customers can realise its value.
3. Rebrand Your Ops/Dev/Any Team as ‘the DevOps’
CIO: “I want to embrace DevOps over the coming year.”
MGR: “Already ready done, we changed the department signage this morning. We are so awesome we now have two DevOps teams.”
Yeah great. And I bet you now have lots of ‘DevOps’ engineers walking round too. If you’re lucky they may sit next to each other at lunch.
4. Start a Separate DevOps Group
Go on. I dare you. Done it? Well done. You’ve implemented DevOps. Actually what you just did is create yet another silo. Now you’ve got yourself another team to try and integrate. Another team with walls to breakdown. Maybe you could go back and rebrand and create three DevOps teams, then you’d be super awesome.
DevOps is not about cherry picking some developers and some IT operations people and siloing them off. You’ve got to embrace and embed.
Collapse the development team into the ops team or vice-versa. You need to fully break down the barriers / walls / guards between the teams and mould them into a single unit with shared goals and responsibilities.
Check out what Gene Kim had to say on this matter here.
5. The Hostile Takeover
DevOps. So that’s a word that starts with “Dev”. That means development lead, because development comes first…… Problem?
DevMgr – “Er, we’re now doing DevOps. My guys need to learn the production systems.”
OpsMgr – “Er….ok. So who’s going to be developing the code?”
The word DevOps is clever. It’s a portmanteau. This means the combination of two words, to form a new word, which gives a new meaning. It even delivers some efficiency. It doesn’t mean we took the word operations and replaced it with the word development. So why would you try and adopt DevOps in that manner?
DevOps requires both groups to recognise their key skills. Share what needs to be shared to collaborate. Learn what needs to be learnt to improve. It does not mean retraining. It does not mean cross-skilling (however, this may be a welcome side-effect). It does mean providing feedback and visibility to improve.
6. DevOps is a Buzzword
If you think DevOps is a buzzword, then you’ve probably been using “The Cloud” as a misnomer too. DevOps is more than just a cool buzzword. It’s a state of mind. You must embrace its values, you must help others embrace its values and you must continually improve yourself and help others to improve for it to be successful.
7. Sell DevOps as a Silver Bullet
DevOps is voodoo. You basically get your development team and your IT operations team together. They smoke some peyote and then sacrifice a chicken. Once you’ve done that your organisation will be revolutionised.
You’ll be able to ship software faster than ever before. Configuration will be self-managing. Your deployment tools will become self-aware. Your development and IT Operations teams will have a newfound harmony.
Get this…DevOps is hard work! For most organisations, it requires cultural change. That’s one of the hardest things you’ll ever attempt. Seasoned development and IT operations teams are about to have their world turned upside down. Don’t try and do it overnight or you will fail.
8. DevOps Means Developers Managing Production
No. Hell No and No again. You’ll just have to read this.
9. DevOps is Development-Driven Release Management
Let me get two things clear:
- DevOps is not development driven. DevOps is not IT operations driven.
- If you want a developer-driven environment, fine, go create one. Just don’t call it DevOps. It’s not.
Development-driven anything may be a process. It’s just not DevOps.
10. We Can’t do DevOps – We’re Unique
Yes you are, you little beauty you! But you’re not special enough that you can’t adopt DevOps. I bet you’re the best developer out there; you code quicker than lightning, and deliver the sort of code that makes people cry with joy. No? OK, so you’re the most awesome Ops Guy on planet.
However, you and your organisation don’t have some unique factor that won’t allow you to adopt DevOps. So, give it a go!
Technology entrepreneur Jesse Robbins has some good advice for getting started;
- Start Small – Build Trust
- Create Champions
- Build Confidence
- Celebrate Success
- Exploit Circumstance
11. We Can’t Do DevOps – We’ve got the Wrong People
Well why did you hire them? That’s right – they’re awesome! If you don’t think that, then you need to take a long hard look at yourself, then go and discover the real hidden talents in your team.
DevOps fosters a collaborative working relationship between Development and IT operations. This collaboration can extend right through the organisation further enhancing working relationships between teams.
You don’t have the wrong people. You have the wrong thought process. Deal with it.
12. Collaboration When Things go Pear-shaped
Ok genius. You messed up. So what? We all do it. But now you want your IT operations guys out of bed at 2am to clean-up something they know nothing about. They are IT operations engineers – not the ‘fixers’. Waiting until an error occurs during a deployment for development and IT operations to collaborate sucks.
It’s too late for this problem…but maybe not for the next. You have your development team and your IT operations team talking (or swearing at 2am) with each other, but at least they are talking. Keep the dialogue going. Get a retrospective review of what happened and how you can fix it going forward. If you have encountered this situation, then try and keep the dialogue going with between your teams. Open the communication channels with development and IT operations early. There’s hope for you yet!
