sprint流程如何捕获将代码部署到sprint的中间而不是最后的生产？目标是拥有“潜在可运输的产品”？
#1 楼
devops哲学中没有“每天一次部署”规则。更重要的是：尽快且尽可能频繁地部署。它还要求解耦架构，因此它的不同部分可以分别发布，也可以从发布中解耦部署。Gene Kim等人的《开发手册》呼吁修改“完成定义”以包括在Windows中运行类似生产的环境。这是在sprint期间始终遵循devops原则的方法。
我认为完成的定义是：只有在准备好投入生产之前，它才完成。一旦准备就绪，您可能会或可能不会释放它，具体取决于您的特定业务需求和sprint目标，但是如果现在还没有准备好发布它，则不会完成。
#2 楼
从某种意义上说，您的问题恰恰突出了团队试图敏捷但不具备良好的DevOps文化的好处时所面临的问题：实际上，我们无法保证在每次冲刺结束时他们都能将自己的任务交付给他们客户。在某些情况下，团队最终可能会使用更宽松的完成定义（例如在我的工作空间/分支中通过质量检查），或者可能考虑使代码可作为任务交付的其他步骤。 >
但是在DevOps为
able to deploy on demand or as needed的情况下，在sprint末尾发货应该是正常的。敏捷和DevOps确实可以很好地协同工作。很少有CI / CD工具能够真正保证它。#3 楼
敏捷软件开发方法描述了一套软件开发的价值观和原则，在这些价值观和原则下，需求和解决方案通过自组织跨职能团队的协作而发展。它倡导适应性计划，进化发展，早期交付和持续改进，并鼓励对变化做出快速而灵活的响应。这些价值观和原则。敏捷软件开发框架不断发展，其中使用最广泛的两个是Scrum和看板。结果（实际上，这是令人鼓舞的-您不太可能出错，并且更可能部署与开发和测试相同的产品）DevOps确实比Scrum更适合看板。
这是因为每天部署10个以上目标的快速测试和发布的DevOps哲学更适合于每次完成工作项时发布，这与第二种DevOps方法中概述的快速反馈和响应模型更加吻合。
但是，即使在冲刺期间，DevOps也会有助于将代码部署到测试，QA和登台，并且可以在测试单元中运行预先罐装的自动化测试，并报告结果或设置新的沙箱环境。这可以使开发人员仍然能够获得DevOps可以提供的快速，放大的反馈，并增加了编码时间，而不是在准备开发环境时浪费时间-即使您没有将其完全部署到生产环境中。
#4 楼
这里有一些很好的答案，但是我想举一个我们如何交付功能的例子。 “运送”到生产不是目标，目标是交付价值。将代码交付生产是达到目的的一种手段，我们通常会多次部署以启用功能。这是一个使用1周冲刺进行精简的人为设计示例。不进行重构将导致额外的技术负担和潜在的性能问题。他们花费星期一的其余时间和星期二的大部分时间进行重构，并在星期二下午发送此更改。用户看不到此更改。星期三和星期四，他们花费时间实施该功能，并在周四的午餐时间将其部署到生产中，但仅部署给一部分用户（使用功能标记或a / b测试） 。星期五早上，他们在代码中发现错误，或者可能是测试的不良结果，并在午餐时间发布了更新。后来，他们为所有人启用了该功能。最重要的是，它利用快速反馈来推动功能交付。采用编写功能并将其部署为“最终游戏”的方法会引入更长的反馈周期，并使您的团队反应迟钝，即减少敏捷。
#5 楼
我不清楚时间限制到预定长度（1/2/3周）的Sprint是否符合能够按需或按需部署的DevOps原则。
像往常一样，没有公认的DevOps定义，也没有对其含义的描述，因此我们只是在这里发表意见。但是在我的系统中，DevOps鼓励运营工程师尽其所能避免开发人员的参与，其中包括除非真正需要（配置，架构审查等），否则不要成为部署的障碍。 />
这与开发周期并没有真正的联系-不管周期是什么，您的工作都不应该成为其中的障碍。 sprint流程捕获的代码是在sprint的中间而不是在目标是“潜在可交付产品”的末尾部署到生产中的？
当然这取决于您公司，但我认为只有在用户拥有该功能后才能使用。