CakeDC(cakephp company)Git workflow--适合于较大团队大型项目开发

CakeDC Git workflow是一个项目开发和版本发布的工做流，在这个工做流程中开发和版本发布周期是基于几个关键阶段(key phases):

• Development:

全部活跃的开发活动都由里程碑驱动，在这个阶段的产出是很不稳定的代码基线

• QA：

Quality assurance testing做为一开发周期的一部分，主要协助确保需求的知足性和质量的可接受性

• Review

客户或者评审员面对的是一个稳定的代码基线，该基线已经通过了QA流程，质量上已经被QA人员承认

• Release

发布版本在QA和review评审流程都顺利完成以后的产物。

cakeDC所使用的workflow设计是基于vincent driessen的gitflow推荐，虽然他们有一些类似性，可是也有部分的裁剪和修改，可能更加适合于较大型团队，有正式流程的项目开发

Organization：

本workflow设计的主要思想是它能适合于集成一个QA流程做为他们开发流程一部分的团队或公司，同时给客户提供一个稳定的stage server来review和approve the pending release。然而，若是你没有QA流程，或者不提供stage server for customer review/approve，这些步骤也能够轻易地被忽略。

贯穿各个phase咱们项目的整个开发和发布被划分为几个不一样阶段的目标，咱们称之为milestones。一个milestone自己并不等同于一个release.一个项目的一个版本能够由多个milestone构成，这依赖于项目的计划和资源情况。

这些phases由"permanent永久"和"temporary临时"的分支来表明，经过这些phase，推动咱们的开发流程向一个release的正确方向迈进。须要一个持续性的分支的缘由是为了准备各类部署需求，容许每个人在项目开发不一样阶段产品的状态有一个清晰地认识。这两种分支包含下面的git branches,而这将造成咱们的work flow的一部分。

Permanent braches:

1.develop

也被称为bleeding edge（前沿）,这个分支包含为当前milestone准备的已经结束的features。这是一个alpha状态的代码基线，每每被认为是很是不稳定的。

2.qa

全部为了一个milestone而作的开发活动最终在这个分支上来作验证和测试。这是一个beta阶段的代码基线，也被认为是不稳定的。

3.stage

一旦为了一个milestone作的开发工做经过了QA测试，那么就能够用这个分支来host stable code base for review.

4.master

若是上述stage分支的代码由客户或者评审人员approval了，那么stage分支的代码就merge到master,而这个master分支将在生产环境保留项目的当前稳定版本。

Temporary branches:

1.feature

这些分支是从develop分支上建立出来，目的是为了隔离一个特定任务的开发工做。feature自己的定义每每很大程度上与管理风格有关，好比milestone是一个长的或短的sprints。

2.issue

这些分支从qa分支上建立，目的是为了解决完整测试一个milestone的软件的QA阶段报出的问题

3.hot-fix

这些分支是由生产环境中报出的紧急问题而触发的。最好的状况下，这些分支将永远不会建立，由于咱们通过QA流程，质量获得了很好的保证

“永久”和“临时”的分支的重要区别是：对于permanent分支，永远不会在这个分支上直接修改代码commit代码，永久分支上永远是经过merge临时分支而获得相关代码的。完整的流程以下：

在下面的章节中，开发和版本发布的各个阶段phases将会分别描述，详细讲解各个流程

Development:

在一个milestone的实际开发活动中，开发人员将从develop分支建立feature branch

这些分支命名为"feature/xxx"。xxx一般对应着项目管理系统中的一个ticket，好比

$ git checkout -b feature/1234 develop
$ git push -u origin feature/1234

经过将开发任务隔离到一个独立的分支上，开发人员可以有效避免destablize develop分支，以避免影响他人的工做。并且，若是有些feature是基于其余的feature，那么这个feature分支能够被其余已经commit到develop分支的feature作updated(rebase)

若是你和其余的开发人员在作同一个feature，那么你能够checkout他们的分支，而且协同工做。

$ git checkout -t origin/feature/1234

当一个feature开发结束，它将被merge back to develop分支，feature分支自己能够被删除了。

$ git checkout develop
$ git merge --no-ff feature/1234
$ git branch -d feature/1234
$ git push origin :feature/1234

develop分支自己本认为是不稳定的，因此最好开发人员能有一个部署这个branch的服务器，这样他们可以轻易地修改项目的bleeding edge version of the project,辅助讨论或者提供一个review当前进展的方式。这也帮助那些对开发流程不是很是清晰地项目经理获取到将要到来的milestone的真实状态。

Testing:

当一个milestone被认为完成时，develop分支将被merge到qa分支，QA流程启动：

 

 

很是重要一点：当develop分支被merge到qa分支时，全部的新features将构成了下一个milestone.这就容许对当前milestone的测试和对下一个milestone的开发工做彻底并行化了。另外，因为QA流程是在一个专用的branch上进行的，这就容许测试阶段能够在不影响继续开发的前提下来作规划和执行。

