7/10 – Understanding Dev Ops

If you had spent your whole life building software you’d have a pretty good sense of what you did when a project went well and some painful memories from when it didn’t. Like humans love to do, we created a word for this knowledge: Dev Ops (Dev = development, Ops = operations or getting stuff done).

This makes you feel awesome and smart to use insider language, but in reality if you had spent your whole life moving rocks you’d know good and bad ways to do that too and you’d call it Rock Ops.

You may be intuitively familiar with Dev Ops yourself if you’ve ever tried to write a group paper. Oh, I should have given a trigger warning before I said that right? Well shoot we’ve gone there, might as well finish.

Imagine some twinkly music and your favorite transition scene from a sitcom…

You and 3 others are sitting around a table, freshly minted as a group and with an assignment from teach to write a paper on whatever you want, 10 pages, single spaced. You are in existential angst since you intuit that you are the one who cares about the grade and half your group rarely shows up to class. Incidentally that half is pumped since they are intuiting your angst and know exactly what the bare minimum input is to make sure you don’t complain to the teacher about the extra work you’ll no doubt be putting in. Shake it off, you’ll get through it.

You set up a 7-step plan:

1. We start with an outline
2. Everyone needs resources: a computer, the same writing program and needs to cite only published references from the Real World Official Journal of Science, capiche?
3. Everyone takes a section to work on by themselves, but your work needs to be open anytime for others to see it
4. We have a final working copy that you upload your work to each night (this’ll help you know how much you’ll need to write on your own, ahh the price of A’s)
5. Everyone use spell check & correct your own mistakes BEFORE you put it into the final working copy
6. Auto send the draft to the teacher a couple times per week so she can check work and give feedback along the way
7. Final delivery will be 3 weeks from now, then we’ll start on the next paper…

In the end you deliver a solid paper, the plans worked out great and you only did 40% of the work this time, victory!

Now let’s translate to Dev Ops…this is the part where Myagi throws punches at Daniel-son and he realizes all that wax on/wax off was ninja training…

1. Outline = goal of your software
2. Resources: cpu, prog, journals = you need to give everyone a place to work or dev environment loaded with tools and real data such that what you test on here is as close to the real world as possible
3. Open work space = make everyone’s work visible
4. Regular upload = continuous integration
5. Spell check, correct your own mistakes = key to fast deployment is making sure there are robust error checks & unit testing all along the way, automated as much as possible so errors don’t get shared with others and slow them down too
6. Auto send to teacher = continuous deployment to end users to incorporate feedback
7. Final delivery in 3 weeks = work in sprints

Recap:

Bad Dev Ops

When dev ops doesn’t go right it feels more like this¹Hopefully this doesn’t sound familiar but the odds are not great:

Business plan:

“Hey we are not really sure what pain we are solving for customers but we have been doing this for awhile and dang we just need to finish it!”

Dev Environment:

“Oh, yeah this is not even real data.” “Well, we don’t really know until we push to production whether it will work because our dev environment is SO different.” “…we don’t have a ‘dev’ environment exactly…”

Open work:

“Nuh-nuh-nuh-NO, I’ll show you my code when I’m good and ready.” “I really don’t like other people looking at my code until it is done, thank you.”

Continuous integration:

“We find out if our code works by our customers complaint list.” “We don’t integrate until Production.”

Unit test:

“Well, yah, it would be cool if we could test stuff but that is unrealistic.”

Continuous Deployment:

“Oh we are still waiting for department 3 who is still waiting for department 2, who is waiting for 1…it’s going to be awhile.” “Maybe we should move to annual releases?” “Facebook deploys new versions to prod 15 times per day – that is impossible.”

Sprints:

“No, our manager gives us our deadlines we don’t have a voice in how long it takes, we are expected to estimate exactly how long each step will take…nevermind that we don’t know what problems we will surface but that is how we do it here.”

Luckily, Dev Ops doesn’t have to be super complicated, but learning about it comes first. When you are ready to start dev-ing you’ll need to make some decisions about where you do that, look up in the sky it’s a bird, it’s a plane, no it is modern tech architecture! The Cloud is next…