软件的涅磐_产品涅磐的持续部署

软件的涅磐

It seems like continuous deployment is what all DevOps teams shoot for. Every merge to master should go right into the customer’s hands. The code should be heavily tested with smoke, unit, and integration tests, put through staging environments, and then put out into the wild with a magic pipeline.

似乎持续部署是所有DevOps团队追求的目标。 掌握者的每一次合并都应直接交到客户手中。 应该使用冒烟，单元和集成测试对代码进行严格的测试，将其置于暂存环境中，然后使用魔术管道将其付诸实践。

And at GameChanger, this is what we have for our back end. On every push to Git, we have a suite of tests that run against the code to test its viability for deployment. We compile and run the application on CI servers. Then, if the code is approved by peers and passes all the tests, you get to click the big green button:

而在GameChanger，这就是我们后端的功能。 在每次使用Git时，我们都有一套针对代码运行的测试，以测试其部署的可行性。 我们在CI服务器上编译并运行该应用程序。 然后，如果该代码得到同行的认可并通过了所有测试，则可以单击绿色的大按钮：

Very satisfying. But is this actually what you want?

非常令人满意。 但这实际上是您想要的吗？

And then after another automatic process of deployment, customers actually start using your code. It's pretty wild when you think about it.

然后，在另一个自动部署过程之后，客户实际上开始使用您的代码。 当您考虑它时，它是相当疯狂的。

If you were talking to a developer from even ten years ago, continuous deployment was only for massive companies that had huge, dedicated DevOps teams. Now, with just a few dedicated people and tools like GitLab, Docker, and Jenkins, you can have your entire deployment pipeline be automated. The tooling has come a long way. Take a look at this article on setting up CD for your Android app.

如果您是十年前与开发人员交流的，那么连续部署仅适用于拥有庞大，敬业的DevOps团队的大型公司。 现在，仅需几个专门的人员和工具(如GitLab，Docker和Jenkins)，就可以使整个部署流程自动化。 工具已经走了很长一段路。 查看有关为您的Android应用设置CD的本文 。

And the tooling itself is very cool — that is undeniable. But as with many things in development, just because you can do something doesn't mean you should.

而且工具本身非常酷-不可否认。 但是，随着许多事物的发展， 仅仅因为你可以做某事并不意味着你应该做 。

So, is continuous deployment right for you? This is the good, the bad, and the broken.

那么，连续部署是否适合您？ 这是好事，坏事和坏事。

善良 (The Good)

停止决定何时发布 (Stop deciding when to release)

Have you ever been in a meeting about when to release code? They are awful.

您是否曾经参加过有关何时发布代码的会议？ 他们真可怕。

• “Should we wait for the next feature to go in this build?”
  “我们应该等待下一个功能加入该版本吗？”
• “This is a big release… do we need more testing?”
  “这是一个很大的版本……我们需要更多测试吗？”
• “Didn’t Joe not wear green on St. Patrick’s Day? I’m nervous about the code he writes.”
  “乔在圣帕特里克节那天不是不穿绿色衣服吗？ 我为他编写的代码感到紧张。”

These are very annoying sentiments, especially if you bring these questions to the people who are building and QA-ing the product.

这些是非常令人讨厌的情绪，尤其是如果您将这些问题带给正在构建和质量检查产品的人员。

“Yes, it is ready,” we say. In fact, let's prove it. Let’s stop having these dumb meetings and when we, the product team, say it is ready, it’s ready and it's going to the customers.

“是的，准备好了。” 我们说。 实际上，让我们证明一下。 让我们停止这些愚蠢的会议，当我们产品团队说准备就绪，准备就绪并将其发送给客户时。

Product managers and business stakeholders might shake in their boots a little, but if you actually trust your engineering team (and you should, or you should find a new one), you never have to think about when to deploy ever again.

产品经理和业务利益相关者可能会稍为摇晃，但如果您真正信任工程团队(并且应该或者应该找到一个新的团队)，则无需考虑何时再次部署。

开始快速发布 (Start releasing quickly)

And now you can deploy fast. Imagine if — and stay with me here — there was a global pandemic that affected every aspect of our lives. It changes the course of many companies and changes what your company needs to do.

现在，您可以快速部署。 想象一下，如果有一个全球性的流行病影响了我们生活的方方面面，并与我一起在这里生活。 它改变了许多公司的进程，并改变了您的公司需要做的事情。

To stay alive and keep your business relevant, you have to release the Social Distance Dating API. A mouthful, but a useful product and possibly a very profitable product.

为了保持活力并保持业务相关性，您必须发布社交距离约会API。 一口，但有用的产品，可能是非常有利可图的产品。

With continuous deployment, you don’t have to find someone to sit down and go through an arduous deployment process. You just click the green button and start finding those matches six feet apart (that sounded creepier than it needed to be).

通过连续部署，您不必找人坐下来进行繁琐的部署过程。 您只需单击绿色按钮，并开始查找相距六英尺的那些匹配项(听起来比需要的更令人毛骨悚然)。

坏人 (The Bad)

您的测试和同行评审都一样出色 (You are only as good as your testing and your peer review)

Now, just because you have all these tests, checks, and code reviews, your code still might not work as intended.

现在，仅由于您具有所有这些测试，检查和代码审查，您的代码仍可能无法按预期工作。

For example, the first thing I ever wrote on a continuously deployed back end was a new endpoint. I had gotten authentication and authorization mixed up and deployed an endpoint without authentication configuration. The endpoint did not need authorization (What user role do you need to hit this endpoint?), but it did need authentication (Is this endpoint call from a legal source?).

