一个星期的发布周期:我如何使这是可行的？

Question

在我的公司(3岁的网络行业初创公司)，我们经常遇到产品团队说“啊啊，这是危机修补程序！”(不是每个人都这样吗？)

这对工程人员的生产力(和士气)有影响，包括自己在内。管理层花了一些时间考虑如何减少这些当天请求的频率，并提出了解决方案，我们将每周发布一次。(以前我们每两周做一次，这通常是几天左右的事。)

有13名开发人员和6名本地/9名离岸测试人员；理论是只有4名开发人员(以及所有测试人员)将在偶数版本上工作，除非有一项工作确实需要其他开发人员提供一些特定的专业知识。每个周期将包含两天的开发工作和两天的质量保证工作(外加一天的范围界定/筛选/.)。

我的问题是：

(a)是否有人有过这种释放周期的经验？

(b)是否有人听说过这段时间的释放周期，甚至有人试图这样做？

(c)如果(a)或(b)，你究竟如何使它发挥作用？(任何需要避免的陷阱等也会受到重视。)

(d)如果这一努力失败，我们如何才能将损害降到最低？

Answer 1

你当然可以每周递送--甚至更频繁。目前，我们通常每两周发布一次，但当某个合作伙伴在没有通知的情况下部署功能时，如果我们等待下一个周期，这将是无关紧要的。在未来几个月的某个时候，我希望我们能够按照标准的方式进行连续交付(一旦“完成”就会尽快发布产品)，但我们还没有足够的信心去做到这一点。

关键是你需要你的网站被自动化测试--单元测试和端到端验收测试/可执行规范--所覆盖。这也意味着您的构建是完全自动化的。在接受级别上，我们使用机器人框架，它非常适合快速构建可维护的测试套件，这要归功于它的关键字方法。关于外观和感觉，我们的现场测试人员进行了一些粗略的检查，但我们在印度也有几个人在不同的浏览器上进行更彻底的检查(有些站点通过为您截图来帮助这类事情，例如BrowserLab)。

我们没有完全自动化部署(最后一步需要手动干预，这对我们来说是一个明智的决定)--但是我们确实自动化了所有的事情，比如确保正确的数据库连接被使用，等等，在部署周期短的情况下，很容易在这类事情上出错。

最近有一本很好的关于连续送货的书，你可能想看看，我已经浏览过了，但还没有详细看过。不过，到目前为止，我所读到的与我们的经历非常吻合：持续交付:通过构建、测试和部署自动化发布可靠的软件

总之，你需要一个高度自律的团队，一个高度的自动化水平--最重要的是--对自动化的高度信任。在我看来，在你的情况下，转移到每周周期可能是一个错误-危机补丁暗示了其他问题，你应该努力消除这些问题。加快节奏可能会让情况更糟..。

Answer 2

如果您持续处于“危机发布”模式，我会说退一步重新评估您的代码和流程会更谨慎。显然，那里有一些失败，只是不断地重复。

虽然在真正的生产规模上不完全可能做到这一点，但至少有一位高级成员和一些其他开发人员和测试人员专门从事此评估可能是值得的。

在我看来，“一次4开始”听起来不像是一个明确的赢家。这意味着持续的上下文切换，这意味着效率要低得多。

记住，如果你总是急急忙忙地做改变，那么你更有可能在这些变化中犯错误，并且在你做这些改变的时候破坏其他的东西。

Answer 3

在软件行业中，发布周期肯定少于一周。他们使用称为连续交付 (也称为连续部署)的技术。

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