第1章 引入

1.1 开发写代码的演变

l 一个开发单打独斗，撸代码，开发网站，自由自在；

l 多个开发同时开发一个网站，同时改一份代码。但是同时改一个文件会导致冲突。

l 采用分支结构，每天上班第一件事克隆代码，下班前最后一件事合并代码。（上一篇文章有写到）

l 好景不长，开发越来越多，代码文件越来越多。每天下班前合并代码时，发现很多合并失败的文件。最后每天加班3小时人工合并代码。

l 解决方法：将代码合并的周期缩短，以前一天，现在一小时，半小时。。。。。

l 随时随地将代码合并，这种方法叫做持续集成。

1.1.1 持续集成

持续集成（英语：Continuous integration，简称CI）

持续集成指的是，频繁地（一天多次）将代码集成到主干。

它的好处主要有两个：

Ø 快速发现错误。每完成一点更新，就集成到主干，可以快速发现错误，定位错误也比较容易。

Ø 防止分支大幅偏离主干。如果不是经常集成，主干又在不断更新，会导致以后集成的难度变大，甚至难以集成。

1.2 运维上线代码的演变

l 初级运维很苦逼，刚开始开发每天合并一次代码，然后运维把代码pull下来测试就可以了。

l 但是，后来开发引进持续集成方法论，开发们都“弹冠相庆”。

l 运维感觉好苦逼，一天到晚不停的测试代码。

l 运维就想有没有办法自动化？

l 借助一个自动化的部署工具，叫做JENKINS。

l 开发上传自己的代码到GITLAB，gitlab发消息通知Jenkins，随后Jenkins从仓库拉取代码。最后全自动部署到测试服务器进行相关测试，并将测试结果通知运维和开发。

l 还有偷懒的方法，直接把这个工具交给开发使用，从此就可以高枕无忧了。

l 这种自动测试的方法叫做持续交付。

1.2.1 持续交付

持续交付（英语：Continuous delivery，简称CD），指的是：频繁地将软件的新版本，交付给质量团队或者用户，以供评审。如果评审通过，代码就进入生产阶段。

持续交付可以看作持续集成的下一步。它强调的是，不管怎么更新，软件是随时随地可以交付的。

l 代码测试通过了，该到生产环境部署了；

l 部署时要么成功，要么失败回滚；

l 可以使用自动化部署工具或批量管理工具（ansible）

l 这里有个方法叫做持续部署。

1.2.2 持续部署

持续部署（英语：Continuous Deployment，缩写为 CD）是持续交付的下一步，指的是代码通过评审以后，自动部署到生产环境。

持续部署的目标是，代码在如何时刻都是可部署的，可以进入生产阶段。

1.3 Jenkins介绍

Jenkins是一个用Java编写的开源的持续集成工具。在与Oracle发生争执后，项目从Hudson项目独立。

Jenkins提供了软件开发的持续集成服务。它运行在Servlet容器中（例如Apache Tomcat）。它支持软件配置管理（SCM）工具（包括AccuRev SCM、CVS、Subversion、Git、Perforce、Clearcase和RTC），可以执行基于Apache Ant和Apache Maven的项目，以及任意的Shell脚本和Windows批处理命令。Jenkins的主要开发者是川口耕介。Jenkins是在MIT许可证下发布的自由软件。

第2章 安装Jenkins

2.1 安装Jenkins

2.1.1 环境说明

2.1.2 软件下载

常规安装方法：使用RPM包安装

RPM包下载地址：

官方仓库  https://pkg.jenkins.io/redhat-stable/

清华大学开源软件镜像站  https://mirrors.tuna.tsinghua.edu.cn/jenkins/redhat/

下载相应的数据包即可，我这里使用的是jenkins-2.73.1-1.1.noarch.rpm

2.1.3 web界面安装

浏览器访问: http://10.0.0.64:8080

输入授权密码，然后点击下一步

稍等一会来到安装插件选择的页面，将此页面关闭，在安装完成Jenkins后安装插件。

关闭安装插件选择后，选择开始使用Jenkins

安装完成，显示界面

安装Jenkins插件

