Git Flow流程发送功能以进行测试，仅实时部署特定功能 [英] Git Flow process to send features for testing, only deploy specific feature to live

问题描述

我们正在努力进行Git Flow流程，并将功能部署到我们的测试和实时环境中:

We are struggling with our Git Flow process, and deploying features to our Test and Live environment:

• 我们希望所有准备好进行测试的功能被组合并部署到测试环境中.
• 我们只希望将特定功能部署到实时环境

• We want all features that is ready for testing, be combined and deployed to the Test environment.
• We want to deploy only specific features to the Live environment

我们使用Git Flow的方式存在问题:

The problem with the way we use Git Flow:

1. 开发人员A按照正常的gitflow流程从"develop"创建功能，并使用新功能进行开发.准备进行测试时，他将其功能合并到"develop"分支中，并将"develop"分支部署到Test环境中.

1. Developer A follows the normal gitflow process to create a feature from "develop", and does his development in a new feature. When ready for testing, he merges his feature into the "develop" branch, and deploy the "develop" branch to the Test environment.

然后，开发人员B遵循相同的过程.这两个功能现在都已合并到开发"分支中，并且两个更改都在测试"环境中可见.

Developer B then follows the same process. Both features are now merged into the 'develop' branch, and both changes visible on the Test environment.

客户端在测试环境上进行测试，但仅批准开发人员A所做的更改以发布到实时环境中.因此，他将从"develop"创建一个新的"release"分支.但是，问题是，这将包括开发者B所做的更改.

The Client does the testing on the Test environment, but only approves changes made by Developer A to be released to the Live environment. So he will create a new 'release' branch from 'develop'. But this issue is, this will include change from Developer B.

仅从开发人员A发布更改的最佳实践是什么?

What is the best practice to only release changes from Developer A?

当前，我们正在遵循以下过程，该过程使我们可以将每个功能发布到Live服务器.但是必须有更好的方法吗?

Currently we are following the procedure below, which allows us to release to the Live server per feature(s). But there must be a better way?

我们遵循常规的Gitflow设置，但是我们还创建了一个名为"qa"的新分支，它将从主分支"branch"创建.这是我们遵循的过程:

We follow the normal Gitflow setup, but we also create a new branch called "qa", this will be created from the master "branch". This is the procedure we follow:

1. 拉动最新的开发"分支
2. 使用gitflow从开发"中创建功能
3. 在功能中进行所有开发
4. 一旦准备好进行测试，
   • 拉最新的"qa"分支
   • 在"qa"分支中
   • 将您的功能合并到"qa"中

• 删除功能
• 撤消您对qa的合并

• 确保您在master分支中
• 如果可能，测试项目并进行更改
• 将所有需要的文件复制到实时服务器

但是，通过创建此"QA"分支，我们根本没有按预期使用开发分支，从而使其变得多余.

But by creating this "QA" branch, we are not using the development branch at all as its intended, making it redundant.

我阅读了这些答案，但对我们没有帮助，或者我不理解此处和此处

I read through these answers, but doesnt quite help us, or I don't understand here and here

推荐答案

4年后，我将尝试回答我自己的问题.尽管@AlBlue的另一个答案是100％正确的做法，但这并不总是可行的.

After 4 years I will try to answer my own question. Although the other answer from @AlBlue is 100% the correct way of doing it, its not always possible.

这里有四个Gitflow选项，以允许使用单独的测试环境，并且仅允许将合并的特定功能合并到主服务器中:

Here are four Gitflow options to allow for a separate test environment, and allow for only specific features merged to be merged into master:

• 如第一个问题中所述，创建一个单独的分支进行集成测试，然后将每个功能合并到该分支中以进行批准.可以在此处找到更多信息 Git分支模型策略.缺点是您将有很多分支机构，如果其他选择可行，我也不喜欢这种解决方案.
• Cherry Pick:经常合并到开发中，在开发上进行集成测试，一旦测试通过，Cherry Pick功能应该包含在发行版/主版本中.(还没有尝试过，但似乎是一个任务)
• 使用功能开关(如Alblue所述)
• 修正您的流程，以使git合并与客户测试脱钩"-就像AlBlue在他的回答中所说的那样.现在，这是我们的首选选项，因为现在已经对自动化部署进行了排序.只需单击一个按钮，就可以为每个功能创建一个单独的托管环境(Azure devops + Azure托管)，因此在合并到开发之前，每个功能都需要进行测试.

• As mentioned in the initial question, create a separate branch(es) for integration testing, and merge each feature into this branch to be approved. More information can be found here Git branching model strategy . Downside is you will have lots of branches, I am not a fan of this solution if the other options are possible.
• Cherry pick: merge into develop often, do integration testing on develop, once testing is approved, cherry pick features that should go into the release/master. (Haven't tried this but seems like a mission)
• Use feature switches (As Alblue mentioned)
• "Fix your process so that you decouple the git merges to master with the customer testing" - exactly as AlBlue said in his answer. This is now our preferred option because we have our automated deployments sorted now. For each feature a seperate hosting environment can be created with a click of a button (Azure devops + Azure hosting), so each feature needs to be tested before being merged into develop.

这篇关于Git Flow流程发送功能以进行测试，仅实时部署特定功能的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！