$ git checkout qa
$ git merge --no-ff develop

在测试阶段，QA可能发现这个milestone的一些issues，也就是说有些feature是fail掉的。当这种事情发生时，为了解决这些bug咱们将要从qa分支上来建立issue分支。这些分支被命名为"issue/xxxx"，xxxx表明了你的项目管理或者bug tracking系统中的一个id，好比：

$ git checkout -b issue/1234 qa
$ git push -u origin issue/1234

当这个issue branch存续期间，若是这个问题自己依赖于另一个issue的结束，那么这个issue branch自己也能够被其余已经被commit到qa分支上的其余issue的commit来作updated/rebased。当问题解决了，merge到qa分支，而后这个issue分支就被删除了

$ git checkout qa
$ git merge --no-ff issue/1234
$ git branch -d issue/1234
$ git push origin :issue/1234

 

在QA阶段，一个专用的测试服务器应该是必须的。这个服务器部署qa分支的代码，专门用于QA团队来作测试使用。

Review:

一旦一个milestone贯穿了实际的开发活动，而且完成了QA流程，新的功能如今就能够放到stage分支上作review了。

在这里qa分支将被merge到stage分支上，同时qa分支也须要merge到develop分支上去，以便为未来的milestone来使用：

$ git checkout develop
$ git merge --no-ff qa
$ git checkout stage
$ git merge --no-ff qa

 

并且，为了标示milestone的结束，应该从stage分支上打一个tag,这些tag被命名为"milestone/xxxx" xxxx是一个milestone id，一般就是一个序数。

$ git tag -a milestone/1

stage分支如今能够部署到一个staging server上去了，能够邀请客户或者评审人员来review和评审。若是任何问题被发现或者新的功能在这个时间被要求，那么他们就将成为在develop分支上的当前active milestone的开发任务，或者能够计划到未来的开发任务中去。

在qa或者stage分支上，不容许直接修改commit，只容许经过feature分支merge到develop分支，随后经过QA流程。尊重这个流程很是重要，然而可能不少组织就直接在stage分支上打patch了，由于这将破坏QA流程。

Release：

当stage分支经过了review，在完成一个或多个milestone以后，一个release能够被建立了。这将是更新生产服务器代码的时

机了。

 

为了建立release，stage分支须要merge到master，另外，为了建立一个release，一个tag须要再master分支上打上。这些tags命名为"release/xxx" xxx为version number。

$ git checkout master
$ git merge --no-ff stage
$ git tag -a release/1.1.0

全部在本release以后从qa merge到stage的代码都构成了下一个版本的应用。

Hot Fixes:

在生产环境中，有时可能会发现一些重大问题，而用户又不能等到下一个release来解决，这时就须要用到hotfix了。

 

 

在这种状况下，一个hot-fix分支须要从master分支上建立，这些分支被命名为“hot-fix/xxx"xxx为bugid：

$ git checkout -b hot-fix/1234 master
$ git push -u origin hot-fix/1234

依赖于QA的需求，可能须要再问题解决后，就在hot-fix分支上来作验证。有3中方法：

1.Kamakazee: 这里hot-fix分支被merge到master分支，QA直接在生产环境中测试。这是很差的方式，由于数据的不一致性可能致使问题

2.Copycat:这里hot-fix被merge到master，而master分支自己被staged到一个专用的服务器。若是生产环境是基于pushes to the repository or a scheduled build来自动部署的，那么

这就多是不可能的。

3.Paranoid:这里hotfix分支staged on a dedicated server，QA必须评审测试，以后才能merge到master。那个staged server有可能须要replicate the data used in the production environment。可是若是因为法律问题或者数据私密问题，也可能不可行。那么一个可选项就是直接stage on the production itself.

一旦patch自己成功了，the hot-fix分支必须merge到stage,qa,develop分支上去。

$ git checkout master
$ git merge --no-ff hot-fix/1234
$ git checkout stage
$ git merge --no-ff hot-fix/1234
$ git checkout qa
$ git merge --no-ff hot-fix/1234
$ git checkout develop
$ git merge --no-ff hot-fix/1234

However, depending on the length of the milestones, it's possible that sufficient changes have been made in the pending release that the problem found in production has already been rectified, or the functionality surrounding the issue has been modified to a point where the problem no longer exists, or has been altered completely.

Finally, once the hot-fix has been applied to all the relevant branches it can now be removed.

$ git branch -d hot-fix/1234
$ git push origin :hot-fix/1234

If you find that there are numerous bugs in your production environment this can be attributed to insufficient details at the requirements stage of the project, or an inefficient QA process. Keep in mind that the QA process is only as good as the initial criteria, so validating the specification for a project is key to it's success.

It's also worth noting that any developer who creates a "temporary" branch should remain responsible for it, as they are the most likely candidates to know the status of the branch.