Gitflow和测试/部署 [英] Gitflow and testing / deployment

问题描述

我有几个关于如何处理测试和部署的问题，当许多开发人员正在研究相同的事情（不能进一步分割）并且您仍然想每天部署时。

目前我们遵循Gitflow，我们有我们的功能分支，每个人都在处理一个独立的功能。功能被合并到开发分支中。我们现在需要一些时间来满足用户需求/缺陷修复/快速功能等。

最终目标是尽快将这些产品推向PROD。我的问题是你会建议这样一个过程：
$ b $ 1我们可以在不引入官僚作风的情况下进行部署（例如，每个月的最后一个星期五发布）。

2）如果有人提交引入错误的代码，它不会影响其他无错代码的其他人。换句话说，如果编码器A试图通过引入一个新的错误来修复一个错误，并且编码器B已经修复了他的错误，那么编码器的B代码将会进一步进入流水线，而编码器A将会很晚的修复这个错误：）

3）我们不能有无限的测试环境。我们也不想花一天时间设置测试环境。我们需要一个可以解决这个需求的解决方案（因此，除非我错过了某些功能，否则测试功能分支不是一种选择）。

3）测试人员毫无疑问知道什么他们正在批准进入prod。

顺便说一句，我们有一个相当广泛的单元/功能测试集，但这个问题是关于这个过程，所以这些都没有真正相关。

另外，我研究了所有其他问题，没有真正解决我所有的问题。如果你认为有一个，我会很高兴看看。

谢谢

解决方法

流程明智的是，与标准流程相比，您只需要一个可选步骤：如果发现错误（或者可能是严重错误），则回滚所有更改（即合并，其中包含错误）。

以下是它的工作原理：

• create a Branch Under Test或简称为开发分支




• 功能分支会合并到测试分支中，而不是直接分支到开发分支中




• 你有一个BUT，它现在或者与最后一个版本相同，或者是从这个过程的最后一次迭代得到很好的测试。

现在您合并了您已准备好的所有分支中的所有功能分支/你测试它。如果出现一个关键问题，即使得包含该bug的功能/ bug修复不适合下一个版本，则通过重置，重做所有合并或重新绑定以及移除提交来撤消该功能的合并一样。请注意，这会更改分支的历史记录，因此在测试完成之前，没有人应该将此分支合并到任何内容中。 如果测试迭代成功完成主要错误）你将它合并到开发中。

让我们检查一下如何满足你的要求：

我们可以在不引入官僚作风的情况下进行部署（例如，在每个月的最后一个星期五发布）。

您仍像以前一样拥有您的发布分支。这里没问题。唯一的开销是你可能不得不撤消合并，如果他们是越野车，但我没有看到解决方法。

如果有人提交引入错误的代码，它不会影响其他人提供无错代码。换句话说，如果编码器A试图通过引入一个新的错误来修复一个错误，并且编码器B已经修复了他的错误，那么编码器的B代码将会进一步进入流水线，而编码器A将会延迟修复错误

检查

我们不能拥有无限的测试环境。我们也不想花一天时间设置测试环境。我们需要一个可以解决这个需求的解决方案（因此，除非我错过了某些功能，否则测试功能分支不是一种选择）

您只需要一个测试环境。更多可能会有助于促进多个测试人员的平行工作。但是这是可选的。

测试人员毫无疑问知道他们正在批准何时进入产品。

如果某个功能分支是BUT历史记录的一部分，您可以使用标准git命令轻松确定。
$ b

缺点/你需要的东西

没有任何东西投入生产，或者只要不被批准就可以与其他人合并由测试人员。这可能会成为过程中的瓶颈，特别是如果来自功能分支的内容质量低下。如果测试人员必须解开东西，他们将不得不重新测试剩下的东西（至少我知道测试人员会坚持这一点，并且有充分的理由）。所以错误减慢了你的速度（这不是新的，但是在这样的过程中变得非常明显）。为了限制这种影响，你应该付出很大的努力功能分支尽可能好：

• 在与BUT合并之前运行功能分支的自动测试


• 在与BUT合并后运行功能分支的自动测试


• 有很多好的自动化测试。
  
