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

 

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

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配置和一堆环境的配置。关于如何配置可持续部署环境，能够看一下这篇文章：

http://www.javashuo.com/article/p-nxvueyue-hx.html