问题描述
在理想的世界中，我们的开发流程将是完美的，从而产生经过彻底测试的定期发布，永远不需要修补"正在运行的应用程序.
但是，不幸的是，我们生活在现实世界中，有时错误会从我们身边溜走，直到我们已经忙着在下一个版本中编写代码时才会抬起它们丑陋的脑袋.并且该错误需要现在修复.不作为下一个预定版本的一部分.不是今晚当交通停止时.现在.
你如何处理这种需求?它确实可能与良好的设计实践背道而驰，例如将您的代码重构为漂亮的离散类库.
在生产服务器上手动编辑标记和存储过程可能会导致灾难，但也可以避免灾难.
应用程序设计和部署技术有哪些好的策略可以在维护需求和良好的编码实践之间找到平衡?
[尽管我们在发布之前进行了大量测试，] 我们所做的就是:
我们的 SVN 看起来像这样:
/repo/trunk//回购/标签/1.1/回购/标签/1.2/回购/标签/1.3现在每当我们发布时，我们都会创建一个标签，我们最终会在生产中检出该标签.在我们进行生产之前，我们会进行暂存，这 [更少的服务器但] 与生产几乎相同.
创建标签"的原因包括我们的应用程序在生产代码中的某些设置与主干"略有不同(例如，没有通过电子邮件发送错误，但已记录)，因此创建标签和提交这些更改.然后在生产集群上结帐.
现在每当我们需要热修复一个问题时，我们首先在 tags/x 中修复它，然后我们从标签中 svn update 并且很好.有时我们会经历分期，但有一些问题(例如拼写之类的次要/琐碎修复)我们会绕过分期.
唯一要记住的是将所有补丁从 tags/x 应用到 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.
这篇关于允许已部署的应用程序进行热修复的一些好的策略是什么?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！