• Deploy! = Release (Part 1): The difference between deploy and release and why it matters.
  • By Art Gillespie
  • The Nuggets translation Project
  • Permanent link to this article: github.com/xitu/gold-m…
  • Translator: stormluke
  • Proofreader: MechanicianW, ALVINYEH

Q: “Is the latest version deployed?”

A: “I deployed GIF support in production.”

Q: “So GIF support has been released?”

A: “The release version of the Gif is already deployed.”

Ask: “…”

I have worked in many companies where “deploy”, “deployment”, “ship” and “release” are used liberally, even interchangeably. As an industry, we have not done enough to standardize the use of these terms, even though we have radically improved operations practices and tools over the past decade or so. At Turbine Labs, we use precise definitions of “go live,” “deploy,” “release,” and “rollback,” and spend a lot of time thinking about what the world looks like when you consider “go live” as a separate phase of the go live process. In the first part of this article, I will share the definitions of these terms, describe some common “deploy == publish” practices, and explain why it is not risk-resistant. In Part 2, I describe some very powerful risk mitigation techniques when “deployment” and “release” are considered different phases of the software launch cycle.

online

Going live is the process by which your team takes a snapshot of a version of the service code from the source management repository and uses it to handle online traffic. I think the whole process of going live consists of four different specialized little processes: build, test, deploy, and release. Performing the first three processes (build, test, and deploy) has never been easier, thanks to technological advances in cloud infrastructure, containers, and orcheation frameworks, as well as process improvements such as Twelve-Factor, continuous integration, and continuous delivery.

The deployment of

Deployment is the process by which your team installs a new version of service code into the infrastructure of the production environment. When we say that a new version of software is deployed, we mean that it is running somewhere in the infrastructure of the production environment. The base setup can be a newly started EC2 instance on AWS or a Docker container running in a container in a Kubernetes cluster in the data center. Your software has started successfully, passed your health check, and is ready (as you hoped!). To handle online traffic, but may not actually receive any traffic. This is an important point, so I’ll repeat it in Medium’s awesome big quote format:

Deployment does not require a new version of the service to be provided to users.

By this definition, deployment can be a virtually risk-free activity. Sure, a lot of things can go wrong during deployment, but if a container crashes silently and no user gets a 500 status response, is the problem really happening?

A new version (purple) was deployed but not released. Known good versions (green) still respond to online requests.

release

When we say a service release, we mean it is responsible for the online traffic of the service. In the verb form, publishing is the process of moving online traffic to a new version. Given this definition, all The risks associated with putting new binaries online — outages, angry users, mean content in The Register — are related to The release of new software rather than its deployment. In some companies, I’ve heard this launch phase is called a rollout. In this article we will continue to use publication.

New version released in response to online requests.

The rollback

Sooner or later, probably not too long ago, your team will bring online some service with questionable functionality. Rollback (and its dangerous, unpredictable, and stressful cousin, roll-forward) refers to the process of returning an online service to a known state, usually by republishing the most recent version. It’s helpful to think of rollback as just another deployment and release process, the only difference being:

  • The characteristics of the version you are shipping are known in production
  • You are performing the deployment and release process under time pressure
  • You may be releasing to a different environment – something may have changed (or been changed) since the last failed release

An example of rolling back after publication.

Now that we’ve agreed on the definitions for going live, deploying, publishing, and rolling back, let’s look at some common deployment and publishing practices.

Publish in place (deploy == publish)

When your team’s rollout process involves pushing a new version of the software to a server running the old version and restarting the service, you’re launching in place. As defined above, deployment and release happen simultaneously: once the new software is up and running (deployment), it loads all the online traffic (release) of the old version. At this point, a successful deployment is a successful release, and a failed deployment leads to partial or total service outages, a bunch of angry users, and perhaps an angry manager.

Publishing in place is the only way to expose deployment risks to users in the deployment/release process we discussed. If the new version you just deployed doesn’t start — maybe an exception was thrown because you couldn’t find a new environment variable, maybe a library dependency wasn’t met, or maybe you just didn’t look at the almanac when you left today — there are no service instances of the old version to load user requests. Your service is at least partially unavailable at this time.

In addition, if there are user-related issues or more subtle operational issues — what I call publishing risk — in-place publishing exposes online requests to all instances that you have published.

In a clustered environment, you might first publish an instance in place. This practice, often called Canary publishing, mitigated some of the risk — the percentage of traffic exposed to deployment risk and publication risk was: the number of new service instances divided by the total number of instances in the cluster.

A Canary release: a host in the cluster runs the new version

Finally, rolling back the wrong in-place deployment can be problematic. Even if you roll back (republish) to an older version, there is no guarantee that you will revert to the previous system state. Like the current faulty deployment, your rollback deployment may fail at startup.

Despite its relatively poor risk management — even with Canary, some user requests are at risk of deployment — in-place deployment remains a common approach in business. I think this kind of experience leads to an unfortunate mix of the terms “deploy” and “release.”

Don’t despair

We can do better! In the second part of this article, we’ll discuss strategies for separating deployment and release, as well as some powerful workflows that can be built on complex release systems.

I am aTurbine LabsOne of the engineers that we’re buildingHoustonThis service makes it easy to build and monitor complex real-time publishing workflows. If you want more service online with ease, you absolutely shouldContact us. We’d be happy to talk to you.

Thanks to Glen Sanford, Mark McBride, Emily Pinkerton, Brook Shelley, Sara and Jenn Gillespie for reading a draft of this article.

Glen D Sanford.

The Nuggets Translation Project is a community that translates quality Internet technical articles from English sharing articles on nuggets. The content covers Android, iOS, front-end, back-end, blockchain, products, design, artificial intelligence and other fields. If you want to see more high-quality translation, please continue to pay attention to the Translation plan of Digging Gold, the official Weibo, Zhihu column.