Git分支模型策略

问题描述

我们正在尝试遵循

解决方案

建立gitflow模型 - 更多地扩展它以满足您的需求。

通过将环境耦合到给定的分支，您在构建版本时给予自己更多的灵活性。即可以说你有两个非依赖特征（特征1和2）正在进行，这两个特征都已经被合并到你的'TestServer'分支中。如果功能1未能通过测试，则功能2仍然可以在没有功能1的情况下进一步发展 - 这是因为您合并到测试服务器是单向合并 - 没有出现，也没有历史记录。相反，您的Feature 2分支会合并为'develop'，并最终会'master'。

我们正在为自己采用/开发类似的策略。 我们的关键要求是适应不可避免的樱桃采摘功能。请注意，我们的解决方案虽然相当复杂，但专为企业应用程序设计，可作为多个业务所有者拥有的多种服务的平台，并利用多个内部框架。

环境

• QA：让开发者确保他们的功能是可测试的。阶段：项目经理/测试经理在各种业主进行UAT测试之前进行抽烟测试UAT：对于业主的全面测试和商业签字，


• BETA：仅用于部署/发布的测试


• LIVE：..

这些环境分为两个类别，'测试中'（QA，Stage和UAT）和'制作'（BETA和LIVE）。

分支

功能优先级可能经常发生变化，从测试问题到监管限制/请求。为了适应这种情况，创建了多个分支来表示环境/类别，如下所示：

• 主人：表示最后一个生产 strong>发布


• 发布候选：下一个发布发布的一组功能
  
• UAT：代表UAT环境


• 阶段：表示'QA'和'阶段'


• 特征 - xxx：用于特征开发

>

我们还根据需要使用Master的HotFix分支，并在预生产分支中准备产品发布（纠正错过的版本增量等 - 次要内容）。

我们分支机构的使用示意图：

分支和合并/ WorkFlow

1. 我们总是从Re租赁 - 候选人，因为此分支始终包含致力于生产功能。
   

2. 一旦某个功能准备好进行测试，它就会被合并（单向）到'Stage'中。这会触发CI构建并部署到QA。

如果QA服务器看起来稳定，开发人员会触发自动部署到Stage。



3. 如果需要更改，请将其设置为功能并重复。如果确定进行业务测试，则从功能合并到UAT。这将部署到UAT。

如果功能未能通过业务测试，请对功能进行更改并重复。如果功能延迟，则不采取任何行动。如果功能正常并签名，然后合并到发布候选版本。


4. 一旦功能的集合（1个或更多）处于发布候选版本中，通过从Release-Candidate合并到Master（通过预生产）进行部署。 部署失败，然后是HotFix。如果确定，请部署到Live。

我们的工作流使用TFS，如下所示：

$ b

发布工作流程

最后，对环境/类别的每个部署应如下所示：

p>

We are trying to follow the gitflow branching model, but with a twist.

We have have four servers environments where the product can be deployed to, each server serves a purpose : development, internal testing, external testing, and production.

• DevServer, where developers test their different features, while developing. Developers cannot test locally on their machines, they have to make their changes on the DevServer to be able to test
• TestServer, where QA testers test multiple features once developers are done
• ReleaseServer, where releases are tested in isolation before moving them to production
• ProductionServer. The production server

We are trying to make the merging / conflicts resolution as easy as possible, so we created two extra branches which is not part of the gitflow model.

Normal gitflow branches

• develop
• master (matches 'ProductionServer')
• featureXXX
• releaseXXX (weekly releases are deployed to 'ReleaseServer')

But also these two branches which is not standard and might need to change...

• dev-release (copy of DevServer)
• test-release (copy of TestServer)

Then process is then as follow:

• developer create their 'featureXXX' from 'develop'
• multiple developers merge their different 'features' into 'dev-release' branch, and 'dev-release' branch gets released to the 'DevServer' where all the developers can then test their different features. Not all these features will be in the same next release
• Once the developers are happy with their dev testing above, they merge their 'featureXXX' into branch 'test-release', and this gets deployed to 'TestServer'. Not all features here will be part of the same next release.
• Once testing on 'TestServer' is done for featureXXX, the developer can close their featureXXX into 'develop'.
• Developer then either create a new 'releaseXXX' or merge their 'featureXXX' into an existing 'releaseXXX'.
• The 'releaseXXX' branch is deployed to to 'ReleaseServer' and tested.
• Once 'releaseXXX' testing is signed off, 'releaseXXX' is merged into develop and master, and deployed to 'ProductionServer'

Are we messing up the whole gitflow model?

Here is our brancing process:

解决方案

To answer your question, no you're not messing up the gitflow model - more extending it to meet your needs.

By coupling environments to a given branch, you're giving yourself much more flexibility when it comes to building releases. i.e. lets say you have two non-dependent features (Feature 1 and 2) in progress, both of which have been merged into your 'TestServer' branch. If Feature 1 fails testing, Feature 2 can still be progressed further without Feature 1 - this is because your merge into 'TestServer' is a one-way merge - nothing comes out, no history. Instead, your Feature 2 branch is merged into 'develop' and eventually 'master'.

We're in the process of adopting/developing a similar strategy to yourself. The key requirement for us is to accommodate the unavoidable cherry-picking of features. Note that our solution, although rather complex, has been designed for an enterprise application, serving as a platform for multiple services owned by multiple business-owners and utilise multiple in-house frameworks..

Environments

• QA: for developers to ensure that their feature is testable.
• Stage: for project managers / test managers to smoke-test prior to UAT testing by the various 'Business Owners'
• UAT: for full testing and business sign-off by the 'Business Owners'
• BETA: merely a test of deployment/release
• LIVE: ..

These environments are grouped into two categories, 'in-test'(QA, Stage and UAT) and 'production' (BETA and LIVE).

Branches

Feature prioritisation can change often, from testing issues through to regulatory restrictions/requests. To accomodate this, multiple branches are created to represent the environment/categories as follows:

• Master: Represents the last production release
• Release-Candidate: A collection of features for the next production release
• UAT: Represents UAT environment
• Stage: Represents 'QA' and 'Stage'
• Feature-xxx: For feature development

We also utilise a HotFix branch from Master as required, and prepare production releases in a 'Pre-Production' branch (correcting missed version increments etc - minor stuff).

A diagram of our Branches in use:

Branching and Merging / WorkFlow

1. We always branch new Features from Release-Candidate as this branch always contains the 'Committed for production' features. Nothing leapfrogs once the commitment for production has been made.

2. Once a feature is ready for testing, it's merged (one-way) into 'Stage'. This triggers a CI build and deploys to QA.

3. If the QA server looks stable, the developer triggers an automatic deployment to Stage.

4. If changes are required then make them in feature and repeat. If OK for business testing, then merge from Feature to UAT. This deploys to UAT.

5. If feature fails business testing, then make changes in feature and repeat. If feature is delayed then take no action. If feature is OK and signed-off, then merge to Release Candidate.

6. Once collection (1 or more) of features are in Release-Candidate, trigger production deployment by merging from Release-Candidate to Master (via Pre-Production).

7. Deployment failed, then HotFix. If OK, deploy to Live.

Our workflow, using TFS, looks like this:

Release workflow

And finally, each deployment to an environment/category would look like this:

这篇关于Git分支模型策略的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！