What Designers Need to Know about the Path to Production

The Path to Production is easy to ignore if you’re a designer.

You do some great research, synthesize it, execute on some awesome looking designs, get the features/functionality you believe is most critical for the users prioritized, and then you can see it all come together!

It’s awesome.

…but then you hear? “Yeah, looks great, but it’s not in prod yet.”

Maybe we’re doing user testing in dev or staging, but what does that mean?

Why is it taking so long to get this thing out there?!

Whether right or wrong to do (please see Kent Beck’s XP Explained for why this is “wrong”) I’ve celebrated when apps I’ve worked for clients at VMware Tanzu Labs have been shipped and are in production. I’ve also really enjoyed seeing analytics, and watching users use something that’s actually out there.

But how does it happen? How does an app go from being an idea all the way to being “in production”? What do we mean when we say production? What do developers actually do? Why does this matter to designers?

In this article I'm going to give you some food for thought and impart some of the wisdom I've learned while asking developers:

How does an idea go from something in your head to a thing people can actually use out in the wild?

I hope that this article sparks your thoughts about path to production, demystifies it, and helps you as a designer to ask better questions about the Path to Production. I also hope that it helps you understand your role in getting an application to production and why, more than anything else, it matters.

Quick Disclaimer - I'm not a developer, I'm a designer. So this is my understanding as a designer but I can certainly be off on some things. If you're a developer and you're reading this, I'd love to know what I got right and what I got wrong. If you're a Product Manager and you're reading this, I'd love to hear your thoughts as well.

Before I dive in…

Quick shout-out to devs who helped me understand more about development and path to prod:

Sean Olzewski, Amogha Gundavaram, Bill Schofield, Emily Davis, PB, Jack Huang, Christopher Pittman (not quite a dev but super influential to me), and so, SO many more.

MAPPING THE PATH TO PRODUCTION

I got this diagram from a course I did on DevOps via LinkedIn Learning. (Shoutout Ernest Mueller and Karthik Gaekwad!)

If you show this to the developer on your team you’ll usually get a lukewarm “This is kinda it, I guess…” reaction *OR* You’ll get “It’s this, but with some steps combined and others added and others we don’t do."

Despite the lukewarm reaction you're likely to get, I want to use this to explain the path to production because it’s the single visual that’s been most important for helping me answer the question about how an application goes from a developer typing something in to their computer to a thing my users can use.

Is this the best possible explanation? Probably not.

Has this been the best *for me*? Yes. Absolutely.

So I hope it’ll be helpful for you, too. Let’s go step by step and demystify some of what we’re seeing here.

SOURCE CODE AND VERSION CONTROL

This part was the most clear to me when I was trying to understand the path to production. I knew that developers were typing things into IntelliJ and I knew that they used something like GitHub so that multiple developers could work on the code at the same time.

A version control tool or system is one that helps document changes and one that helps to merge changes when developers work on different parts of the same overall codebase.

Source Code is the file that developers are working on. When they’re typing something into their computer, that’s the source code.

Version control is a way to allow multiple developers to work on the same source code at the same time. Version control also keeps a history of changes.

TESTING, ARTIFACTS, AND DEPLOYMENT

A build is just the combined code all together.

I’m not going to talk too much about testing, but I think it’s important to understand that the ideas behind Extreme Programming (XP) include paired programming, which are central to our way of working at VMware Tanzu Labs.

You may have already pair as a designer, and if you haven't it's one of the few truly life changing experiences I've had as a designer. Real time collaboration is such a critical part of the design process.

Design pairing techniques are based on developer pairing. The purpose of pairing as a developer is that you can do code review in real time and you can run tests so that the code will work all together. If you don’t run tests you run the risk of defects or bugs in your code. So even if you don’t do those tests as part of paired programming, it’s important to check the code frequently for defects.

I’m not sure I’m savvy enough to write eloquently on the different types of tests and how developers perform tests, but I encourage you to talk to the devs on your team and ask.You can even pair in with the devs on your team to watch how this testing takes place and it’s really neat!

So once we’ve tested the code and we’re confident that it runs correctly.

We want to take all the code files and put them into one file with lots of files inside, like a zip or war file. That zip is an “artifact”. Here’s a way I sometimes think about this part of the process.

I used to work in a sandwich factory and my job was putting lettuce on sandwiches (that’s a real thing. I did that! Shoutout Lord Sandwich!)

When the sandwich finished on the assembly line and all the meat and cheese and veggies and condiments were on the sandwich, then it was wrapped in shrink wrap by a machine. To me, that’s kinda what the artifact is. It’s the completed singular sandwich shrink wrapped.

