持续集成

持续部署，并不简单！ https://coolshell.cn/articles/7657.html 2012年06月25日 马基雅弗利 评论 46 条评论 36,619 人阅读 【 感谢 @常新居士 投递此文 】 这几年，持续集成随着敏捷在国内的推广而持续走热，与之相伴的持续部署也一直备受关注。 自前两年，持续交付这个延续性概念又闯进了国内IT圈，慢慢开始在社区和会议中展露头角。许多不明真相的群众跟风哭着喊着要“上”，而许多前CI的半吊子玩家换件衣服就接着干，有的甚至衣服都来不及换…… 。国内的这些土财主如果不巧请了某些所谓的战略家，除了建了一堆持续集成环境，以及每天嚷嚷着要这个要那个，混乱的状况在根本上没有得到改善。本文无意费力探讨持续集成和持续交付的概念，而是打算谈谈对于大型软件企业，以持续集成为基础实现持续部署（交付）时，所要面对的问题以及可行的解决方案。地主老财们，夜黑风正猛，山高路又远，注意脚下…… And God Said, Let there be light: and there wa — GENSIS, Charpter 1, King James 一、起步 先来讲个故事…… 几年前，一对留美的夫妇通过朋友找到我，让我帮忙在国内组建一个开发团队，该团队负责为其开发一款基于社交网络的客户关系管理软件,（暂且称之为项目A）

应用场景： 问题 项目分为app和后台两种，为了保证再同一个环境下面测试，所以不可能链接开发本地服务进行测试，所以需要搭建一个测试环境，供app进行开发测试。这个时候就有一个问题，如果开发新增加功能或者app调试的时候发现问题，这个时候就需要提交新的代码或者修复bug，然后重新发布到测试环境中去。但是后台人员又不能进入Linux服务器中，只能通过Linux运维人员来重新部署，这样的效率就会极低。 方案： 基于这种模式下面的，我们引入了Jenkins工具，通过Jenkins来拉取svn/git代码到服务器中，再Jenkins中编写Linux运行脚本，通过脚本我们就可以对代码进行编译运行，然后重新发布到服务器中运行。后端人员也不需要通知Linux运维人员来执行这个操作，直接再Jenkins的控制台就可以执行了。 实验环境 IP 主机名称 服务 192.168.1.21 master k8s 192.168.1.22 node01 k8s 192.168.1.10 git gitlab 192.168.1.13 jenkins jenkins 总体流程： 在开发机开发代码后提交到gitlab 之后通过webhook插件触发jenkins进行构建，jenkins将代码打成docker镜像，push到docker-registry 之后将在k8s-master上执行rc、service的创建

一、配置jar包 https://pan.baidu.com/s/1e6su8eOYy5GXKxvpet4uxw 将jar包放置E:\apache-ant-1.9.13\lib（activation.jar、mail.jar） 注：自己的本地ant路径 二、修改build build.xml 文件内容如下，copy一份进去，相关地址需要修改 <?xml version="1.0" encoding="UTF-8"?> <project name="ant-jmeter-test" default="run" basedir="."> <tstamp> <format property="time" pattern="yyyyMMddhhmm" /> </tstamp> <!-- 需要改成自己本地的 Jmeter 目录--> <property name="jmeter.home" value="F:\apache-jmeter-3.0" /> <!-- 发送给哪些人--> <property name="mail_to" value="zxc1012527160@163.com"/> <!-- 抄送给哪些人，多个用逗号隔开/--> <!--property name="mail_cc" value="++++1@163.com,++++2@163.com"/-->

一、概述 简介 Jenkins 2.x的精髓是Pipeline as Code，那为什么要用Pipeline呢？jenkins1.0也能实现自动化构建，但Pipeline能够将以前project中的配置信息以steps的方式放在一个脚本里，将原本独立运行于单个或者多个节点的任务连接起来，实现单个任务难以完成的复杂流程，形成流水式发布，构建步骤视图化。简单来说，Pipeline适用的场景更广泛，能胜任更复杂的发布流程。举个例子，job构建工作在master节点，自动化测试脚本在slave节点，这时候jenkins1.0就无法同时运行两个节点，而Pipeline可以。 基本概念 Stage: 阶段，一个Pipeline可以划分为若干个Stage，每个Stage代表一组操作。注意，Stage是一个逻辑分组的概念，可以跨多个Node。 Node: 节点，一个Node就是一个Jenkins节点，或者是Master，或者是slave，是执行Step的具体运行期环境。 Step: 步骤，Step是最基本的操作单元，小到创建一个目录，大到构建一个Docker镜像，由各类Jenkins Plugin提供。 语法 Pipeline支持两种语法： Declarative Pipeline （在Pipeline 2.5中引入，结构化方式）和 Scripted Pipeline

1.安装说明 PS:为什么要有安装说明？江边望海在网上找资料的时候发现很多教程是没有交代清楚安装环境的。所以，不清楚他们的教程是否适合我的环境。明确『安装说明』方便网友了解我的配置环境，便于大家深入理解此教程。 虚拟机：VirtualBox4.3.26 操作用户：root 系统环境：centos6.6-x86_64（最小化安装） 软件下载目录：/root/opt ================ 2.预置条件 1.需要JDK1.6+支持；（如果不知道如何安装JDK,请访问我写的《 Centos下安装JDK 》） 2.需要Mysql数据库支持；（虽然SonarQube自带了H2数据库，但是为了方便管理数据推荐使用Mysql数据库） 多说一句：JDK是必须安装的，Mysql数据库并不是必须要安装的，如果公司有Mysql服务器，直接拿来使用就行，江边望海这次就没有安装Mysql直接用公司内网提供的Mysql数据库。 ================ 3.安装 在安装之前，介绍一下SonarQube和SonarQube Runner之间的关系。 SonarQube是服务器端，它主要有两个功能：1.分析源代码；2.因为它内嵌了Apache模块，所以提供Web端的界面访问。 SonarQube Runner是一个利用SonarQube服务端分析代码的命令行工具，可以把它简单理解为客户端。

