我们有一个小型的scrum团队，它开发了一个有很多用户的网站。我们希望改进我们的开发和发布/部署流程，但在我们看来，有很多概念并不能完美地结合在一起。因为我们不是唯一一家开发网站的公司，我想在这里问一下可能是个好主意;)
首先，软件不是很好，所以像持续交付或持续部署这样的事情是不可能的，因为糟糕的测试覆盖，这是我们不能很快改变的。
我们有两周的冲刺，所以我们在这段时间内开发新功能或解决错误，在最后的冲刺会议之后，我们将功能分支合并到master中(我们在git中使用功能分支并进行审查和合并)，做一些测试，并将master部署到公共测试版环境中。在那里，我们通常会发现一些错误，解决它们，然后将主版本(包括测试版补丁)部署到生产环境中。之后我们开始下一个冲刺。
但是这个过程远非完美。首先，在我们的sprint评审会议上展示所有分支的特性是很困难的，而且因为我们只有一个部署的主分支，所以我们不能轻易地将热修复程序部署到不同的环境中。有时我们需要更多的时间在beta环境中进行测试，所以我们不能合并新的特性，或者对于生产环境来说，一旦部署，如果我们已经在beta环境中测试新特性，我们就不能部署热修复程序。如果我们预计由于较大的更改而在beta版或生产版中出现bug，那么开发部门就必须将功能分支保留更长的时间，因此稍后合并功能分支会变得越来越痛苦。
首先，我们考虑了长期运行的分支，如master用于开发，生产和测试。所以我们可以将任何我们想要的特征合并到三个分支中的一个。但是我们真的很喜欢使用拉请求(审核、反馈和合并后删除特性分支)，使用它真的很好，但是我们只能将一个拉请求分支应用到另一个分支上。因此，我们可以在不删除分支的情况下合并到主版本，并且必须切换到另一个工具来合并一个特性到beta或生产版本，或者为beta和生产版本创建新的拉取请求。它是这样工作的，但它不是一个很好的工作流，因为它只合并到一个主分支。
我们还考虑了git-flow (Vincent Driessen的分支模型)，这看起来不错，但它似乎更适合具有传统发布周期和版本控制的软件，而不是100%适用于web应用程序，web应用程序没有真正的版本，但在sprint之后部署所有准备好的东西。它解决了热修复问题，有一个额外的开发分支，但它需要发布版本。所以我们可以创建一个发布分支，把问题整理出来，发布到生产环境中，然后删除这个发布分支。我们可以打开一个pull request，将它合并到master和发布分支中，但是如果我们想要将它发布到beta(我们使用capistrano进行部署)，问题就开始了，因为分支在每个sprint中都会更改。如果我们想在beta环境中测试功能该怎么办?我们可以使用发布分支进行beta测试，但这样一来，发布到生产的版本必须等到发布/beta分支中的所有功能都准备好了。如果测试大型功能需要很长时间，我们就不能将小的更新上传到生产环境中。
下一个问题是版本控制。我们使用jira, jira喜欢使用版本来发布。我们可以使用"1、2、3"这样的版本……，但是一个sprint应该是一个版本吗?感觉不对，因为sprint计划和发布计划不一样，或者在开发web应用程序时应该是一样的吗?因为有时候我们在一个sprint中开发功能，这需要更长的时间，并且在接下来的1-2个sprint中完成后才会发布。使用git-flow，这些更改在准备好之前不能合并到开发中，因为每个发布都是从开发分支中分支出来的。这样一来，一些特征分支长时间不合并，合并就变得越来越困难。这与持续集成是相反的。
最后但并非最不重要的是，部署和QA过程不太适合scrum，我们没有自己的web运营团队，当sprint准备好时，产品负责人必须审查故事，我们必须测试它们，将它们部署到beta/生产中，并必须立即修复其中的问题，这也会中断下一个sprint。我们不确定什么时候合并特性分支合适?在评审会议之前?通过这种方式，我们可以将产品所有者不接受的特性合并到应该很快发布的分支中，但是如果我们不合并它们，我们就必须在它自己的分支中演示每个特性，并合并每个接受的特性分支，因此集成和测试只能在sprint审查会议之后开始。集成和测试可能需要几天的时间，并且需要开发资源，那么下一个冲刺应该何时开始呢?在发布到生产环境之后?但这样我们就不能每两周开始一次冲刺，也不是每个开发人员都需要整合和QA，那么他们应该做些什么呢?目前，我们在上一个sprint的评审会议之后立即开始下一个sprint的计划会议，但是如果我们这样做，我们不确定我们需要多少时间来发布从sprint中提取资源的版本…
那么如何发布web应用程序呢?你使用什么工作流程?如果我们想在工作流中集成拉取请求，最好的方法是什么?如何将QA和部署集成到scrum工作流中?
我试着做一个待办事项，并按优先级排序:
先验1:重新定义完成的定义。
我认为你是在背叛自己，你可以在一个sprint中开发多少功能。scrum将sprint的结果定义为"软件的有用增量"。你所做的是产生一个"可测试的软件增量"。你必须把测试包含在冲刺中。所有的故事，没有经过测试，并有一个"生产准备"印章在它上面，根本没有完成。
先验1:做回顾
把团队聚集在一起讨论这个发布混乱。您需要一种轻量级的方法来测试故事。你和你的团队最清楚什么是可用的，什么是阻碍你的。如果你已经做了那些回顾，那么这次就完成了。;)
Prio 1:自动化测试
如果没有unittest，你怎么能完成任何故事?开始做吧。我建议您搜索系统中最微妙/最重要的组件，并将该组件的测试覆盖率(ECLemma/JaCoCo帮助)提高到至少60%。为此投入一整个冲刺。我不知道你们的国防部，但是这个工作被拖延了，必须重做。如果经理告诉你这是不可能的，提醒他过去的瀑布式开发时代，2周的开发都没有让他感到惊讶，为什么现在要…
Prio 2:集成测试
您有单元测试，并且您在sprint中做了一些额外的手动测试。您想要的是在sprint中包含集成测试(与master合并)。
这是必须发生的，因为你必须(!)在sprint中解决引入的bug。所以必须尽早进行整合。为了达到这一目标，在sprint中你必须按照优先级进行工作:最优先的任务/故事必须首先由整个团队解决。目标是将其编码并进行单元测试，然后将其交给测试人员进行冒烟测试。发现的bug具有故事的优先级。当它工作得足够好时，这个部分被部署到集成中并在那里进行测试。(当然大多数时候，并不是所有的团队成员都能有效地完成一个故事。所以另一个故事是并行处理的。但是当有什么事情阻止了你的Prio1 Story时，整个团队都必须帮助你。
Prio 2:减少新功能增加质量
为了包含更多的质量，你必须降低对新功能数量的期望。更努力地工作并不是scrum告诉你的。它告诉你要交付更高的质量，因为这将在中期加速你的开发。
关于QA和部署，我建议如下:
- 尽早将代码提交到主分支，并经常提交。我完全不熟悉git，所以我不能评论你是如何使用它的，但是我总是在主干上工作(使用Subversion)，所有的开发人员都向主干提交新代码。当我们创建一个发布时，我们将主干分支创建一个发布分支。
- 如果你还没有这样做，那么设置一个持续集成系统(我们使用TeamCity，但它将在某种程度上取决于你的堆栈)。获取每次提交时正在运行的单元测试。
- 创建一个'done'的定义并使用它。这将阻止您处于测试在前一个sprint中实现的功能的情况。确保你对完成的定义包括通过由你的产品负责人共同编写的验收测试，在我看来，PO不应该在Sprint Review期间拒绝功能。