例如，我在连续部署的后端上写的第一件事是一个新端点。 我混淆了authentication和authorization ，并在没有身份验证配置的情况下部署了端点。 端点不需要authorization (您需要使用哪个用户角色才能访问此端点？)，但确实需要authentication (此端点是否从合法来源调用？)。

It passed the tests, it passed code review, and it was deployed. It wasn’t until a few days later that I realized my error and went back and added the authentication to the endpoint. But for a few days, anyone — literally anyone with a browser or curl— could have just hit that endpoint and gotten legitimate data from our back end. Pretty scary. Maybe we should build a check for this into our CI…

它通过了测试，通过了代码审查，并被部署。 直到几天后，我才意识到自己的错误，然后回过头来将身份验证添加到端点。 但是几天之后，任何人(实际上是任何拥有浏览器或curl )都可以访问该端点并从我们的后端获取合法数据。 挺吓人的。 也许我们应该为此在我们的CI中建立一个检查...

And of course, if you write new code but don’t write new tests with it, how can your CI test it? The code could not function as intended for your customers but still pass your test suite.

当然，如果您编写新代码但不使用它编写新测试，则CI如何进行测试？ 该代码无法按预期的功能运行，但仍可以通过您的测试套件。

Long story short, three checkmarks don’t mean your code will work or is even logically correct. You still have to be careful.

长话短说，三个复选标记并不意味着您的代码将起作用，甚至在逻辑上是正确的。 您仍然必须小心。

如果您的代码对人类生活负责怎么办？ (What if your code is responsible for human life?)

Should a Falcon 9's code change mid-launch because an intern hit a green button at SpaceX?

Falcon 9的代码是否应该由于实习生在SpaceX上按下绿色按钮而在发射中更改？

The Verge. The Verge从SpaceX拍摄的照片。

破碎的 (The Broken)

But where continuous deployment really shines is when shit does hit the fan. If you have ever done Site Reliability or been on-call, one of the worst things that can happen is fixing a problem but not being able to get the fix to users. You find a root cause or a workaround to get customers back in a working state, but the fix has to stay on your local machine because you don’t know how to get the fix to your clients quickly.

但是，持续部署真正发亮的地方是什么时候引起了粉丝的注意。 如果您曾经做过站点可靠性检查或处于待命状态，则可能发生的最糟糕的事情之一就是解决问题，但无法将修复信息提供给用户。 您找到了使客户恢复工作状态的根本原因或解决方法，但是该修补程序必须保留在本地计算机上，因为您不知道如何快速将修补程序提供给客户。

With continuous deployment, just hit the green button! At our company, you can even circumvent a lot of our testing and checks if you really need to have a fix in the hands of your customers right now. This is the definition of a hotfix, and it has saved many an incident at my company.

通过持续部署，只需点击绿色按钮即可！ 在我们公司，您甚至可以规避许多测试，并检查您是否真的需要立即解决客户问题。 这是修复程序的定义，它已节省了我公司的许多事件。

But GameChanger also has a client app, namely our iOS and Android apps. We don’t continuously deploy these because they have to go through their respective app stores. They require human review and have long turnaround times.

但是GameChanger也有一个客户端应用程序，即我们的iOS和Android应用程序。 我们不会持续部署这些应用程序，因为它们必须经过各自的应用程序商店。 他们需要人工检查，并且周转时间长。

This means we are in a bit of pickle when a user finds an edge case or bug. We can usually fix these things quickly, but we can’t actually get the fix to these users until a week or so later. It is very disheartening to tell a customer that they will need to wait to do what they want to do.

这意味着当用户发现一个极端的情况或错误时，我们会有点不高兴。 我们通常可以很快地解决这些问题，但是直到一周左右之后，我们才可以真正将这些问题解决。 告诉客户他们将需要等待去做自己想做的事情，这真令人沮丧。

但是我想立即部署我的代码！ (But I Want My Code Deployed Now!)

OK, so should you continuously deploy your back end?

好的，您是否应该持续部署后端？

I don’t know… probably? People seem to like it. I still lay awake at night worrying if someone accidentally deployed something that isn’t working and our monitoring or checks didn’t catch it. But then, that would probably happen with batched deployment anyway…

我不知道……可能吗？ 人们似乎喜欢它。 我仍然彻夜难眠，担心是否有人意外部署了无法正常工作的东西，而我们的监控或检查没有发现问题。 但是，无论如何，这可能会发生在批量部署中……

I also worry that with the low turnaround time of code being deployed and code deploying so often, does this mean the team thinks less deeply about what we are doing now because we can “just deploy a hotfix later”?

我还担心由于代码部署和代码部署的周转时间很短，这是否意味着团队会因为“可以稍后再部署修补程序”而对我们现在正在做的事情没有那么深入的考虑？

But like with all things in engineering, weigh the pros and cons for your project. Weigh the costs of building your CD pipeline and maintaining it and weigh the pros and cons of whether CD is right for your application.

但是，就像处理工程中的所有事物一样，请权衡项目的利弊。 权衡构建CD管道和维护它的成本，并权衡CD是否适合您的应用程序的利弊。

Just don’t deploy willy-nilly. Thanks for reading!

只是不要随意部署。 谢谢阅读！

翻译自: https://medium.com/better-programming/product-nirvana-continous-deployment-3a5763768cf8

软件的涅磐