I had a friend come to me the other day with what seems to be a simple ask. His company, a large banking enterprise, is looking into DevOps. So where should he start in building awareness?

Some context here – my friend is a programmer, a lifelong developer with high-level black belt skills in a variety of languages. He doesn’t want this to become a full time job for him – he loves coding and application development/architecture in particular. He just wants some resources to pass along.

Here’s my response:

A few words first on what DevOps is…

If you’re just getting started, there’s a decent Microsoft site out here at this address. Including a great series of videos that introduce what DevOps is and means, with some really rich content in the footnotes for next steps..

DevOps means in practical terms making sure your release pipeline from a development workstation to production is as smooth and automated as possible. So that implies:

1. Infrastructure as Code: You have your infrastructure written out as a recipe and it’s rebuilt each time you push out code (Infrastructure as Code). Following a template enforces consistency, it’s the only sane way to handle things. The big players in this space to date are Chef and Puppet, maybe Octopus.
2. Testing: Your testing is as rigorous as possible. This means when you do a release no person needs to look at anything but exceptions where there’s failures – your releases are gated where if there’s major bugs you’ll catch them early on and prevent a release to production. This means integration and unit testing using things like Selenium for the UI layer.
3. Release Management: When developers check in code its continuously integrated and released. Note – this is mostly IDE based. I believe MSFT has best in class tooling here especially built on top of VSTS releases, where essentially it becomes fire and forget, a checkbox. (Remember when Agile used to be hard?)

For my open source friends – the big players in the industry right now come from the Linux community. So start in your learning efforts with Chef (https://learn.chef.io/) and Puppet (https://puppet.com/download-learning-vm) . Ansible is also a hot name. You can download VM’s and start playing with them, or run these tools on the cloud, free with Azure, and they’re Linux based, very easy on the $.

OK, That’s Great. Now What?

Well, if you want to tackle this, and you’re book oriented, I would recommend the following:

The “Gang of Four” Books:

1. Get “The Phoenix Project” by Gene Kim. This is great in particular for you executive/leadership types. Think about leaving this on the desk of decisonmakers you know if you need support for your DevOps initiative.
2. Another, very practical book is “Leading the Transformation” by Gary Gruver and Tommy Mouser. This is a much more connected approach on how one leader found a way around serious organizational constraints – yes your efforts will make enemies if handled badly! – by chaining it to specific business (not technical) phased objectives. A must read.
3. You developers out there should already have “Continuous Development” by Jez Humble on your bookshelves. It’s a modern classic and explains why developers should be 100% onboard with RM and continuous delivery movements.
4. IT people need to pick up a copy of “Visible Ops” by Gene Kim, very prescriptive and outstanding in basing your transformation on key IT/operations based KPI’s. Nonfuzzy, clear, short and sweet at about 100 pages in a little booklet. I love it.

Yeah, I’m more into videos. Books are so 90’s, dude.

OK, well do you have 12 minutes? Check out this intro with Donovan Brown,  and an excellent three part series on Release Management – Part 1 (overview), Part 2 (RM architecture), and Part 3 (release pipelines). Outstanding, and will give you a nice overview of setting up Continuous Integration and build pipelines.

My blog has some links on “All Happy Families Are Alike“, “Devopoly“, “Cats and Dogs Living Together“, and “The Five Dysfunctions of DevOps“. These are lengthy but put together will give anyone a good overview of the Phoenix Project and Visible Ops.

Now We’re Getting Started…

Well that’s enough to at least whet the appetite.

Here’s the three things I’d like you to come away with:

1. DevOps is a big effort, you will need help. You can’t do it grass roots. It will require strong commitment by management and the understanding that this will require both time and money. If you feel that you lack that level of commitment, manage expectations or scrub the effort until the conditions are more favorable. Likely, you will need some experienced help to form a roadmap and get buy-in, and coach/mentor so the first few months go smoothly. You will also need to commit time and effort to mastering and maintaining your code for both testing and building out your infrastructure. (Hopefully, your releases themselves will be mostly code-free).
2. Build maturity through better testing. Your gated releases are going to need a high level of assurance that your builds are functional. So building up your QA maturity is one big investment that will pay huge dividends in avoiding production mishaps and environmental anomalies that come through manual deployment methods.
3. Infrastructure As Code is where its at. As long as environments are manually provisioned, you have a vector for errors and time-sucking anomalies. Once you start writing out environments as recipes and going away from manual patching to destroying/rebuilding environments along with your production releases – you’ll never, ever go back. It rocks!

Thanks guys, hope this is helpful to you with those first few steps on your journey!