持续集成

-- 几个月前的学习笔记,懒得再翻译回来了 Continuous Integration Continuous Integration Purpose & Main Goals Enviroment Infomation Configuring Env Path Installing JDK 1.8 Install Nexus Configuring iptables Verify Nexus service by setting up a Maven project Install Maven on server side (later will be used by Jenkins) Install GitLab Enable SSH connection using GitLab without password Install Jenkins Setup automated build in Jenkins with Gitlab’s Web Hook feature Setup automated deploy after build in Jenkins Install Git server(Optional) Purpose & Main Goals Automatically build Expose problems earlier. Common module

【持续集成相关工具集】： CI-Server(Jenkins/Hudson.....) 代码管理工具（SVN/git...) java框架（maven) 覆盖率工具（c++:gcov java:maven cobertura插件） 静态扫描插件（jenkins插件） 覆盖率报表合并工具 jenkins二次开发api apache +php +codeiginter 配置 mysql +python 用来管理数据库 python-dev 下载 链接 ........... 笔者将来会专门在持续集成板块介绍相关的工具集合 【安装Jenkins配置启动】： apache-tomcat-6.0.37-src.tar.gz + jenkins.1.556.war 自己搜索下吧 tomcat/bin下全部chmod +x ./* 把jenkins.war 拷贝到 tomcat/webapps下 启动tomcat/bin 下startup.sh 查看8080端口是否启动 浏览吧： http://192.168.1.xxx:8080/jenkins 若想从局域网别的机器访问，则修改tomcatxxx/cong/server.xml Host name="xxx.xxx.xxx.xxx" Engin name="xxx.xxx.xxx.xxx" 同时设置防火墙 (局域网其他机器打不开时可以试试)

Hudson 持续集成 概述 IP:192.168.4.221 8G 内存（Hudson 多个工程在同时构建的情况下比较耗内存） 环境：CentOS 6.6、JDK7 Hudson 不需要用到数据库 Hudson 只是一个持续集成服务器（持续集成工具），要想搭建一套完整的持续集成管理平台， 还需要用到前面课程中所讲到的 SVN、Maven、Sonar 等工具，按需求整合则可。 1、 安装 JDK 并配置环境变量 JAVA_HOME=/usr/local/java/jdk1.7.0_72 2、 Maven 本地仓库的安装（使用 Maven 作为项目构建与管理工具）： 下载 maven-3.0.5 （注意：建议不要下载 3.1 或更高版本的 Maven，因为与 Hudson 进行集成时会有问题，之前有遇到过）： # wget http://mirrors.hust.edu.cn/apache/maven/maven-3/3.0.5/binaries/apache-maven3.0.5-bin.tar.gz 解压： # tar -zxvf apache-maven-3.0.5-bin.tar.gz # mv apache-maven-3.0.5 maven-3.0.5 配置 Maven 环境变量： # vi /etc/profile ## maven env export MAVEN

持续集成与持续交付是软件开发和交付中的实践。我们项目中一直在践行持续集成（CI：Continuous Integration）；持续交付（CD：Continuous Delivery）未能达到理想状态，只能实践一部分。这篇文章用于总结CI/CD的实践。 持续集成 什么是持续集成？ 软件开发中，集成是一个很可能发生未知错误的过程。持续集成是一种软件开发实践，希望团队中的成员频繁提交代码到代码仓库，且每次提交都能通过自动化测试进行验证，从而使问题尽早暴露和解决。 持续集成的好处是什么？ 持续集成可以使问题尽早暴露，从而也降低了解决问题的难度，正如老马所说，持续集成无法消除bug，但却能大大降低修复的难度和时间。 如何做到持续集成？ 首先，持续集成需要： 1. 单一的代码仓库，团队成员都像该仓库提交代码； 2. 自动化构建且构建过程需要包含自动化测试； 3. 有单独的集成机器用于构建； 4. 保证构建速度不要太慢（曾经有一个项目构建需要20分钟，就会很痛苦）； 5. 在类产品环境进行测试； 6. 能够方便获取最新的可执行程序； 7. 可视化，大家都能看到构建过程及结果； 8. 自动化部署。 其次，我们通过以下步骤进行持续集成： 1. 程序员将代码下载到本地，并在完成修改后提交代码； 2. CI服务器监测代码库，并在有提交时自动触发； 3. CI服务器对代码进行构建，运行单元测试和集成测试

持续集成（Continuous integrationI） 是一种软件工程流程，是将所有软件工程师对于软件的工作副本持续集成到共享主线（mainline）的一种举措。 目的就是让产品可以快速迭代，同时还能保持高质量。 核心措施是代码集成到主干之前，必须通过自动化测试。只要有一个测试用例失败，就不能集成。 持续交付 (Continuous delivery) 频繁地将软件的新版本，交付给质量团队或者用户，以供评审。如果评审通过，代码就进入生产阶段。 可以看作是持续集成的下一步，它强调的是不管版本怎么更新，软件是随时随地可以交付的。 持续部署(continuous deployment) 是持续交付的下一步，指的是代码通过评审以后，自动部署到生产环境。 目标是代码在任何时刻都是可部署的，可以进入生产阶段。 前提是能自动化完成测试、构建、部署等步骤。 来源：博客园 作者： tongyishu 链接：https://www.cnblogs.com/tongyishu/p/11682104.html

系列目录 前面章节中我们讲到了Sonarqube的使用,其实Sonarqube获取msbuild结果主要是执行三个命令,开始标记,执行msbuild,结束标记,这些都是命令,是非常容易集成到我们ci流程中的,但是使用这种方式最为简单,但是Sonarqube插件与jenkins集成的更好,我们可以通过jenkins页面看到构建结果是否成功,以及可以通过链接轻松地跳到Sonarqube web管理界面.前面章节我们介绍了如何在自由式任务中使用sonarqube插件,这里我们讲下如何在pipeline中使用sonarqube插件. 还是直接先上代码 node { def sqScannerMsBuildHome = tool 'defaultSonarforMsbuild' stage('SonarQube analysis') { withSonarQubeEnv('defaultSonarserver') { echo "\"默认地址是:${sqScannerMsBuildHome}\"" bat "\"${sqScannerMsBuildHome}\\SonarQube.Scanner.MSBuild.exe\" begin /k:jenkinstest /n:jenkinstest /v:110.0 /d:sonar.host.url=http://localhost:9000"

系列目录 有的童鞋可能已经发现,PipeLine项目与自由式项目相比,可配置的项少了很多,比如说环境变量定义,所有步骤完成后执行动作,拉git代码库等.其实这些功能并没有缺,而是配置的方式不一样了,以前是通过图形化界面配置,虽然直观简便,但是功能不能包罗万像,对于一些复杂的项目显得捉襟见肘,而Jenkins PipeLine使用代码配置功能更加强大.以后的章节中我们会介绍常用的配置如何通过PipeLine里的Groovy脚本来实现. 前面讲参数化构建的时候已经讲到对于复杂的构建把一些重复的,常用的代码做成变量的重要性,这里讲解如何通过PipeLine方式定义项目级别的参数以及环境变量. 首先需要说明的是,节点级别和全局级别以及文件参数变量的配置在PipeLine里依然有效,读取的方式也一样,只是会有一些小坑,这里也会介绍 PipeLine中可以定义变量和环境变量,下面分别介绍如何定义变量和环境变更. PipeLine中定义变量非常简单,只需要使用 def 变量名=变量值的形式即可 看如下PipeLine代码(大家自己创建项目) node { def hello = "world" stage ( "echo" ){ bat "echo $hello" } } 以上脚本中我们先是定义了一个名为 hello 的变量,然后通过 $变量名 方式获取到它,然后把它打印到控制台.

系列目录 Activity界面主要是对多次构建管理界面,主要是帮助管理员快速了解项目每次构建与以往构建相比问题是增加了还是减少了等指标.由于目前我们仅进行了一次构建,因此没有对比数据,我们再对测试项目进行一次构建. 构建代码如下 SonarScanner.MSBuild.exe begin /k:"mygetdata" /v:"2.0" MSBuild.exe /t:Rebuild SonarScanner.MSBuild.exe end 与前一次构建相比,这里仅仅是把版本号从1.0升到2.0,其它的没有变化. 以上命令在cmd里执行即可,需要说明的是以上构建没有指定项目名,因此需要在项目的sln或者csproj文件所在的目录下执行. 需要注意的是,两个构建只要key相同,就会被认为是同一个项目的构建. 构建完以后,我们把标签切换到 overview 标签,可以看到如下图示界面 可以看到右连连新增加了黄色高亮的统计,这个统计是相对于前一次构建新增bug数量等信息的统计 我们再把页面切换到Activity界面.可以看到这个页面内容丰富起来了. 图标里的线代一次构建.鼠标放到线上便可以看到这次构建的综合信息.如果构建特别多,我们还可以根据日期来过滤,把范围锁定到更小的功范围内. Issue界面是管理员管理问题细节的一个重要界面.管理员可以在这个界面根据问题等级,问题解决状态来查看问题

想在公司的新项目上使用k8s，那么持续集成和发布就是必须的了，这里写一下之前在部署的时候遇到的问题，分离一个阿里云特别有帮助的文档 https://help.aliyun.com/document_detail/106712.html?spm=a2c4g.11186623.6.813.626e4330lQtSFi 1、使用jnlp-slave镜像进行与jenkins-master的连接，但是jenkins一直卡在“doesn't have label”的提示上 　　之前同事们一直使用的SSH进行git clone的操作，但是我这次的操作即使是拷贝了公钥也没有用，最后使用http的方式进行的 3、使用kaniko进行镜像上传失败 　首先，/root/.docker/config.json如果没有则需要先登录，打开config.json就会看到用用户具有哪些docker库的权限，然后再使用这个配置文件生成一个secret给kaniko的容器挂载 4、在使用kubectl镜像进行部署的时候报no funcion kubernetesdeploy，而且装了kubernetes continous deploy也没有用 　我遇到这个问题的时候使用的是jenkins官方的镜像，然后手动安装的kubernetes continous deploy，但是我使用了阿里云文档里的jenkins镜像后

1、先配置好build.xml文件 如果持续集成，必须要按照以下文件配置 <?xml version="1.0" encoding="UTF-8"?> <project name="ant-jmeter-test" default="run" basedir="."> <tstamp> <format property="time" pattern="yyyyMMddhhmm" /> </tstamp> <property environment="env"/> <property name="ReportName" value="TestReport" /> <!-- 需要改成自己本地的 Jmeter 目录--> <property name="jmeter.home" value="D:\apache-jmeter-4.0" /> <!-- jmeter生成jtl、html格式的结果报告的路径--> <property name="jmeter.result.dir" value="${env.WORKSPACE}/results/${env.BUILD_ID}" /> <!-- 生成的报告的前缀--> <property name="jmeter.result.jtlName" value="${jmeter.result.dir}/${ReportName}.jtl" />