Web 应用程序部署流程、Scrum Sprint、Git 流程、版本控制 [关闭]

Question

我们有一个小型 Scrum 团队，负责开发一个拥有大量用户的网站。我们想改进我们的开发和发布/部署过程，但是那里有很多概念，在我们看来并不完美。由于我们不是唯一一家开发网站的公司，我认为在这里询问可能是个好主意；）

首先，软件状况不佳，因此无法进行持续交付或持续部署之类的事情，因为测试覆盖率差，而且我们无法很快改变。

我们有两周的 sprint，所以我们在那段时间开发新功能或解决错误，在最后的 sprint 会议之后，我们将功能分支合并到 master（我们使用 git 中的功能分支和 pull-request 进行审查和合并） ，做一些测试，然后将 master 部署到公共 beta 环境中。在那里，我们通常会发现一些错误，解决它们，然后我们将主要的包含 beta 修复程序部署到生产环境中。之后，我们开始下一个 sprint。

但这个过程远非完美。首先，在我们的 sprint review 会议上展示所有这些分支的特性是很困难的，而且因为我们只有一个被部署的主分支，我们不能轻易地将修补程序部署到不同的环境中。有时我们需要更多时间在我们的 beta 环境中进行测试，因此我们无法将新功能合并到 master 或相同的生产环境，一旦部署，如果我们已经在 beta 测试新功能，我们将无法部署修补程序。如果我们预计测试版或生产中的 bug 会因较大的变化而出现，那么开发也不得不将功能分支保留更长的时间，因此以后合并功能分支会变得越来越痛苦。

首先，我们考虑了长期运行的分支，例如用于开发、生产和测试版的 master。所以我们可以将我们想要的任何特性合并到三个分支之一中。但是我们真的很喜欢处理拉取请求（评论、反馈和合并后删除功能分支），使用起来真的很好，但我们只能将拉取请求分支应用到另一个分支。所以在这里，我们可以在不删除分支的情况下合并到 master，并且必须切换到另一个工具来将功能合并到 beta 或生产，或者为 beta 和生产创建新的 pull request。它以这种方式工作，但它不是一个很好的工作流程，只合并到一个主分支。

我们还考虑了 git-flow（Vincent Driessen 的分支模型），它看起来不错，但它似乎更适合具有传统发布周期和版本控制的软件，而不是 100% 用于没有真实版本的 Web 应用程序，但部署冲刺后准备好的一切。它解决了修补程序问题，有一个额外的开发分支，但它需要发布版本。所以我们可以创建一个发布分支，解决问题，将其发布到生产环境并删除发布分支。我们可以使用发布分支打开合并到 master 的拉取请求，但如果我们想将其发布到 beta 版（我们使用 capistrano 进行部署），问题就开始了，因为分支在每个 sprint 中都会发生变化。如果我们想在我们的 beta 环境中测试功能怎么办？我们可以将发布分支用于测试版，但是这样发布到生产环境必须等到发布/测试版分支中的所有功能都准备好。如果大型功能的测试需要很长时间，我们就无法将小型更新上传到生产环境。

下一个问题是版本控制。我们使用 jira，jira 喜欢使用版本来发布。我们可以使用“1,2,3”之类的版本...，但是一个冲刺应该是一个版本吗？感觉不对，因为 sprint 计划与发布计划不一样，还是在开发 Web 应用程序时应该一样？因为有时我们会在一个 sprint 中开发功能，这些功能需要更长的时间，并且会在接下来的 1-2 个 sprint 完成后发布。使用 git-flow，这些更改在准备好之前无法合并到开发中，因为每个版本都是从开发分支分支出来的。所以这样一来，有些特征分支很长一段时间没有合并，合并变得越来越困难。这与持续集成相反。

