什么是一些好的策略来允许部署的应用程序是可修补的？ [英] What are some good strategies to allow deployed applications to be hotfixable?

问题描述

在一个理想的世界中，我们的开发过程将是完美的，导致定期发布被彻底测试，永远不需要修补正在运行的应用程序。

但是，不幸的是，我们生活在现实世界中，有时候错误会滑过我们，不要拖着丑陋的头，直到我们在下一个版本中已经在编写代码了。而且这个bug需要修正 现在 。不是下一个发行版的一部分。不是今晚当交通死亡时。 。

如何处理这个需求？它真的可以与良好的设计实践相违背，例如将代码重构成漂亮的离散类库。

生产服务器上的手动编辑标记和存储过程可以是但是它也可以避免灾难。

应用程序设计和部署技术在维护需求和良好的编码实践之间找到平衡有什么好的策略？ / p>

解决方案

[即使我们在发布之前测试了很多，]我们所做的是这样的：

我们的SVN看起来像这样：

  / repo / trunk / 
 / repo / tags /1.1 
 /repo/tags/1.2 
 /repo/tags/1.3 
  

现在每当我们发布，我们创建一个标签，我们最终在生产中检出。在我们进行生产之前，我们进行分段，这是[较少的服务器，但与生产相同）。

创建标签的原因包括某些设置我们的应用程序在生产代码中略有不同（例如，没有错误通过电子邮件发送，但是记录）从中继，所以创建标签并提交这些更改是有意义的。然后在生产集群中检出。

现在，只要我们需要修复一个问题，我们首先将其修复到标签/ x，然后再 svn update 来自标签，很好。有时我们会进行分期，有一些问题（例如拼写错误的小事情修正案），我们进行旁通分段。

唯一需要记住的是将所有补丁从 tags / x to trunk 。

如果你有多个服务器， Capistrano 非常有助于运行所有这些操作。

In an ideal world, our development processes would be perfect, resulting in regular releases that were so thoroughly tested that it would never be necessary to "hotfix" a running application.

But, unfortunately, we live in the real world, and sometimes bugs slip past us and don't rear their ugly heads until we're already busy coding away at the next release. And the bug needs to be fixed Now. Not as a part of the next scheduled release. Not tonight when the traffic dies down. Now.

How do you deal with this need? It really can run counter to good design practices, like refactoring your code into nice, discrete class libraries.

Hand-editing markup and stored procedures on a production server can be a recipe for disaster, but it can also avert disaster.

What are some good strategies for application design and deployment techniques to find a balance between maintenance needs and good coding practices?

解决方案

[Even though we test a lot before we release, ] What we do is this:

Our SVN looks like this:

/repo/trunk/
/repo/tags/1.1
/repo/tags/1.2
/repo/tags/1.3

Now whenever we release, we create a tag which we eventually check out in production. Before we do production, we do staging which is [less servers but] pretty much the same as production.

Reasons to create a "tag" include that some of the settings of our app in production code are slightly different (e.g. no errors are emailed, but logged) from "trunk" anyway, so it makes sense to create the tag and commit those changes. And then checkout on the production cluster.

Now whenever we need to hotfix an issue, we fix it in tags/x first and then we svn update from the tag and are good. Sometimes we go through staging, with some issues (e.g. minor/trivial fixes like spelling) we by-pass staging.

The only thing to remember is to apply all patches from tags/x to trunk.

If you have more than one server, Capistrano is extremely helpful to run all those operations.

这篇关于什么是一些好的策略来允许部署的应用程序是可修补的？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！