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

在本系列文章中，我们将探讨在容器时代如何在基于Docker的环境中创建连贯的工作流程和流水线来简化大规模项目的部署。另外，我们还将详细介绍如何利用Docker和Rancher自动化处理这些工作流。

在上文《将构建环境容器化》中，我们开始了构建持续集成流水线的第一步工作——构建系统（Build System）的创建。我们分析了【Build】这一环节的常见的三大挑战——依赖管理、管理环境依赖、复杂项目的漫长构建时间，以及如何用传统工具与方法解决这些问题。接着，我们分享了如何利用Docker创建容器化的构建系统以更轻松地解决那些传统挑战，包括如何将构建环境容器化、如何使用Docker打包应用程序、如何使用Docker Compose创建构建环境，最终创造一个可重复的、集中管理的、良好隔离的、并行化的构建系统。

现在我们已经将【Build】系统创建好了，那么在本文中，我们将为示例的应用创建一个持续集成流水线。这样我们既可以确保遵循最佳实践，又可以确保彼此冲突的那些变化不会相互作用、引发问题。不过，在我们为代码建立持续集成之前，我们先花一点时间讨论如何将代码划分到分支中。

分支模式

在我们实现持续集成流水线的自动化时，一个需要考虑的重点是团队遵循的开发模式。这个模式通常由团队如何使用版本控制系统来决定。由于我们的应用程序托管在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创建CI流水线

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