最后但同样重要的是，部署和 QA 流程不太适合 scrum，我们没有自己的网络运营团队，当 sprint 准备好时，产品负责人必须审查故事，我们必须测试它们，将它们部署到测试版/生产环境，并且必须立即修复其中的问题，这也会中断或下一个 sprint。我们不确定何时是合并功能分支的合适时间？在审查会议之前？这样我们可以将产品所有者不接受的特性合并到应该很快发布的分支中，但是如果我们不合并它们，我们必须在它自己的分支中演示每个特性并合并每个接受的特性分支，所以集成和测试只能在 sprint 评审会议之后开始。集成和测试可能需要几天时间并且需要开发资源，那么下一个 sprint 应该什么时候开始呢？发布到生产后？但是这样我们就不能每两周开始一个 sprint，也不是每个开发人员都需要进行集成和 QA，那么他们应该做什么呢？目前，我们在上一个 sprint 的审查会议之后立即开始下一个 sprint 的计划会议，但是如果我们这样做，我们不确定需要多少时间来发布从 sprint 中提取资源的...

那么您如何发布 Web 应用程序？ 您使用什么工作流程？ 如果我们想在工作流中集成拉取请求，最好的方法是什么？ 您如何将 QA 和部署集成到 Scrum 工作流程中？

Answer 1

我尝试做一个积压并优先处理它：

Prio 1：重新定义完成的定义。

我认为你是在背叛自己，你可以在一个 sprint 中开发多少功能。 Scrums 将 sprint 的结果定义为“有用的软件增量”。 你所做的是产生一个“可测试的软件增量”。 您必须将测试包含在 sprint 中。所有未经测试且带有“生产就绪”标记的故事根本就没有完成。

优先级 1：进行回顾

让团队一起讨论这个版本的混乱。您需要一种轻量级的方式来测试故事。您和您的团队最清楚什么是可用的，什么是阻碍您的。 如果你已经在做这些回顾，那么这个就完成了。 ;)

Prio 1：自动化测试

如果没有单元测试，您如何完成任何故事？ 开始制作它们。我建议您搜索系统中最微妙/最重要的组件，并为该组件带来至少 60% 的测试覆盖率（ECLemma/JaCoCo 帮助）。 为此投入整个冲刺。我不知道你的国防部，但这是一项被拖延且必须重做的工作。 如果经理告诉你这是不可能的，让他想起过去的瀑布般的美好时光，2 周的开发还没有引起他的注意，为什么现在要...

优先级 2：集成测试

您已经进行了单元测试，并且在冲刺中进行了一些额外的手动测试。 您想要的是将集成测试（与 master 合并）包含到 sprint 中。

这必须发生，因为您必须（！）解决已引入的 sprint 中的错误。因此，必须进行早期整合。 要做到这一点，在 sprint 中按优先级工作很重要：优先级最高的任务/故事必须首先由整个团队解决。目标是对其进行编码和单元测试，然后将其交给测试人员进行冒烟测试。发现的错误具有故事的优先级。当它工作得足够好时，这部分将被部署到集成中并在那里进行测试。 （当然大多数时候，并不是所有的团队成员都能有效地处理一个故事。所以另一个故事是并行处理的。但是每当您的 Prio1 故事停止时，整个团队都必须在那里提供帮助。）

Prio 2：减少新功能提高质量

要提高质量，您必须降低对新功能数量的期望。更努力地工作并不是 Scrum 告诉你的。它告诉您提供更高的质量，因为这将加快您的中期发展。

Answer 2

关于 QA 和部署，我建议如下：

• Commit your code early to the main branch, and commit often。我对 git 完全不熟悉，所以我无法评论你是如何使用它的，但我一直在主干（使用 Subversion）工作，所有开发人员都向主干提交新代码。当我们创建发布时，我们将主干分支以创建发布分支。
• 如果您还没有这样做，那么请设置一个持续集成系统（我们使用TeamCity，但它在某种程度上取决于您的堆栈）。获取您在每次提交时运行的单元测试。
• 创建一个definition of 'done' 并使用它。这将阻止您处于测试在前一个 sprint 中实现的功能的情况。确保您对完成的定义包括通过由您的产品负责人共同编写的验收测试，我认为 PO 不应该在 Sprint 审查期间拒绝功能。