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

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

 

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

 

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

1.png


分支模式


在我们实现持续集成流水线的自动化时,一个需要考虑的重点是团队遵循的开发模式。这个模式通常由团队如何使用版本控制系统来决定。由于我们的应用程序托管在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命令后,它将创建一个开发分支(如果原先没有开发分支的话),并将其检出作为工作分支。

2.png

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

3.png

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

4.png

需要注意的是,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服务器上安装下面的插件和依赖项:

相关文章
相关标签/搜索