Then a bunch of sandwiches would go into a box for delivery and that’s the artifact repo.

When the sandwiches are sent out, to continue the analogy, that’s kinda like sending it to an environment where it’s unpacked by the store and maybe production is like eating the sandwich? I don’t know, it’s a loose analogy. Hang with me.

DEV → STAGING → PRODUCTION

Let’s take a moment to talk about environments before moving on to the final portion of the flow chart. Development or a “Dev environment” means that the code for the application is just running on a local computer. It’s not in an external server. It’s not in the cloud.

Once that code is created locally, we want to get it to production, but we first need to do two things-

1. Get it to the cloud
2. Make sure it works the way we expect it to once it’s in the cloud.

Staging environments are a place where our code is in the cloud and not on a local machine. They’re also a place where we can be sure something works all together in concert before we put it into production. Sometimes you’ll hear that staging “mirrors” production. That’s because staging is where our code works just like production but it isn’t in the hands of our users.

A production environment is the place where users can use the thing we built in full. You’ll hear we “promote” to production or “push” to production. I like to think of it that staging *becomes* production and a new staging occurs.

Sometimes there are other environments too. You’ll see a “Testing Environment” in the graphic, and sometimes I’ve seen a “QA Environment.” There can be unlimited environments and sometimes there are reasons to have others, but the Dev to Staging to Production flow is the most common I’ve seen across a wide range of products I've worked on with clients at VMware and beyond.

CI/CD AND RELEASE

We’re getting to the end of our Path to Production Journey.

Here you can see a CI Environment and a Deployment Tool with some testing going on between the two. CI/CD stands for Continuous Integration / Continuous Deployment. I’ve also heard the “CD” part stand for “Continuous Delivery”, but I’m pretty sure this is the same thing. You’ve probably heard people say “DevOps”. I think CI/CD is where the rubber hits the road with Development and Operations.

Development is the code writing part.

Operations is the part where you’re actually managing the code in the cloud to make sure it’s running and scaling the way it’s supposed to be.

It’s a little mysterious to me, but I like to think of a CI/CD pipeline is kinda like the sandwich line I described earlier. It packages everything up for release and moves it into position. I’d encourage you to ask your teammates about CI/CD pipelines and tools (like GitLab, Concourse, and Jenkins).

Anyway, we’ve packaged everything up, zipped it up, tested it, checked it, made sure it’s secure (sometimes you’ll hear “DevSecOps” and not just “DevOps”), and make sure it’s ready for release.

Then…drumroll…we push to production! (Insert sprinkles and glitter and fireworks here!)

HEY THIS IS ALL COOL AND ALL, ANDREW, BUT I'M A DESIGNER SO WHY DO I CARE? SOUNDS LIKE A BUNCH OF DEV STUFF....

I think it's fair to ask why this all matters to you if you're a designer.

One way to think about why path to production matters is to consider the four DORA metrics you’re seeing here. Championed (and I think created) by the authors of the book Accelerate. Dr. Nicole Forsgren, Jez Humble, and Gene Kim.

1. Lead Time -- How fast from when you think about a thing to build can you actually release it?
2. Deployment Frequency -- How fast can you push to production?
3. Mean Time to Restore -- If the system goes down, how fast can you get it back up and running?
4. Change Failure Rate -- How much of the code you ship is defect-free?

Here’s why this stuff really really really really really matters.

The faster your team can ship, the more likely you are to be able to design something and get real feedback from real users.

It’s okay to make mistakes. Make them! Ship first and ask questions later.?

At VMware we are opinionated about the kind of agile and lean ideas we are because they WORK….but they only work when we’re shipping. Teams have to ship all the time and, believe me, nothing is more satisfying than seeing your work out there.

We also want to be able to revert back to previous versions if the thing we shipped didn’t work out. Netflix famously set up a thing called “Chaos Monkey” that would just destroy parts of their code randomly to help them build resilient systems.

The more resilient your system, the faster you can revert back when things go sideways, the more you’ll be able to offer users.

WRAPPING UP

Path to Prod isn’t just one thing or even just one process.

It’s a ton of things and each one is a rabbit hole.

Over the years I’ve learned a lot and I feel like it’s made me a better designer and a better consultant.

I hope that this article demystified some of the path to prod and I also hope it sparked your interest. Talk to your devs, find out more about the path to prod or any of the specific aspects of it that I discussed.

It’s important for designers and developers to form closer bonds.

As always if you loved this article, share it with your friends.

If you didn’t tell me, so I can do better next time.

Thanks!!