如何在软件开发训练模型中管理功能或拉取请求? [英] How to manage features or pull requests in Train Model of Software Development?

查看:18
本文介绍了如何在软件开发训练模型中管理功能或拉取请求?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我们的团队现在正着手发布列车部署模型 (

这个想法是将您想要用于下一个版本的分支合并到一个中间瞬态集成分支(您可以称之为集成"或开发"或下一个"......).
为每个新版本重新创建该分支,并允许在集成中(一起)测试这些功能分支.

然后您只合并到 master 下一个版本中您真正想要的那些.
integration 分支合并到master.只有 feature 分支.

查看更多此处在这里.
我在此处回答了有关该工作流程的问题.

Our team is now moving to release train deployment model (http://thinking-in-code.blogspot.com/2010/07/train-model-of-software-development.html) and we need tools or method to manage how we merge Pull Requests and build new release.

Note: I will be using Git terminologies to explain the problem

With release train deployment model, the releases occur at fixed schedules and the features are pinned to a specific release. But the core idea with this model is that if a feature is not complete or specifically not bug free, that feature is not taken up in the coming release but scheduled for a later release.

With this in mind, we need some approach to manage Pull Requests and release builds with respect to following:

  1. A build can be made with all the feature branches so that this build can be given for testing (QA). We do not want to actually merge this in our development or release branch. (why? The next point deals with it)

  2. So if a feature is not zero bug (bug free), we would want to drop that feature. Hence we would actually merge only features with zero bugs and create new release build. In this way, a feature can easily be dropped. In terms of release train terminology, the feature would not board the release train.

What we have thought:

Assuming master contains the released code. Now the feature branches F1, F2, F3 are created on top of it.

  1. Our automation setup, would merge these feature branches (from pull requests having "Approved" state) in chronological order in a temporary branch cut out from master and the setup will create a build from this temporary branch for QA Testing. (The merging in temporary branch would not close the PR)

  2. Now, if only feature F1 and F3 are bug free on zero bug date, then PRs for F1 and F3 would be manually merged into master and a final release build would be created from master.

(Note: For point 1, if merge conflict arises, developers of individual branches would resolve it.)

Is there any Jenkins plugin or any other tool which can help us achieve the above. Please share some thoughts about this and suggest any better way of handling this problem.

解决方案

Hence we would actually merge only features with zero bugs and create new release build

Well... the problem is that the result of the merge (meaning the "0 bugs feature branches" merged) can result in some bug!
A 0-bug feature branch (when develop in isolation) can have bug when considered in integration.

The general git workflow which does follow a release train model would be the gitworkflow (one word)

The idea is to merge the branches you want for the next release to an intermediate transient integration branch (that you can call "integration" or "dev" or "next"...).
That branch is re-created for each new release and allow for testing those feature branches in integration (together).

Then you merge only to master the ones you actually want for the next release.
You do not merge the integration branch to master. Only feature branches.

See more here and here.
I answered questions about that workflow here.

这篇关于如何在软件开发训练模型中管理功能或拉取请求?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