从7.12版本开始，GitLab CI使用YAML文件(.gitlab-ci.yml)来管理项目配置。该文件存放于项目仓库的根目录，它定义该项目如何构建。 stages stages 用来定义可以被job调用的stages。stages的规范允许有灵活的多级pipelines。stages中元素的顺序决定了对应job的执行顺序： 相同stage的job是并行执行的； 下一个stage的job在前一个stage的job成功完成后才开始执行； 如果.gitlab-ci.yml中没有定义stages，那么stages默认定义为build、test和deploy； 如果一个job没有指定stage，那么这个任务会分配到test stage。 variables variables 用来定义变量，全局变量作用于所有job，也可以在指定的job中定义变量（优先级高于全局变量） 如果在job中想禁用全局定义的变量，可通过 variables: {} 定义一个空的哈希值。 GitLab CI/CD内置变量 variables 变量值 CI_JOB_NAME 对应的job_name GIT_STRATEGY 指定git获取代码的方式（clone,fetch,none） jobs jobs 用来定义了一组作业，其中必须包含 script 语句。 job.stage（默认： test ）

随时随地将代码合并的方法叫做 持续集成 =================================================================== 视频用的10.0.0.11 gitlab 10.0.0.12 Jenkins 安装Jenkins 上传好准备好的rpm包 安装JDK # rpm -ivh jdk-8u121-linux-x64.rpm 测试安装结果 # java -version -------------> java version "1.8.0_121" 安装Jenkins # rpm -ivh jenkins-2.73.3-1.1.noarch.rpm 开机启动 启动服务 它监控的8080端口 # systemctl enable jenkins # systemctl status jenkins # lsof -i :8080 --------->java 19195 jenkins 测试访问 浏览器输入10.0.0.12:8080 安装成功 配置Jenkins 完成后进入需要解锁密码 提示密码路径在这里 默认用户admin # cat /var/lib/jenkins/secrets/initialAdminPassword 3f73d5e052974d96b6eb9bc5fb0f82f2 进入后会联网下载数据

一、什么是持续集成？ （1）Continuous integration（CI） 持续集成是一种软件开发实践，即团队开发成员经常集成他们的工作，通常每个成员至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建（包括编译，发布，自动化测试）来验证，从而尽快地发现集成错误。许多团队发现这个过程可以大大减少集成的问题，让团队能够更快的开发内聚的软件。 （2）没有持续集成 项目做模块集成的时候，发现很多借口都不通==>浪费大量时间 需要手动去编译打包最新的代码==>构建过程不透明 发布代码，上线，基本靠手工==>脚本乱飞 （3）持续集成最佳实践： 维护一个单一的代码库 使构建自动化 执行测试是构建的一部分 集成日志及历史记录 使用统一的依赖包管理库 每天至少集成一次 （4）jenkins介绍 Jenkins 只是一个平台，真正运作的都是插件。这就是jenkins流行的原因，因为jenkins什么插件都有 Hudson 是Jenkins的前身，是基于Java开发的一种持续集成工具，用于监控程序重复的工作，Hudson后来被收购，成为商业版。后来创始人又写了一个 jenkins ，jenkins在功能上远远超过hudson Jenkins官网： https://jenkins.io/ Jenkins下载：http://updates.jenkins-ci.org/

On Debian-based distributions, such as Ubuntu, you can install Jenkins through apt-get. Recent versions are available in an apt repository . Older but stable LTS versions are in this apt repository . You need to have a JDK and JRE installed. openjdk-7-jre and openjdk-7-jdk are suggested. As of 2011-08 gcj is known to be problematic - see https://issues.jenkins-ci.org/browse/JENKINS-743 . Please make sure to back up any current Hudson or Jenkins files you may have. Installation wget -q -O - https://jenkins-ci.org/debian/jenkins-ci.org.key | sudo apt-key add - sudo sh -c 'echo deb http://pkg

一、环境准备 Jenkins: 到官网下载jenkins.war包： http://jenkins-ci.org/ 安装方法有两种： 把下载下来的jenkins.war包放到文件夹下,如C:\jenkins，然后打开命令行窗口并进到该目录下，执行java -jar jenkens.war命令，当提示：“Jenkins is fully up and running”时，表示启动成功，这时在浏览器窗口输入：http://localhost:8080/ 就可到jenkins的首页。 如果有tomcat，把jenkins.war包放在tomcat的webapps文件夹下，启动tomcat时会自动启动jenkins，这时通过http://localhost:8080/jenkins就 可以访问jenkins的首页了。 ANT: 　　　　　　下载ant并配置ANT_HOME，官网： http://ant.apache.org/ 。 　　3、Junit: 　　　　　　下载junit.jar包，没用过的可参考： http://blog.csdn.net/lengyuhong/article/details/5815017 　　4、SVN: 　　　　　　1、用本地硬盘当SVN仓库： http://wenku.baidu.com/view/12b02f6a011ca300a6c39081.html