Eri*_*ard 9 language-agnostic deployment maintenance
在理想的世界中,我们的开发过程将是完美的,从而产生经过如此彻底测试的常规版本,从而无需"修补"正在运行的应用程序.
但是,不幸的是,我们生活在现实世界中,有时虫子会从我们身边溜走,并且在我们已经忙于编写下一个版本之前,不要将它们放在丑陋的头上.而bug 现在需要修复.不作为下一个计划发布的一部分.当交通消失时,今晚不是. 现在.
你是如何处理这种需求的？它确实可以与良好的设计实践背道而驰,比如将代码重构为漂亮的离散类库.
在生产服务器上手动编辑标记和存储过程可能会导致灾难,但它也可以避免灾难.
应用程序设计和部署技术有哪些好的策略可以在维护需求和良好的编码实践之间找到平衡点？
[尽管我们在发布之前进行了很多测试，]我们所做的是：
我们的 SVN 看起来像这样：
/repo/trunk/
/repo/tags/1.1
/repo/tags/1.2
/repo/tags/1.3
现在，每当我们发布时，我们都会创建一个标签，最终在生产中检查该标签。在进行生产之前，我们会进行暂存，这[服务器较少，但]与生产几乎相同。
创建“标签”的原因包括我们的应用程序在生产代码中的某些设置与“主干”略有不同（例如，没有通过电子邮件发送错误，而是记录错误），因此创建标签并提交这些更改是有意义的。然后检查生产集群。
现在，每当我们需要修复问题时，我们都会tags/x先修复它，然后再svn update从标签中修复，就可以了。有时我们会经历登台，但由于一些问题（例如拼写等小/琐碎的修复），我们会绕过登台。
唯一要记住的是应用从tags/x到 的所有补丁trunk。
如果您有不止一台服务器，Capistrano（指向 capify.org 的链接不再达到预期目的）对于运行所有这些操作非常有帮助。