一周的发布周期：如何使之可行？

在我的公司（拥有3年历史的网络行业初创公司）中，我们的产品团队经常遇到这样的问题：“哦，现在这是一个危机补丁！” （不是每个人吗？）

这会影响包括自我在内的工程人员的生产率（和士气）。管理层花了一些时间思考如何减少这些当日请求的频率，并提出了我们每周都会发布的解决方案。（以前，我们每两周进行一次，通常会拖延几天左右。）

有13位开发人员和6位本地/ 9位离岸测试人员；从理论上讲，只有4个开发人员（和所有测试人员）才能处理偶数版本的发布，除非要完成的工作确实需要其他开发人员中的一些专门知识。每个周期将包含两天的开发工作和两天的质量检查工作（加上1天的范围界定/分类/ ...）。

我的问题是：

（a）在这个发布周期的长度上是否有人有经验？

（b）是否有人听说过试图释放的时间如此长？

（c）如果是（a）或（b），您在地球上如何运作？（也应避免任何陷阱，以此类推。）

（d）如果这项努力失败了，我们如何才能使损害最小化？

您当然可以每周交付一次，甚至可以更频繁地交付。目前，我们通常每两周发布一次，但是在某些合作伙伴没有通知的情况下部署功能并不稀奇，如果我们等待下一个周期，这将是无关紧要的。在接下来的几个月中的某个时候，我希望我们继续采用连续交付（一旦“完成”后尽快发布项目），但是我们还没有足够的信心去实现这一目标远。

关键是您需要使您的网站受到自动化测试的严格覆盖-单元测试和端到端验收测试/可执行规范。这也意味着您的构建是完全自动化的。在验收级别，我们使用Robot Framework，因为它采用关键字方法，因此非常适合快速建立可维护的测试套件。在外观上，我们的现场测试人员进行了一些粗略的检查，但是我们在印度也有几个人，他们在不同的浏览器上进行了更彻底的检查（有些网站可以通过为您截取屏幕快照来帮助您完成此类事情，例如BrowserLab）。

我们没有完全自动化部署（最后一步需要人工干预，这对我们来说是一个明智的决定）-但是我们会以短的部署周期来自动化所有事情，例如确保使用正确的数据库连接等。在这种情况下犯错太容易了。

关于持续交付，有一本相当不错的近期书籍，您可能需要检查一下，我已经略过，但尚未详细介绍。到目前为止，我所阅读的内容与我们的经验非常吻合：持续交付：通过构建，测试和部署自动化来可靠地发布软件

总而言之，您需要一支训练有素的团队，高度自动化以及最重要的一点是对该自动化的高度信任。对我来说，在您的情况下转移到每周周期似乎是一个错误-危机补丁提示了其他问题，您应该努力消除这些问题。加快节奏可能会使情况变得更糟。

如果您一直处于“危机发布”模式，那么我会退后一步，重新评估您的代码和流程，这是更加谨慎的做法。显然，那里存在某种故障，并且这种故障会不断重复发生。

尽管可能无法完全按照实际的生产规模进行此操作，但是至少有一位高级成员以及开发人员和测试人员的其他子集专门用于此评估可能是值得的。

在我看来，“一次四连胜”听起来并不是一个明确的赢家。这意味着不断的上下文切换，这意味着效率要低得多。

请记住，如果您一直在急于进行更改，那么您更有可能在这些更改中犯错误，并在执行操作时破坏其他内容。

在软件行业中，肯定已经实现了不到一周的发布周期。他们采用了称为持续交付的技术（也称为持续部署）。

有一家公司每天发布50次。 这篇博客文章描述了他们是如何做到的。

管理层花了一些时间思考如何减少这些“危机工作”的发生频率，并提出了我们每周都会发布的解决方案。

看来您的管理层是世界冠军……为什么不投资于团队合作精神呢？您将看到问题将自己消失。

（a）+（b）恕我直言，根据您的团队规模，最长应为两周。一个人表演或很小的团队（例如2或3个）将需要一周的时间。

（c）+（d）但是，不管您的团队或项目的规模如何，我要做的第一件事就是自动化构建和部署。通过在项目的早期阶段进行工作，我节省了数天甚至数周的工作。

您的部署必须一键完成。从源到阶段，再从阶段到生产。有很多工具可以实现这一目标。从蚂蚁/蚂蚁到超重的东西，例如Automated Build Studio。

从文件部署到数据库升级，一切都可以自动化，包括备份，通知，报告，...