BACKGROUND IMAGE: iSTOCK/GETTY IMAGES
I do testing and support for a delivery team, and my manager wants me to get started with DevOps. What do I do first?
First of all, I realize your position may be a little scary, but it is more fortunate than most. Your manager came to you, asking for your ideas. That means you have agency. Instead of having something inflicted upon you, you get to decide what it will be. That is a fantastic opportunity. Not only that, it sounds like the DevOps process will come from within the team, which is self-supporting.
Too many companies try to hire a DevOps team and end up using that team as another step in the delivery process. In our Lean Software Delivery Class, we model a system that is perfectly balanced over time, but has different variation -- someone's work station is a little slower, sometimes faster. As a result, bottlenecks emerge naturally. The more stations you add, the slower you go. The lesson here: New steps have a cost; be very careful when adding them.
So, it sounds like you're in the right place to get started. Let's do it.
Enough DevOps to move toward it
DevOps is typically pictured as the intersection of programming (dev), operations (ops) and test. Since programmers automate things, the intersection involves automating the creation of servers, keeping the operating and system software updated, deployments and risk management functions, including visual monitoring.
Where to start in creating a DevOps process? Well, first, I'd find the bottleneck -- the piece of work that is repetitive and needs to be done over and over again.
Or, you could look for the work -- the thing you don't do all the time, but would like to.
Or, you could reduce risk -- check if a server is still up or visualize the number of seconds it takes for the server to deliver pages, perhaps the number of 4XX errors per minute.
Or, you could automate workflow to ensure pieces of the work are followed. I am least excited about this, because you could trust people, use a wiki or use plenty of other tools. Still, there could be cases where you want to write a little glue code to push changes from this system to that system automatically, or to notify the team when this or that event occurs.
So, read that list four or five times and take a walk. As you walk, think about your own software process and what you could do to improve. Do not worry that you do not have the skills to set up a virtual server, or that you don't know anything about visual monitoring. We'll worry about that later. For now, just brainstorm with yourself. Get back to your desk and start writing the ideas at the bullet-point level.
For a little insight into what might be worth automating, consider this XKCD comic.
Once you have the list, stop and share this article with the DevOps process team. Ask everyone else to do what you just did.
Most of the successful teams I work with have had an official event -- perhaps a ceremony -- where they took some time to pause, reflect and sum up what is happening. One term for that is a retrospective, and the real magic in a retrospective is the part where people propose experiments to try. Those are changes to the way you make software that are time-constrained. The whole team agrees to try the new idea until the next retrospective, and then assesses how it went. That means people who hate it -- and are sure it won't work -- only have to put up with it for two weeks in order to convince everyone what a bad idea it is. Sometimes, they are right, and sometimes they are surprised -- and both cases are OK.
At this retro, the DevOps process team is going to list improvement ideas to invest time in. There are plenty of ways to do this. One easy way is to have each person propose at least one idea on a sticky note and stick it to the wall. After the marketplace, the team dot votes to determine the most popular ideas, which then become stories. The stories might be too big and you might want to break them down. My advice is to start with quick wins to build momentum.
Now comes the hard part: The team has to convince whoever sets the priorities to fund some number of stories each week. Given that your boss wants to do DevOps, that implies some willingness to make some investment in the concept.
One more idea: Check out The Heusser Test, which provides a checklist a team might tick off as they move toward DevOps. I'm very reluctant to tell you exactly what to do, as that is a bit like a doctor giving a prescription without first examining the patient, but you could look to the my test for an idea of where your gaps might be and inspirations on how to close them.
DevOps from the ops perspective
Just getting stated with DevOps? No worries -- you're not that far behind everyone else
Here's what not to do in a new DevOps effort
Have a question for an expert?
Please add a title for your question
Get answers from a TechTarget expert on whatever's puzzling you.