问良好的scrum和持续集成软件开发工作流

EN

你就是其中之一，但我会把你的图表做一些扩展：

基本上(如果您的版本控制允许这样做，即如果您在hg/git上)，您希望每个开发人员/开发人员都有他们自己的“个人”分支，其中包含他们正在处理的单个用户故事。当他们完成这个特性时，他们需要推入一个中央分支，即"Release“分支。此时，您希望开发人员获得一个新的分支，以便进行下一步的工作。原始特性分支应该保持原样，因此任何需要对其进行的更改都可以单独进行(这并不总是适用的，但它是一个很好的起点)。在开发人员返回旧特性分支之前，您应该使用最新的发布分支，以避免奇怪的合并问题。

此时，我们已经找到了一个可能的发布候选版本，它的形式是" release“分支，并且我们已经准备好运行我们的CI流程(在这个分支上，显然您可以在每个开发人员分支上这样做，但是在大型开发团队中，这种情况非常罕见，因为它会使CI服务器混乱)。这可能是一个固定的过程(理想情况下，CI应该在“发布”分支被更改时运行)，或者是夜间运行。

此时，您将希望运行一个构建，并从CI服务器获得一个可行的构建伪件(也就是说，您可以进行可行的部署)。如果使用动态语言，可以跳过这一步！一旦构建好了，您就会想要运行您的Unit测试，因为它们是系统中所有自动化测试的基础；它们可能是快速的(这很好，因为CI的全部目的是缩短开发和测试之间的反馈循环)，而且它们不太可能需要部署。如果它们通过，您将希望将应用程序自动部署到测试服务器(如果可能的话)，并运行任何可用的集成测试。集成测试可以是使用单元测试框架(即需要更多状态的“单元”测试)的自动UI测试、BDD测试或标准集成测试。

到目前为止，您应该对构建是否可行有了相当全面的指示。最后一步，我通常会设置一个“发布”分支，让它自动地将发布候选服务器部署到测试服务器上，这样QA部门就可以进行手动冒烟测试(这通常是每晚进行的，而不是每次签入，以避免扰乱测试周期)。这只是给出了构建是否适合于实时版本的快速人工指示，因为如果测试包不够全面，那么很容易遗漏一些东西，而且即使有100%的测试覆盖率，也很容易遗漏一些您不能(不应该)自动测试的内容(比如对错对齐的图像，或者拼写错误)。

这确实是持续集成和持续部署的结合，但是考虑到敏捷中的重点是精益编码和自动化测试作为一个一流的过程，您希望尽可能全面地获得一种方法。

我所描述的过程是一个理想的案例场景，有很多原因可以让您放弃其中的部分(例如，开发人员分支在SVN中根本不可行)，但是您希望尽可能多地使用它。

至于Scrum sprint周期是如何适应这种情况的，理想情况下，您希望尽可能频繁地发布版本，而不是等到sprint结束时才发布，因为快速获得关于某个特性(以及作为一个整体构建)是否可行的反馈，是缩短您对产品负责人的反馈循环的关键技术。

从概念上说是的。一个图表并不能捕捉到很多重要的要点，但如下所示：

1. 单元测试
2. 增量提交
3. 分期通常会被部署到，生产通常不会。

您可能希望为图表绘制一个更宽的系统。我将考虑增加以下内容：

显示您对系统的输入，这些输入是提供给开发人员的。把它们称为需求、bug修复、故事或其他什么。但目前您的工作流假设查看器知道这些输入是如何插入的。

显示工作流中的控制点。谁/什么决定什么时候允许更改进入主干/主/发布分支/等等.？在独联体上建立了哪些代码树/项目？是否有一个检查点来查看构建是否被破坏？谁从独联体释放到分期/生产？

与控制点相关的是确定您的分支方法是什么，以及它如何适合这个工作流。

有测试小组吗？什么时候涉及或通知他们？是否在独联体上进行自动化测试？破坏是如何反馈到系统中的？

考虑如何将此工作流映射到具有决策点和输入的传统流程图。您是否捕捉到了需要充分描述您的工作流程的所有高级触点？

我想，你最初的问题是试图作一个比较，但我不确定你在比较哪个方面(S)。连续集成与其他SDLC模型一样，都有决策点，但在过程中可能处于不同的位置。