DevOps之持续构建

1、前言：

CI、CD是敏捷开发中重要的一环。CI即Continuous integration，持续构建的意思，CD即Continuous Deploy，持续部署的意思。在开发或者测试环境中，将构建和发布做成自动化是非常节约人力、减少人为失误从而提升开发效率的一项工作。
本次例子将会展现从传统开发到敏捷开发的过程。

A、现开发流程：

开发写完代码→提交到代码仓库→测试下载代码打包→部署到测试环境测试→测试完成提交到部署分支→运维下载代码打包→部署到灰度环境→准备测试上线。

总结：

传统的开发方式，每个人干着重复的事情，哪一步出现问题，回滚麻烦。

B、改善后的开发流程：

开发写完代码→jenkins自动打包、ansible自动部署→测试直接开始测试→没有问题，运维准备上线。

总结：

可以看到，开发只负责写代码，测试只负责功能测试，运维只负责手动上线。减少了很多人为的工作，自动化使团队的工作效率大大提高，从而实现DevOps。
这里用到的技术：

jenkins：持续构建代码
ansible：批量部署
sonar：代码测试

这里先从jenkins开始讲起。

2、jenkins的部署

系统	centos7
配置	4c16g
目录	/app/jenkins

开始安装：

mkdir -p /app/jenkins
cd /app/jenkins/
从官网下载war包
wget http://mirrors.jenkins.io/war-stable/latest/jenkins.war

jenkins依赖java环境，建议使用java8.
jdk的安装参考我devops的其他文档

docker安装jenkins注意点：

这里我没有用容器来安装jenkins。
说说容器启动jenkins的优点和缺点
优点：java环境变量、jenkins的war包等全封装在image里，非常方便和快捷的就搭建了jenkins，也符合容器build once、run anyway的特点
缺点和解决：

(1)
Q:用docker跑jenkins，构建完成后jenkins无法执行一些指令 shell、ansible等
A：docker启动jenkins，用户是jenkins，起在容器里面，shell是/bin/bash
所以诸如ansible这些在/usr/bin下面的指令没办法运行。解决方法：以root的角色运行jenkins 容器，插件开元，风险较大
(2)
Q:docker起jenkins时，jenkins的时间与宿主机的时间相差8小时
A：是因为jenkins的jvm在localtime里面获取时间，解决方法：-v /etc/localtime:/etc/localtime
dockerfile也要注意时区

由于现公司没有上k8s，所以基础服务也没有使用docker的必要。这里还是直接在宿主机上搭建服务。

继续安装

默认jenkisn的home目录是/root/.jenkins
我这里改变路径

写入环境变量：
vim /etc/profile

###jenkins
export JENKINS_HOME=/app/jenkins/jenkins

source /etc/profile
启动jenkins：
nohup java -jar jenkins.war --httpPort=5303 > /var/log/jenkins.log 2>&1 &

jenkins的web的url
http://ip:5303

配置jenkins

浏览器输入url，看到如下图：

jekins.jpg

按照提示，修改默认密码

继续
如果服务器ping不通谷歌，会出现离线的问题：
离线解决：
vim /root/.jenkins/updates/default.json
把www.google.com换成www.baidu.com

重启服务

安装推荐插件

创建账号，jenkins部署完成！

3、jenkins的使用

登陆，点新建任务，创建一个自由风格的软件项目

构建项目.jpg

jenkins持续构建的本质就是将拉代码、打包、部署集成在一起。所以必填的项目有：
源码管理，负责拉取代码。红色的部分可以添加git的权限

源码管理.jpg

代码拉下来后就是构建：
我这里是java项目，用的mvn

构建代码.jpg

完成后点击开始构建。
构建完成后，会发现jenkins的家目录下面的workspace的里面会出现新建的工程。工程的目录下面有刚打的包。打完包后，后面就可以根据包来实现自动化了。下一篇文章会讲如何结合ansible做持续部署。