敏捷和代码发布[关闭]

为什么在工作流程进行过程中没有任何形式的Sprint计划会议?标记您的存储库并立即开始下一个版本。如果您需要对候选版本进行bug修复,请从标记中分支并修复它们。批准工作流程和最终UAT测试不应涉及或延迟开发团队。(如果您实际使用的是Git或Mercurial,请原谅非分布式SCM术语。)

如果您采用像scrum这样的敏捷过程,那么发布输出是“可发布的软件”,而不是“已发布的软件”。如果您有一个开销,使产品发布,那么它可以并行发生。我应该补充一点,大部分测试应该作为冲刺的一部分——也许你需要重新审视在你的周期中到底做了什么测试?

如果您在测试“大”版本时遇到问题,那么您的发布周期将很长。发布的基本原则通常是==较小的发布。如果您遇到了问题,并且只发布了一小组不需要花费很长时间测试的特性,那么您的发布工程团队就是瓶颈,他们的瀑布式批准过程需要更改。

在Sprint期间全部发布到一个公共开发环境中,在Sprint期间发布到一个QA环境中。

在sprint结束时发布到参考环境中,只演示已完成(和已测试)的特性。

只要产品所有者愿意,就发布到生产中。

bug的风险不应该是一个问题,因为bug不应该与发布频率有任何关联,实际上更多的发布实际上意味着更少的风险和更少的bug。应进行测试 在期间 冲刺,而不是之后。如果某个东西没有经过全面测试,可能有问题,那么它就没有 完成 而且不应该进行拆卸,更不用说投入生产。

在最终发布到生产中应该是产品所有者的电话。几乎是一个政治化的瀑布发布工程过程 从未 把虫子排除在生产之外,它只会使表演更晚,而不是更快。经理们在表单上勾选一个带有“OK”的复选框,并不会让顾客看不到错误的代码。在开发过程中频繁发布给QA。测试不应该是发布工程周期的一部分,它应该是开发周期的一部分。

这取决于您的产品对任务的重要性。通过“发布”,你的意思是将你的生命关键软件发布到医院吗?还是休闲游戏网站?

如果您的工作是任务关键型或生活关键型的,敏捷可能无法为您工作。在这种情况下,您可能需要在部署之前进行更正式的测试。

如果你在一个非关键任务的网站上工作(这通常比不工作要好!)你有成为一辆小马车的自由。这有助于您更快地迭代并一次又一次地重新发布。

对于敏捷非常适合的那种产品,让开发人员自己测试,让客户看到结果,然后尽快向一小群用户(希望随机选择活跃用户——走廊测试)发起测试,如果这是一件小事,甚至是对整个用户群。在Web服务上,您可以快速完成此操作并在不经历太多痛苦的情况下修复它。