DevOps实践－从0到1搭建敏捷团队的持续集成环境

2019独角兽企业重金招聘Python工程师标准>>>

 

什么是持续集成，持续部署，持续交付

1. 持续集成，是指将代码合并到同一分支，通过编译，测试，打包之后，将程序保存到版本库中的过程。
2. 持续部署，是指将目标代码自动地，定时地发布到目标环境上。
3. 持续交付，是指自动地，定时地将最终产品交付给用户使用。

     简单的说，持续集成就像是软件行业的“工业4.0”版本，通过一系列自动化的工具，将开发，测试，部署，发布的流程定时化，自动化，这样可以有效地，及时地发现开发过程中的问题，及早交付产品，快速地试错，得到快速的反馈，在激烈的产品竞争中获取时间上的优势。

Git 分支模型

一图胜千言，下面我们一幅图来介绍一下Git的分支模型，以及在持续集成中的作用。这里我简单说一下Git的分支开发模型，如果想要更详细了解里面的操作，可以参考一下这篇文章：http://blog.jobbole.com/81196/

这里我们先简单介绍一下这几个分支：

develop:开发分支，一般开发都在上面进行

feature: 特性分支，主要是开发一些新特性的时候会创建，等到开发完了之后，合并到develop分支上，然后就会删除。

release: 等到develop上面的特性开发得差不多了，就会创建一个release分支，这个分支上面只是用来修改bug,等到稳定之后，就切换到master上面。

master: master分支上面的Head永远指向的是稳定的，可随时发布的状态。

hotfixes:如果线上出现了任何问题，那么就从master分支上检出一个hotfixes分支，修复bug之后，把代码合并到master和develop分支上。

为什么这里要有这样的一个分支模型出来呢？我理解是软件开发团队化，规划化所导致的必然结果，这里就急需要有一种精益求精的开发模型来适应这种变化，有点像丰田汽车的“精益生产”，这里我们把他暂时称为“精益开发”。

但是，对于一些敏捷团队来说，本身规模就达不到这种量级，所以，更多的时候，我们可能只用到了其中的 develop和master分支。在我们接下来的持续集成中，我们将通过利用jenkins作为持续集成工具，利用develop分支，搭建一个前端项目的可持续集成，持续部署，持续交互的基本模型。

持续集成

搭建Jenkins 和 Github环境，具体的搭建环节可以参考以下的链接。

http://www.jianshu.com/p/22b7860b4e81

网上的教程大多是教如何搭建一个持续集成的环境，实现代码的编译，测试，打包，但是对于一个前端开发项目来说，在开发中，我们更需要的是拥有“持续部署”，实现可以看到实时反馈效果的功能，接下来我们将结合tomcat,利用一些操作系统上的命令，来实现一个“单机版”的持续部署前端环境。

持续部署

 

首先，我们假设你本机已经安装好了Jenkins,也根据上述的步骤创建了一个Github的前端项目。那我们现在碰到的一个问题是，如何将编译好的项目部署到服务器上面。目前了解到的方法是jenkins集成了一些插件，可以直接将编译后的项目直接部署到服务器上面，例如Tomcat。 这方面已经做的很成熟了。

由于现在很多项目是前后端分离的，前后端交互也是通过接口的形式交互，部署也是单独部署。我在实践中发现，对于那些对服务器有自主权的敏捷团队，可以将jenkins的编译目录和服务器对应的目录进行链接，这样集成后的代码就可以直接映射到服务器对应的目录下，这样内部的开发团队就可以通过服务器直接访问到集成后的项目了。

这里我只是简单说一下整个流程，整个流程实现起来需要另外写一片文章详细叙说，里面涉及到服务器设置，jenkins配置和一堆环境的配置。关于如何配置可持续部署环境，可以看一下这篇文章：

https://my.oschina.net/u/2562868/blog/1552610

 

 

                                                                                                                    

 

 

 

 

 

 

 

转载于:https://my.oschina.net/u/2562868/blog/1547275