问如何将Devops按需部署与敏捷Sprint流程相关联

EN

在神的哲学中没有“每天部署一次”的规则。更多的是:尽快并尽可能频繁地部署。此外，它还需要解耦体系结构，因此它的不同部分可以单独发布，也可以用于从发布中分离部署。

吉恩金姆和al.calls的发展手册，用于修改to的定义，以包括在类似生产的环境中运行。也就是说，在冲刺过程中始终遵循发展原则。

您想要避免的是结束一个sprint，所有的开发人员都会交出他们经过测试的代码，这些代码正在工作，但没有集成，并以某种方式交给其他团队进行部署。

我认为done的定义是:直到它准备好在生产中运行，它才能完成。一旦它准备好了，你可能会也可能不会发布它，这取决于你的具体业务需求和冲刺目标，但如果它现在还没有准备好发布，它还没有完成。

从某种意义上说，您的问题正好突出了试图变得敏捷的团队所面临的问题，但没有良好的DevOps文化的好处:几乎无法保证在每一次冲刺结束时，他们都能够交付给他们的客户。

在某些情况下，团队可能会使用更宽松的done定义(比如在我的工作区/分支中传递QA )，或者说明将代码转换为任务的附加步骤。

但是，由于DevOps是able to deploy on demand or as needed，在sprint结束时发送应该是正常的。敏捷和DevOps真的很好地结合在一起。

附带注意:我个人认为able to deploy on demand or as needed是一个延伸-只有当CI/CD处理通过所有必要的QA检查时才会发生这种情况。很少有CI/CD工具能够真正保证这一点。

敏捷软件开发方法

描述了一组软件开发的价值观和原则，在这些价值观和原则下，需求和解决方案通过自组织、跨功能团队的协作努力而发展。它提倡适应性规划、进化发展、早期交付和持续改进，并鼓励对变化作出迅速和灵活的反应。敏捷这个术语(有时是编写的敏捷)被敏捷宣言所推广，它定义了这些价值和原则。敏捷软件开发框架继续发展，其中最广泛使用的两个是Scrum和Kanban。

虽然没有任何规则禁止在DevOps的末尾使用Scrum Sprint来部署Sprint的结果(实际上，这是鼓励的--您不太可能出错，更有可能部署与dev和测试相同的产品) DevOps确实比Scrum更适合看板。

这是因为DevOps以10+部署一天为目标的快速测试和发布理念更适合于每次工作项完成时发布，这与第二条路 of DevOps中概述的快速反馈和响应模型更加一致。

然而，即使在sprint中，DevOps也可能有助于将代码部署到测试、QA和阶段中，并让预先准备好的自动化测试通过测试单元运行，并报告结果或建立一个新的沙箱环境。这可以让开发人员仍然获得DevOps提供的快速、放大的反馈，并增加编码所花费的时间，而不是浪费准备开发环境的时间--即使您没有一直部署到生产中。