• 代码评论


• 结对编程


• 自动化测试环境中的部署

这样可以减少测试人员必须完成的工作量，加快其余部分将会有很大帮助。

你说你不能有很多测试环境。考虑是否可以有部分测试环境，它不需要所有资源，但仍然适用于某些测试。

I have a few questions around how do you handle testing and deployment when many developers are working on the same thing (that cant be split further) and you still want to deploy daily.

Currently we follow Gitflow where we have our features branches that everyone is working on an isolated feature. Features are merged into develop branch. Every now and then we take some time to cater for user requirements / bug fixes / quick features etc.

The end goal is to get those to PROD asap. My question is what process would you suggest such that:

1) We can deploy without introducing bureaucracy (e.g. Release on the last Friday of every month).

2) If someone commits code that is introducing a bug it doesn't affect someone else that has committed bugless code. In other words, if Coder A tries to fix a bug by introducing a new bug, and coder B has fixed his bug then coder's B code will get further into the pipeline while coder A will stay late fixing the bug :)

3) We cannot have unlimited testing environments. We also don't want to spend our day setting up testing environments. We need a solution that can work around this requirements (so test on feature branches is not an option unless I m missing something)

3) The testers know exactly without a doubt what they are approving to go into prod.

Btw we have a fairly extensive set of unit / functional tests but this question is about the process so those are not really relevant.

Also, I have researched all the other questions and nothing really addresses all of my questions. If you think there is one that does I would be happy to have a look.

Thanks

解决方案

Process wise you need only one more optional step compared to the "standard process": If you find a bug (or probably a critical bug) you roll back all changes (i.e. merges, which contain the bug).

Here is how it works:

• create a Branch Under Test, or BUT for short, from the development branch

• feature branches get merged into the test branch, not directly into the development branch

• you have a BUT which is right now either identical to the last release or well tested from the last iteration of this process.

• Now you merge all the feature branches /bugfixes in that branch that you have ready.

• you test it. If a critical issue arises, i.e. one which makes the feature/bugfix which contains the bug undesirable for the next release, you undo the merge of that feature by resetting, and redoing all merges or by rebasing, and removing the commit, which is basically the same. Note that this changes the history of the branch, so nobody should merge this branch into anything before testing is completed.

• if a test iteration completeted successfully (i.e. without major bugs) you merge it into development.

Lets check how this fulfills your requirements:

We can deploy without introducing bureaucracy (e.g. Release on the last Friday of every month).

You still have your release branches as before. No problem here. The only overhead is that you might have to undo merges, if they are to buggy, but I don't see a way around that.

If someone commits code that is introducing a bug it doesn't affect someone else that has committed bugless code. In other words, if Coder A tries to fix a bug by introducing a new bug, and coder B has fixed his bug then coder's B code will get further into the pipeline while coder A will stay late fixing the bug

Check

We cannot have unlimited testing environments. We also don't want to spend our day setting up testing environments. We need a solution that can work around this requirements (so test on feature branches is not an option unless I m missing something)

You only need one testing environment. More might be helpful to facilitate parallel work of multiple testers. But that is optional.

The testers know exactly without a doubt what they are approving to go into prod.

You can very easily determine with standard git commands if a feature branch is part of the history of the BUT, which is what you need.

Drawback / Things you need

Nothing goes into production, or can be merged with other peoples work as long as it isn't approved by the testers. This can become a bottleneck in the process, especially if the stuff that comes from the feature branches is low quality. If testers have to unmerge stuff they'll have to retest the rest (at least testers I know would insist on that, and for a good reason). So bugs slow you down (which isn't new, but becomes very obvious with such a process).

To limit this effect you should put a lot of effort to make the feature branches as good as possible:

• run automatic tests of the feature branch before merging with BUT
• run automatic tests of the feature branch after merging with BUT
• have lots of GOOD automated tests.
• code reviews
• pair programming
• automate the deployment in your test environment

Basically everything that reduces the amount of work the testers have to do and speeds up the rest will help a lot.

You said you can't have many test environments. Consider if you can have partial test environments, which don't require all the resources, but are still good for some of the tests.

这篇关于Gitflow和测试/部署的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！