So you wanna do DevOps? Okay, 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 “brain storm” and in came the “idea shower” and with it came the “anti-pattern”.
If the “pattern” is the right way, then inherently the “anti-pattern” is the wrong – 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.
DevOps according to Gene Kim, is underpinned by 3 core principles known as the “Three Ways”.
The First Way emphasizes 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.
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 compliments 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 realize 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 you’ve got to try and integrate. Another team with walls to breakdown. Maybe you could go back and rebrand (see AP: x) and create 3 DevOps teams then you’d be super awesome.
DevOps is not about cherry picking some developers and some IT Operations people and silo’ing 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.
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 a word, you got that right. Actually, it’s a portmanteau of Development and IT Operations (I’ll collect my gold star from teacher later).
DevOps is more than just a cool buzz word. 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. Once you throw away the BS and start collaborating you might get people to think your catchy new word “DevOps” might actually be cool.
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 new found harmony.
Get this….. DevOps is hard work! For most, it requires Culture Change! That’s one of the hardest things you’ll ever attempt. For seasoned development and IT Operations teams you’re about to try and turn their world up-side-down. Don’t try and do it overnight or you will fail.
8. DevOps means Developers Managing Production
No. Hell No and No again. I’m so incensed you’ll just have to read this….
9. DevOps is Development-driven release management
Let me get 2 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.
Take a look at this article for example.
“Within DevOps, programmers are programmers.” – Right on!
“Equally, within DevOps, operations staff are operations staff.” – We’re cooking now!
“Traditionally, getting software out to production can be either the responsibility of operations or of the development team.”
“IT operations teams will have established and trusted deployment strategies in place that minimise downtime and ensure stability at the expense of agility and speed of response.”
Yep, we’re back on track…… and then bam!
“Development-driven release management” – What? It gets worse
“Development-driven release management goes the other way and looks at how deployment can be carried out as often and easily as possible.
However, these deployments aren’t necessarily into production……………
From a process standpoint, continuous delivery has two big requirements: first, the process itself has to be solid beyond development. This means that it has to be as solid as any process that a traditional IT operations team might put into place.”
No. Non. Nej. Na. Nee. Nein.
Development-driven anything may be a process. It’s just not DevOps.
Replacing your IT Operations team with an automated deployment process is nonsense. Please don’t try this at home folks!
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 lighting, and deliver the sort of code that makes grown men cry with joy. No? Okay, so you’re the most awesome Ops Guy on planet. If Chuck Norris were an IT Operations Engineer he’d be want to be you.
However, you and your organisation don’t have some unique factor that won’t allow you to adopt DevOps. So give it a go!
- 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.
Someone told me recently that they couldn’t do DevOps because “they have the wrong developers or the wrong ops people…”. So they have developers who can’t code? I thought to myself, “my organisation has the wrong developers, people who can’t code, they run HR and Marketing!”
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 “fixer” like Michael Clayton. 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!