持续集成与持续部署宝典Part 2：创建持续集成流水线

在我们实现持续集成流水线的自动化时，一个需要考虑的重点是团队遵循的开发模式。这个模式通常由团队如何使用版本控制系统来决定。由于我们的应用程序托管在git仓库中，因此我们使用git-flow模型进行分支、版本化以及发布我们的应用程序。它是基于git仓库上最常用的模型之一。简而言之，该模型的思想是维护两个分支：一个开发（者）分支，一个主分支。每当我们想开发新功能时，就会从开发分支创建出新的分支，并在功能开发完成时，将它合并回来。所有功能分支都有开发人员单独管理。一旦将代码提交到开发分支，CI服务器将负责确保分支始终能够编译、通过自动化测试并且可以在服务器上进行QA测试和评审。当我们准备进行发布时，可以从开发分支创建一个发布，并将其合并到主分支中。被发布的特定的commit hash也会使用版本号进行标记。被标记好的发布项接着就可以被推送到Staging/Beta或者生产环境中。

下面我们将使用git-flow工具来帮助管理我们的git分支。安装git-flow请参考这里的说明：https://github.com/nvie/gitflow/wiki/Installation。安装好git-flow，你就可以通过下面所示的git flow init命令配置你的仓库。Git flow会问一些问题，我们建议你使用默认的设置即可。执行过git-flow命令后，它将创建一个开发分支（如果原先没有开发分支的话），并将其检出作为工作分支。

现在，我们使用git flow输入git flow feature start [feature-name]命令创建一个新功能。通常做法是用ticket/issue id用作功能的名称。比如，如果你使用的是Jira处理ticket，那么ticket id（例如，MSP-123）就可以作为功能名称。你还会发现当你使用git-flow创建新功能时，它将自动切换到功能分支。

到了这一步，你可以去完成该功能所需的全部内容，然后运行自动化测试套件以确保一切正常运转。一旦你准备好发布工作，只需告诉git-flow去完成这一功能即可。根据你对该功能的实际需要，你想要进行多少次提交都可以。在我的这个示例中，从我们的目的来看，我们只需更新README文件，并通过输入“git flow feature finish MSP-123”来完成更新。

需要注意的是，git flow合并了开发分支的功能，删除了功能分支并且返回到了开发分支。此时，你可以将开发分支推送到远程仓库（git push origin develop:develop）。当你提交了开发分支，CI服务器就会接管持续集成流水线。对于更大的团队来说，一种更合适的模式是在完成功能之前将功能分支推送到远程，让它们经评审（review）后，使用pull request来合并到开发分支中。

在这一节，我们假设你已启动并运行了一个Jenkins集群。如果没有的话，你可以在这里使用官方的Jenkins镜像：https://hub.docker.com/_/jenkins/，在这里可以看到更多关于建立可扩展Jenkins集群的内容：https://rancher.com/deploying-a-scalable-jenkins-cluster-with-docker-and-rancher/。在你有了运行的Jenkins集群后，我们需要在Jenkins服务器上安装下面的插件和依赖项：