一个迭代就发布一次可行？
迭代通常被认为是一个固定的time box，让团队有一个较为固定的冲刺节奏。SCRUM里面把这个time box叫做 Sprint(冲刺)。为了避免名词上的吹毛求疵，笔者使用迭代这个无论是否使用SCRUM,是瀑布还是敏捷，还是大规模敏捷的组织都熟悉的词：迭代。
在敏捷软件开发中，如SCRUM中，Sprint 是一个固定的时间周期，通常为两到四周，团队在这段时间内致力于完成一组特定的工作目标。Sprint 的目的是提供一个可预测的节奏，帮助团队维持高效的工作流程，并确保在每个时间点都能交付可工作的软件增量。
发布，另一方面，是指将软件的新版本交付给用户的过程。在传统的软件开发模式中，发布通常是周期性的，可能会在几次迭代后进行，例如按季度或年度发布。然而，在现代敏捷和 DevOps 实践中，发布频率可以更高，甚至可以在单个迭代内进行多次发布，这取决于团队的工程能力和业务需求。
发布和迭代（迭代）之间的关系是多样的，可以从以下几种模式中变化：
·N:1 - 多次迭代后进行一次发布，这是传统的发布模式，常见于大型、复杂的项目或传统企业。
以下是SAFe中给出的某个批次的PI从计划到最终完全交付的过程视图。
当然现行的SAFe6.0中也加入了持续交付的概念，不像早期模型里面会提到在PI的最后经过若干个迭代后完成统一的发布。
·1:1 - 每次迭代结束时进行一次发布，这是更敏捷的工作模式，可以快速响应市场变化和用户反馈。
·1:N - 在一次迭代内进行多次发布，这是现代 DevOps 实践中的目标，它要求高度自动化的 CI/CD 流程和快速反馈机制。
一个非常易于理解的模式是Github Pull Request/Gitlab Merge Request。如果某个需求的feature分支在经历了开发、评审和测试之后，在合并进主干的同时进行了发布，也就是所谓的“单件流”。
这种模式下的交付就可以做到在一个迭代内实现多次的发布。
我们从发布频率和迭代的关系来看。当一个迭代来完成一次发布。按照这样的节奏可能是大家所熟悉的所谓敏捷工作模式。也就是在一次迭代结束的时候交付一次可工作的增量，也就是实现一次发布。而在早年间，或者一些toB的软件公司，它的发布节奏会更慢一些，通常是经过若干次迭代之后才会进行一次发布，如按季度甚至按年进行发布。现在随着大家工程能力的提升，发布的频率也越来越快，也有团队可以实现在一次迭代内进行若干次发布。
因此。发布和迭代的关系是多变的，可以从N:1，到比1:1，直至1:N。
在设计DevOps平台的业务模型时,在支持现有现行的工作模式的同时，也要为未来提速增效所可能带来的工作模式的变化留好扩展的空间。也就是不能完全将迭代和交付等同于相同一个业务对象。
最后，发一下著名的交付模式和分支模型的图。具体就不解读了，感兴趣的读者可以自行对比。
