The team's release process

  • 2 minutes

The first step to setting up a DevOps practice is to assess your current process. This means analyzing:

  • Your existing artifacts, like deployment packages and NuGet, as well as your container repositories.
  • Your existing test-management tools.
  • Your existing work-management tools.
  • Recommending migration and integration strategies.

Let's do that with the Tailspin team and see how DevOps can help.

After Irwin the product manager leaves, Amita says, "We need help. I don't know when these fixes are due, but I do know it's soon. We're not set up for a fast turnaround. Plus, the new Space Game website will have to wait until we get this mess solved, and that game is coming up fast."

Andy looks at Mara. "This is a lot to take in during your first few weeks."

"That's okay," Mara answers. "Maybe you can explain to me how things work around here. How does a game move from dev to production?"

"That's a great question," says Andy. "I'm not sure we can give you a simple answer, but let's try."

The team decides to go to a coffee shop to relax and have an informal discussion. Together, they'll try to figure out why they're having so many problems.

Over coffee, Mara listens and tries to take notes. There's a lot of information and it's not organized. Her overall thoughts about the team are:

  • They use a waterfall approach. Management sets the priorities. Developers write code and hand the build off to QA. QA tests and then hands off to ops for deployment.
  • The waterfall approach could be acceptable for a small team, but here the goals aren't always clear and they seem to change frequently.
  • Testing is delayed until late in the process. That means it's harder and more expensive to fix bugs and make changes.
  • There's no clear definition of what done means. Each team member has their own idea. There's no overall business goal that everyone agrees on.
  • Some code is in a centralized version-control system. Many tools and scripts exist only on network file shares.
  • There are many manual processes.
  • Communication is haphazard and depends on email, Word docs, and spreadsheets.
  • Feedback is also infrequent and inconsistent.
  • On the plus side, the team seems to get along, and they want to make things better.

When she looks at her pile of notes, Mara knows she needs to organize all this information. Organizing it will make it easier to evaluate the processes. She's convinced a DevOps approach will solve many of the team's problems, but she needs a way to present her case to the team.

A DevOps practice often begins with understanding your existing processes. From there, you can evaluate what's working well, what's not, and focus on what to fix first.

Screenshot of a person taking notes on their tablet device.

Mara asks, "Have any of you ever done a value stream mapping exercise?"

Andy rolls his eyes, Amita sighs, and Tim says, "We don't need more paperwork."

Mara says, "I get it. Leave it to me."

Glad to let the newbie handle it, everyone heads back to work.