系统管理 >> 管理插件

选择自己需要的插件进行安装即可，也可选择全部安装。

至此Jenkins安装完成

2.2 Jenkins配置

2.2.1 配置jenkins并发执行数量，提高执行效率 

系统管理 >> 系统设置 >> Maven项目配置

2.2.2 设置邮件，能够在测试完成后，主动发邮件告知测试情况

    系统管理 >> 系统设置 >> Jenkins Location

向下拉，找到邮件通知，配置邮件的smtp信息

配置完成后点击 Test configuration 进行测试，测试成功后，点击保存

第3章 Jenkins使用

3.1 创建一个新的任务

创建一个新的任务

输入项目的名称，选择构建自由风格的软件

3.1.1 将Jenkins与gitlab联合

gitlab的详细安装方法参照：版本控制系统

创建公钥和私钥

在gitlab中添加公钥id_rsa.pub

在jenkins中添加私钥id_rsa

在首页中，点击项目名称的下拉监听

选择源码管理，先将gitlab的项目地址复制过来

选择SSH密钥和证书，然后选择直接输入，将私钥复制到下框中即可

添加完成后，点击保存

  选择刚才创建的证书，完成后，选择构建

选择构建——拉到最底部，选择使用shell脚本

脚本内容

选择构建后的操作，让每次构建完成后都将结果发送给管理员

3.1.2 测试手动集成

回到主页，点击右侧的按钮进行测试

部署完成

查看部署日志

查看部署结果

3.1.3 自动测试（gitlab主动通知Jenkins测试）

该功能会使用到一个插件 gitlab plugin

配置gitlab认证

添加一个新的凭证

从gitlab的设置中将 token复制过来

将复制的token粘贴到api token中，点ok

在系统配置中找到Gitlab 将信息进行填写，Credentials 选择刚刚创建对的即可

打开项目，编辑项目的构建触发器

在gitlab上配置连接jenkins ，将Jenkins的Secret token 与Build URL 复制到gitlab中

保存之前先进程测试，测试成功后进行保存

在gitlab进行上传文件，可以测试。

在日志中显示是 Started by GitLab push by Administrator 即表示自动集成成功

第4章 代码上线方案

4.1 早期手动部署代码

l 纯手动scp上传代码。

l 纯手动登陆，Git pull 或者SVN update。

l 纯手动xftp上传代码。

l 开发发送压缩包，rz上传，解压部署代码。

4.1.1 缺点：

l 全程运维参与，占用大量时间。

l 如果节点多，上线速度慢。

l 人为失误多，目录管理混乱。

l 回滚不及时，或者难以回退。

上线方案示意图

4.2 合理化上线方案

1、开发人员需在个人电脑搭建LAMP环境测试开发好的网站代码，并且在办公室或 IDC机房的测试环境测试通过，最好有专职测试人员。

2、程序代码上线要规定时间，例如：三天上线一次，如网站需经常更新可每天下午 17点上线，这个看网站业务性质而定，原则就是影响用户体验最小。

3、代码上线之前需备份，网站程序出了问题方便回退，另外，从上线技巧上讲，上传代码时尽可能先传到服务器网站临时目录，传完整后一步mv过去，或者通过In做软链接— 线上更新代码的思路。如果严格更新，把应用服务器从集群节点平滑下线，然后更新。

4、尽量由运维人员管理上线，对于代码的功能性，开发人员更在意，而对于代码的性 能优化和上线后服务器的稳定，运维更在意服务器的稳定，因此，如果网站宕机问题归运维管，就要让运维上线，这样更规范科学。否则，开发随意更新，出了问题运维负责，这样就错了，运维永远无法抬头。

4.3 大型企业上线制度和流程

JAVA代码环境，上线时，有数台机器同时需要更新或者分批更新

1. 本地开发人员取svn代码。当天上线提交到trunk，否则，长期项目单开分支开发，然后在合并主线(trunk)

2. 办公内网开发测试时，由开发人员或配置管理员通过部署平台jenkins实现统一部署，（即在部署平台上控制开发机器从svn取代码，编译，打包，发布到开发机，包名如idc_dep.war）.

