Jenkins

jenkins构建java项目找不到命令mvn,java的解决方法 参考文章： （1）jenkins构建java项目找不到命令mvn,java的解决方法 （2）https://www.cnblogs.com/weifeng1463/p/9109317.html 备忘一下。 来源： oschina 链接： https://my.oschina.net/u/4363296/blog/4740354

持续集成、持续交付和持续部署 持续集成 Continuous Integration：持续集成，简称CI，是软件开发周期的一种实践，把代码仓库（Gitlab或者Github）、构建工具（如Jenkins）和测试工具（SonarQube）集成在一起，频繁的将代码合并到主干然后自动进行构建和测试。简单来说持续集成就是一个监控版本控制系统中代码变化的工具，当发生变化是可以自动编译和测试以及执行后续自定义动作。 其实这里最关键的是自动化测试，这个是最难的，因为测试涉及内容很多。 持续交付 Continuous Delivery：持续交付，简称CD，是在CI的基础进行了扩展，在CI环节完成了软件构建和测试工作并形成了新的版本，那么接下来就要进行交付，而这里的交付并不是交付到生产环境，而是类生产环境（STAGING），我们可以理解为灰度环境或者预发环境，进而接受部分真实流量的测试。如果没有问题的话则通过手动的方式部署到生产环境。如下图所示： 持续部署 Continuous Deployment：持续部署，简称CD，它是在持续交付的基础上打通最后一公里的工作，就是把手动部署到生产环境的方式升级为自动部署。看下图和上图在最后部署到生产环境中的区别。 总结 持续集成、持续交付和持续部署其目的是减少代码改动到投入生产的所需时间，提早发现风险、减少QA的测试时长、减少运维的人工干预

一.CI，CD，Jenkins的介绍 CI：持续集成(Continuous integration，简称 CI)，在传统的软件开发环境中，有集成，但是没有持续集成这种说法，长时间的分支与主干脱离，导致分支与主干可能存在较大偏差，在集成代码的时候可能需要花费数小时更久的时间来修复代码，以便最终将代码集成主干(俗称"集成地狱"或"集成灾难")；而CI旨在鼓励团队成员进行频繁集成（例如每小时或至少每天一次 ） 来避免这种情况的出现，通过自动检测、拉取、构建和（在大多数情况下）进行单元测试的过程，来保障代码的质量可以进行下一步的使用，这也是持续集成的目的，CI是属于开发人员的自动化流程。 CD：持续交付(Continuous Delivery)和持续部署(Continuous Deployment)，这里查阅了一些资料，并简单总结了一下： 　　 　　1.持续交付意味着所有的变更都可以随时交付生产使用，强调的是一种可交付的能力 　　2.持续部署意味着所有被发现的release candidate 并且通过所有质量测试的变更都会被自动部署到生产环境中，强调的是一种方式 Jenkins：Jenkins是开源CI&CD软件领导者，并拥有众多插件来支持它用于持续、自动的构建/测试软件项目、监控外部任务的运行 二.在docker上安装Jenkins 选择jenkins的镜像文件

1.下载jenkins rpm包。 https://pkg.jenkins.io/redhat/ 2.安装 rpm -ivh jenkins- 2.182 - 1.1 .noarch systemctl start jenkins less /var/log/jenkins/jenkins.log // 查询admin密码 访问 http: // ip:8080/ 进行安装 3.修改端口 vi /etc/sysconfig/ jenkins JENKINS_PORT = " 8080 " // 修改这个 systemctl restart jenkins 4.登陆注册 5.批量导入插件 tar -xzvf jenkins-plugins. tar .gz -C /var/lib/jenkins/ systemctl restart jenkins 6.免密ssh密钥目录 有个问题搞了2天才清楚，在linux上免密登陆成功了，但是 Publish over SSH 上面配置一直失败！！！最终发现linux用的免密密钥目录是在/root/.ssh ，而jenkins用户的目录是在 [root@host- 173 -**- ** - ** . ssh ]# ls id_rsa id_rsa.pub known_hosts [root@host - 173 - ** - ** - ** .

