通过Scrum和持续集成进行软件开发的良好工作流程
Answers:
您已经到达那里了，但是我会稍微扩展一下您的图表：
基本上（如果版本控制允许，例如，如果您使用的是hg / git），则希望每个开发人员/开发人员对都有自己的“个人”分支，其中包含他们正在研究的单个用户故事。完成功能后，需要将其推入中央分支“发布”分支。在这一点上，您希望开发人员获得一个新的分支，以便他们接下来需要进行的工作。原始功能分支应该保持不变，因此可以对其进行任何更改都可以单独进行（这并不总是适用，但这是一个很好的起点）。在开发人员恢复使用旧功能分支之前，您应该拉入最新的发行分支，以避免奇怪的合并问题。
至此，我们已经以“ Release”分支的形式发布了候选版本，并且我们准备运行CI流程（显然，您可以在该分支上的每个developer分支上执行此操作），但这是在大型开发团队中相当罕见，因为它会干扰CI服务器）。这可能是一个持续的过程（理想情况下，只要更改“发行”分支，CI就应运行），或者可能是每晚进行。
此时，您将需要运行构建，并从CI服务器获得可行的构建工件（即，您可以可行地部署的东西）。如果您使用的是动态语言，则可以跳过此步骤！构建完成后，您将要运行单元测试，因为它们是系统中所有自动化测试的基础；它们可能很快（这很好，因为CI的全部目的是缩短开发和测试之间的反馈循环），并且它们不太可能需要部署。如果它们通过了，您将想要自动将应用程序部署到测试服务器（如果可能），并运行所有可用的集成测试。集成测试可以是自动化的UI测试，BDD测试或使用单元测试框架（即“单元”
至此，您应该对构建是否可行有一个比较全面的指示。我通常使用“ Release”分支设置的最后一步是让它自动将候选发布版本部署到测试服务器，以便您的QA部门可以进行手动烟雾测试（这通常是每晚进行的，而不是每次检入，这样以避免弄乱测试周期）。这只是一个快速的人工指示，表明该构建是否真的适合实时发布，因为如果您的测试包不够全面，很容易错过一些东西，即使测试覆盖率达到100％，也很容易错过一些您可以't（不应）自动测试（例如图像未对齐或拼写错误）。
实际上，这是持续集成和持续部署的结合，但是鉴于敏捷的重点是精益编码和自动化测试，因为它是一流的过程，因此，您希望寻求一种尽可能全面的方法。
我概述的过程是一个理想的情况，有很多原因可能导致您放弃其中的一部分（例如，开发人员分支在SVN中根本不可行），但是您希望尽可能地针对它。
至于Scrum的sprint周期是如何适应这一情况的，理想情况下，您希望尽可能多地进行发布，而不要等到sprint结束后再发布它们，以便快速获得有关功能（以及整体构建）的反馈）对于投入生产是可行的，这是缩短与产品负责人的反馈回路的关键技术。
您可能需要为该图绘制一个更广泛的系统。我会考虑添加以下元素：
显示您对系统的输入，并输入给开发人员。称其为需求，错误修复，故事或其他内容。但是目前，您的工作流程假定查看者知道如何插入这些输入。
在工作流程中显示控制点。谁/由谁来决定何时允许更改主干/主干/发布分支/等等...？CIS上构建了哪些代码树/项目？是否有检查点检查构建是否损坏？谁从CIS放行到分期/制作？
与控制点相关的是，确定您的分支方法是什么以及它如何适合此工作流程。
有测试团队吗？他们何时参与或得到通知？是否在CIS上执行了自动化测试？破损如何反馈到系统中？
考虑如何将该工作流映射到具有决策点和输入的传统流程图。您是否捕获了充分描述您的工作流程所需的所有高级接触点？
我认为，您最初的问题是试图进行比较，但是我不确定您要比较哪个方面。像其他SDLC模型一样，持续集成具有决策点，但是它们可能在流程中处于不同点。
我使用“开发自动化”一词来涵盖所有自动化构建，文档生成，测试，性能评估和部署活动。
因此，“开发自动化服务器”具有与连续集成服务器相似但更广泛的权限。
我更喜欢使用由提交后挂钩驱动的开发自动化脚本，这些脚本允许私有分支和中央开发主干都实现自动化，而无需在CI服务器上进行其他配置。（这排除了我所知道的大多数现成的CI服务器GUI的使用）。
提交后脚本根据分支本身的内容确定要运行的自动化活动。通过读取分支中固定位置的提交后配置文件，或通过检测特定单词（我使用/ auto /）作为存储库中分支路径的组成部分（使用Svn）。
（使用Svn设置比使用Hg设置更容易）。
这种方法使开发团队可以更加灵活地组织工作流程，从而使CI能够以最小（接近零）的管理开销来支持分支机构的开发。
在asp.net上有很多关于持续集成的文章，您可能会发现它们很有用，它涵盖了相当多的基础知识和工作流程，它们与您的工作后的情况相符。
您的图没有提到CI服务器完成的工作（单元测试，代码覆盖率和其他指标，集成测试或夜间构建），但是我认为这已在“连续集成服务器”阶段涵盖了。我不清楚为什么CI框会被推回到中央存储库吗？显然，它需要获取代码，但是为什么还要将其发送回去呢？
CI是各种学科推荐的实践之一，它并不是scrum（或XP）所独有的，但实际上我想说的是，即使是非敏捷的流（例如瀑布（可能是湿敏捷的？），也可以从中受益）。 。对我来说，关键好处是紧密的反馈循环，您很快就会知道刚提交的代码是否可以与其余代码库一起使用。如果您正在冲刺中工作并且每天站立起来，那么能够引用状态或CI服务器中昨晚构建的指标绝对是一个加分项，可以帮助您集中精力。如果您的产品所有者可以看到构建状态-共享区域中的一台大型监视器显示了构建项目的状态-那么您确实加强了该反馈循环。如果您的开发团队经常进行承诺（每天一次以上，最好是每小时一次以上），那么会减少需要很长时间才能解决的集成问题的机会，但是如果这样做，很明显全部，您可以采取所需的任何措施，例如每个人都停止处理损坏的构建。在实践中，您可能不会遇到很多失败的构建，而这些构建需要花费几分钟的时间来确定您是否经常集成。
根据您的资源/网络，您可能需要考虑添加不同的最终服务器。我们有一个CI构建，它是由对仓库的提交触发的，并且假设构建并通过了所有测试，然后将其部署到开发服务器，因此开发人员可以确保它运行良好（您可以在此处包括Selenium或其他UI测试吗？ ）。但是，并不是每个提交都是稳定的构建，因此要触发到登台服务器的构建，我们必须标记要构建和部署的修订版（我们使用mercurial），这又是自动化的，只需通过提交特定的修订即可触发标签。投入生产是一个手工过程。您可以将其简化为强制构建，技巧就是知道您要使用哪个版本/构建，但是，如果您要适当地标记修订，则CI服务器可以签出正确的版本并执行所需的任何操作。您可能正在使用MS Deploy将更改同步到生产服务器，或者将其打包并放置在zip文件中，以供管理员手动部署...这取决于您对此是否满意。
除了升级版本外，还应该考虑如何处理故障并降低版本。希望它不会发生，但是可能会对您的服务器进行了一些更改，这意味着在UAT上不能运行的产品在生产中不起作用，因此您发布批准的版本会失败...您可以始终采用确定方法来确定错误，添加一些代码，提交，测试，部署到生产中以对其进行修复...或者您可以在自动发布到生产中包装一些其他测试，如果测试失败，则它会自动回滚。
CruiseControl.Net使用xml来配置构建，TeamCity使用向导，如果您想要避免团队中的专家，那么xml配置的复杂性可能是其他需要注意的事情。
首先，警告：Scrum是一种非常严格的方法。我曾在一些尝试使用Scrum或类似Scrum的方法的组织中工作，但他们中的任何一个都没有真正接近于完全使用整个学科。根据我的经验，我是一个敏捷的狂热者，但是（不情愿）对Scrum持怀疑态度。
据我了解，Scrum和其他敏捷方法有两个主要目标：
- 首先是提供一种明确的机制来管理风险和持续发现风险。
- 第二个是为利益相关者交流，需求发现和需求管理提供一种结构化的机制。
第一个（风险管理）目标是通过迭代开发实现的；迅速犯错并吸取教训，使团队能够建立理解和知识能力，以降低风险，并通过已提供低风险的“严谨”解决方案的方式来降低风险。
开发自动化（包括持续集成）是此方法成功的最关键因素。风险发现和教训学习必须快速，无摩擦且没有混杂的社会因素。（当人们用机器告诉他们自己是错误的而不是别人的时候，人们会更快地学习MUCH-自我只会妨碍学习）。
您可能会说-我也是测试驱动开发的粉丝。:-)
第二个目标与开发自动化的关系较小，而与人为因素的关系较大。实施起来比较困难，因为它需要从业务前端进行购买，而后者不太可能需要形式化的支持。
开发自动化可以在这里发挥作用，因为可以使用自动生成的文档和进度报告来保持开发团队外部的利益相关者不断更新进度，并且可以使用显示构建状态和通过/失败测试套件的信息辐射体来传达进度在功能开发方面，帮助（希望）支持采用Scrum通讯过程。
因此，总而言之：
您用来说明问题的图表仅捕获了过程的一部分。如果您想研究敏捷/ scrum和CI，我认为必须考虑该过程中更广泛的社会因素和人为因素。
我必须像往常一样敲打相同的鼓作为结尾。如果您试图在现实世界的项目中实施敏捷过程，那么成功机会的最佳预测指标就是已部署的自动化水平。它减少了摩擦，提高了速度并为成功铺平了道路。