3. 开发人员通知或和测试人员一起测试程序，没有问题后，由配置管理员打上新的tag标记。这里要注意，不同环境的配置文件是随代码同时发布的。

4. 配置管理员，根据上一步的tag标记，checkout出上线代码，并配置好IDC测试环境的所有配置，执行编译，打包(mvn,ant)(php不需要打包)，然后发布到IDC内的统一分发服务器。

5. 配置管理员或SA上线人员，把分发的程序代码内容推送到相关测试服务器（包名如idc_test.war），然后通知开发及测试人员进行测试。如果有问题向上回退，继续修改。

6. 如果IDC测试没有问题，继续打好tag标记，此时，配置管理员，根据上步的tag标记，checkout出测试好的代码，并配置好IDC正式环境的所有配置，执行编译，打包(mvn,ant)(php不需要打包)，然后发布到IDC内的统一分发服务器主机，准备批量发布。

7. 配置管理员或SA上线人员，把分发的内容推送到相关正式服务器（包名如idc_product.war）,然后通知开发及测试人员进行测试。如果有问题直接发布回滚指令。

IDC正式上线的过程对于JAVA程序，可以是AB组分组上线的思路，即平滑下线一半的服务器，然后发布更新代码，重启测试，无问题后，挂上更新后的服务器，同时再平滑下线另一半的服务器，然后发布更新代码测试（或者直接发布后，重启，挂上线）

4.3.1 php程序代码上线的具体方案

  对于PHP上线方法：发布代码时（也需要测试流程）可以直接发布到正式线临时目录 ，然后mv或更改link的方式发布到正式上线目录 ，不需要重启http服务。这是新朗，赶集的上线方案。

4.3.2 JAVA程序代码上线的具体方案

 对于java上线方法:较大公司需要分组平滑上线（如从负载均衡器上摘掉一半的服务器），发布代码后，重启服务器测试，没问题后，挂上上好线的一半，再下另外一半。如果前端有DNS智能解析，上线还可以分地区上线若干服务器，逐渐普及到全国的服务器，这个被称为“灰度发布”，在后面门户网站上线的知识里我们在讲解。

4.3.3 代码上线解决方案注意事项

1. 上线的流程里，办公室测试环境-->IDC测试环境-->正式生产环境，所有环境中的所有软件均应版本统一，其次尽量单一，否则将后患无穷，开发测试成功，IDC测试就可能有问题（如:操作系统，web服务器，jdk,php,tomcat,resin等版本）

2. 开发团队小组办公内部测试环境测试（该测试环境属于开发小组维护，或定时自动更新代码），代码有问题返回给某开发人员重新开发。

3. 有专门的测试工程师，程序有问题直接返回给开发人员（此时返回的一般为程序的BUG，称为BUG库），无问题进行IDC测试

4. IDC测试由测试人员和运维人员参与，叫IDCtest,进行程序的压力测试，有问题直接返回给开发人员，无问题进行线上环境上线。

5. 数台服务器代码分发上线方案举例（JAVA程序）

  　　 A:假设同业务服务器有6台，将服务器分为A,B两组，A组三台，B组三台，先对A组进行从负载均衡器上平滑下线，B组正常提供服务，避免服务器因上线影响业务。

  　　 B:下线过程是通过脚本将A组服务器从RS池（LVS,NGINX,HAPROXY,F5等均有平滑方案）中踢出，避免负裁均衡器将请求发送给A组服务器（此时的时间应该为网站流量少时，一般为晚上）

  　　 C:将代码分发到A组服务器的站点目录下，对A组服务器上线并重启服务，并由专业的测试人员进行访问测试，测试成功后，挂上A组的服务器，同时下线B组服务器，B组代码上线操作测试等和A组相同，期间也要观察上线提供服务的服务器状况，有问题及时回滚。

6. 特别说明：如果是PHP程序，则上线可以简单化，直接将上线代码（最好全量）发布到所有上线服务器的特定目录后，分发完成后，一次性mv或ln到站点目录，当然测试也是少不了的。测试除了人员测试外，还有各种测试脚本测试各个相关业务接口。