前两篇博文中提到Development,QA,Staging,Production四个环境，也说明了源代码的分支和四个环境的对应关系，本篇博文聊一下，怎么把源码自动化发布到对应的环境中。 市面上主流的DevOpt工具都支持这些功能，github,gitlab，都有CICD功能，当然，如果源码服务器是自己搭建的，也可以利用像Jenkins这类软件来实现CICD，关于这些大众工具，网上有很多教程序，这里就不主要来分享了，本例是用.net core实现一个极简的自动发布工具——《MyCICD》。 说一下实现思路吧！ clone 或 pull分支代码 publish run 是不是很简单，上代码吧 using System; using System.Collections.Generic; using System.Configuration; using System.Diagnostics; using System.IO; using System.Linq; using System.Text; using System.Threading; namespace MyCICD { class Program { static void Main(string[] args) { var processIDs = new int[0]; while (true) { if

一台服务器安装多个 Jenkins 系统服务运行 因群友提问，一台服务器能否安装多个 Jenkins 系统服务运行？ 回答：当然必须可行。 下面我只举一个实例，还有其他方式都可以实现，动动手多折腾就都会了哈。 使用 tomcat 部署两套系统服务，如下图所示不同的两套 tomcat 服务。 image 957×582 39.7 KB 启动两套 tomcat 服务，如下图所示，都正常的启动了。 image 1425×828 71.6 KB 同一台服务器，同一个IP地址，访问不同的 jenkins 系统。 Jenkins 1系统 image 1318×1009 60.2 KB Jenkins 2系统 image 1295×1030 82.2 KB Jenkins 1系统 版本使用最新的 Jenkins 2.249.2 image 1307×1065 54 KB Jenkins 2系统 版本使用稍旧点的版本 Jenkins ver. 2.204.2 image 1303×1041 107 KB 如上图所示，多个 Jenkins 系统服务，不同的版本在一个系统里都是正常的运行。 来源： oschina 链接： https://my.oschina.net/sh021/blog/4732786

流水线支持两种语法：声明式和脚本式流水线。两种语法都支持构建持续交付流水线。且均可用在web ui或者Jenkinsfile中定义流水线，通常认为创建一个Jenkinsfile并将其检入源代码控制仓库是最佳实践。 创建jenkinsfile jenkinsfile是一个文本文件，它包含了Jenkins流水线的定义并被检入源代码控制仓库。下面的流水线实现了基本的三阶段持续交付流水线。 jenkinsfile(declarative pipeline) pipeline{ agent any stages{ stage( 'Build' ){ steps{ echo 'building...' } } stage( 'Test' ){ steps{ echo 'Test...' } } stage( 'Deploy' ){ steps{ echo 'Deploy...' } } } } 其中aggent指令是必须的，带白哦jenkins为流水线分配一个执行器和工作区。没有agent指令，声明式流水线不仅不生效，且不能完成任何工作。 一个合法的声明式流水线还需要stages指令和steps指令，因为他们来指示jenkins要执行什么，在哪个阶段执行。 pipeline语法： post部分定义一个或多个steps,post支持以下post-condition块中的其中之一：always

https://stackoverflow.com/questions/53541489/updating-environment-global-variable-in-jenkins-pipeline-from-the-stage-level/53541813 pipeline { agent any environment { FOO = "initial FOO env value" } stages { stage("Stage 1") { steps { script { echo "FOO is '${FOO}'" // prints: FOO is 'initial FOO env value' env.BAR = "bar" } } } stage("Stage 2") { steps { echo "env.BAR is '${BAR}'" // prints: env.BAR is 'bar' echo "FOO is '${FOO}'" // prints: FOO is 'initial FOO env value' echo "env.FOO is '${env.FOO}'" // prints: env.FOO is 'initial FOO env value' script { FOO = "test2" env.BAR = "bar2" } } }

互联网软件的开发和发布，已经形成了一套标准流程，最重要的组成部分就是持续集成（Continuous integration，简称CI）。 本文简要介绍持续集成的概念和做法。 一、概念 持续集成指的是，频繁地（一天多次）将代码集成到主干。 它的好处主要有两个。 （1）快速发现错误。每完成一点更新，就集成到主干，可以快速发现错误，定位错误也比较容易。 （2）防止分支大幅偏离主干。如果不是经常集成，主干又在不断更新，会导致以后集成的难度变大，甚至难以集成。 持续集成的目的，就是让产品可以快速迭代，同时还能保持高质量。它的核心措施是，代码集成到主干之前，必须通过自动化测试。只要有一个测试用例失败，就不能集成。 Martin Fowler说过，"持续集成并不能消除Bug，而是让它们非常容易发现和改正。" 与持续集成相关的，还有两个概念，分别是持续交付和持续部署。 二、持续交付 持续交付（Continuous delivery）指的是，频繁地将软件的新版本，交付给质量团队或者用户，以供评审。如果评审通过，代码就进入生产阶段。 持续交付可以看作持续集成的下一步。它强调的是，不管怎么更新，软件是随时随地可以交付的。 三、持续部署 持续部署（continuous deployment）是持续交付的下一步，指的是代码通过评审以后，自动部署到生产环境。 持续部署的目标是，代码在任何时刻都是可部署的

本次实践从需求出发到部署，采用大部分开源工具链Jira+GitLab+Jenkins+Spinnaker. Jira作为需求和任务管理工具，集成GitLab实现需求与代码关联，自动创建特性分支和版本分支以及合并请求的创建。GitLab代码提交触发JenkinsCI流水线，这里CI指的是Jenkins来做构建、测试、扫描、生成镜像上传镜像操作。CD由Spinnaker对各个环境部署。 详细的内容在下面PPT：本此内容已经录制成视频教程，已经购买Jenkins实践课程的同学请耐心等待，预计两天内免费更新到课程中。欢迎更多的同学一起加入DevOps课程学习！目前还有优惠哦~ 该项目涉及到Jenkins共享库中的Gitlab接口，Jenkinsfile，SPinnaker Pipeline模板。仓库地址：https://github.com/zeyangli/devops-practice 欢迎点赞关注！ 关于我们 泽阳，DevOps领域实践者。专注于企业级DevOps运维开发技术实践分享，主要以新Linux运维技术、DevOps技术课程为主。丰富的一线实战经验，课程追求实用性获得多数学员认可。课程内容均来源于企业应用，在这里既学习技术又能获取热门技能，欢迎您的到来！（微信ID: devopsvip） DevOps流水线实践课程 ????戳阅读原文，进入课堂 来源： oschina 链接：