Jenkins

通过python调用jenkins-cli实现快速发布 下载jenkins-cli.jar 登录jenkins页面，进入【系统管理】-【jenkins命令行接口】，点击截图中内容即可下载jar包文件。 编写jks-autodeploy.py文件，内容如下： #!/usr/bin/python3 #coding:utf8 import os import time curtime=time.strftime("%Y-%m-%d %H:%M:%S", time.localtime()) url="http://172.16.4.83:8080/" username="admin" passwd="passwd" #jobs="zzz-job" tag="v2.0.200601.09" jobs = open("jobs","r") for job in jobs: job=job.strip('\n') cmd = "java -jar jenkins-cli.jar -s %s -auth %s:%s build %s -p tag=%s" % (url,username,passwd,job,tag) os.system(cmd) print("%s开始构建------ tag版本:%s" % (jobs,tag)) time.sleep(5) jobs.close() 说明

卸载 rpm卸载 1、rpm -e jenkins rpm -ql jenkins 检查是否卸载成功 2、彻底删除残留文件： find / -iname jenkins | xargs -n 1000 rm -rf 注意这一步一定要进行！！！ 安装 1、下载安装jdk，安装java运行环境 因为这个jenkins是java写的，所有要运行起来必须要配置java运行环境。 到apache或什么地方去找jdk的包。安装。并且配置环境。之前已有写过 下载tar.gz或zip包。解压后。配置，或者 rpm 安装 后 环境变量配置 #vi /etc/profile 添加如下内容 export JAVA_HOME=/usr/local/jdk1.8.0_181 export PATH=$JAVA_HOME/bin:$PATH export CLASSPATH=$JAVA_HOME/lib/dt.jar:$JAVA_HOME/lib/tools.jar 让环境生效 #source /etc/profile 2、 下载 jenkins 安装包 要下载新版本的2.170 之后的版本， yum -y install jenkins-2.204.1-1.1.noarch.rpm 默认访问http端口是8080. 可到这修改，我这修改为8081 vi /etc/sysconfig/jenkins

1.使用场景 CICD是最近几年比较火的技术，顾名思义就是持续集成和持续部署。 以前的老技术，比如svn+jenkins这种，jenkins的配置多数还是依赖于负责维护CI的人，很多人不熟悉jenkins怎么配置，每一个步骤应该怎么编译和测试，一般都由CI的人来定义。 而CICD，其实可以使用jenkinsfile，就想gitlab的gitlab-ci.yaml文件，把CICD的流程控制和步骤也作为开发的一部分，由开发去维护。并且可以很快的部署到多个环境。 2. 实践 使用gitlab的CICD流程，使用nginx为例子。搭建一个pipe。一旦提交代码，自动部署nginx到k8s的集群中。 使用到的技术有： docker，k8s，helm，gitlab-runner，nginx 2. gitlab的CICD搭建 步骤一： 搭建k8s集群环境，可以使用minikube或者kubeadm快速的搭建起来k8s集群。 步骤： https://kubernetes.io/docs/setup/production-environment/tools/kubeadm/install-kubeadm/ 步骤二： 安装helm https://zhuanlan.zhihu.com/p/33813367 步骤三： 安装gitlab-runner并且注册 步骤四： 在gitlab上面新建project

我希望我的经历能够帮助现在的软件测试人，特别是想往自动化方向发展的测试人。 我的职业生涯开始和大多数测试人一样，开始接触都是纯功能界面测试。那时候在一家电商公司做测试，做了有一段时间，熟悉产品的业务流程以及熟练测试工作流程规范之后，效率提高了，工作比较轻松，也得到了更好的机会去发展。 在后来的公司得到了领导的信任，待遇方面工资加上年终奖，加起来年薪能达到20W。由于当时公司规模和产品的局限性，导致自动化测试始终未能应用到公司项目中。外面的世界很大，自动化已经流行而且越来越普及，内心经过一番抉择后，我更想要突破自己的技术瓶颈，所以选择顶住了压力，跳槽到一家公司专职做自动化测试工作。通过不断的项目经历和机会，我将公司产品前后端的自动化测试全部落地实现。 那些自动化脚本真正成为了公司资产，每次上线回归带来的收益远超出我的预期。并且定时在公司的技术分享会展示效果，那种从0到1的成就感非常难忘。后面负责自动化测试团队工作，核心框架搭建。学习用到的技术栈：包括Python、Selenium、RF、Requests、Jenkins、以及见识到先进主流的Docker容器技术，持续集成 从手工到自动化测试/测试开发，给我带来的帮助不仅仅是20W到40W，待遇上面的提高，包括做自动化测试遇到的坑，解决问题的思路，以及技术瓶颈的突破，形成一套知识框架体系，得到一套有效落地的自动化测试方案。

密码忘记了。没关系。 1，找到 JENKINS_HOME/adminxxx目录。users目录内找到用户的config.xml 2，把<passwordHash>节点的内容（图中黑色的那一串）换成 #jbcrypt:$2a$10$DdaWzN64JgUtLdvxWIflcuQu2fgrrMSAMabF5TSrGK5nXitqK9ZMS 3，重启，默认密码为：111111 ———————————————— 原文链接：https://blog.csdn.net/df007df/article/details/52622457 来源： oschina 链接： https://my.oschina.net/u/4382322/blog/4286756

1.新建一个jenkins用户 useradd jenkins 2.使用yum安装Jenkins(没有jdk先安装jdk) 先查看是否有jenkins的安装包 yum list jenkins 如果有直接安装即可 yum install jenkins 没有则进行下一步 wget -O /etc/yum.repos.d/jenkins.repo https://pkg.jenkins.io/redhat-stable/jenkins.repo ## 获取yum源 rpm --import https://pkg.jenkins.io/redhat-stable/jenkins.io.key ## 导入秘钥 yum install jenkins ## 安装 安装成功！可使用service jenkins status查看状态 3.启动jenkins，以及相关命令 service jenkins start ## 启动 service jenkins status ## 查看状态 service jenkins stop ## 停止 4.浏览器访问 http://127.0.0.1:8080 配置及安装相关插件 查看密码解锁 cat /var/lib/jenkins/secrets/initialAdminPassword 选择插件安装。根据他推荐的很多冗余的插件

一、简介 1、SonarQube 介绍 SonarQube 是一个开源的代码质量分析平台，便于管理代码的质量，可检查出项目代码的漏洞和潜在的逻辑问题。同时，它提供了丰富的插件，支持多种语言的检测，如 Java、Python、Groovy、C、C++等几十种编程语言的检测。它主要的核心价值体现在如下几个方面： (1)检查代码是否遵循编程标准：如命名规范，编写的规范等。 (2)检查设计存在的潜在缺陷：SonarQube 通过插件 Findbugs、Checkstyle 等工具检测代码存在的缺陷。 (3)检测代码的重复代码量：SonarQube 可以展示项目中存在大量复制粘贴的代码。 (4)检测代码中注释的程度：源码注释过多或者太少都不好，影响程序的可读可理解性。 (5)检测代码中包、类之间的关系：分析类之间的关系是否合理，复杂度情况。 2、SonarQube 平台是由 4 个部分组成 ①　SonarQube Server ②　SonarQube Database ③　SonarQube Plugins ④　SonarQube Scanner 3、SonarQube 工作流程 SonarQube 在进行代码质量管理时，会从下图 所示的七个纬度来分析项目的质量。 SonarQube 需要数据库的支持，用于存储检测项目后的分析数据，同时为了实现可持续监测，还需要持续集成工具（如Jenkins

“ 本文用图文示例了一个从零开始以 Linux + Jenkins + Gitee 为组合的持续化集成的部署实践，包括软件安装、项目权限、任务搭建、脚本编写等。 背景 手里有一个项目，最开始只有我自己维护，由 开发->部署->上线 均由我一个人完成。实际的应用场景为：本地开发、gitee 源码存储 + 版本控制、服务器 git 获取源码、服务器编译代码、项目正式上线可访问。 慢慢的随着项目的发展，开发人员多了一个，这个时候就涉及到两个人分别开发不同功能分别上线的情况，流程变成了 开发（并行）->测试（并行）->部署（随时）->上线（随时） ，不再完全由一个人来决定每一个路径的执行（当然强制由一个人也不是不行），因为完全取决于一个人来控制 部署->上线 的流程，会严重影响协作的流畅性。比如，当开发者需要部署时，就必须要另一个流程控制人实时能够进入服务器、拉取代码、执行编译命令。而这个流程控制人，完全没有了独立的时间去做别的事，被绑定在了当前迭代上，尤其是短时间内需要频繁操作时，会很占用资源。 这是我在个人小项目中体会到的实实在在的痛点，这也加深了我对团队中引入持续集成(CI)的理解和认知。但本篇不对原理性的内容做过多说明，而更多注重实践，即如何从零搭建一个可正常使用的 Jenkins 环境及构建任务。 目录 环境简介 安装 Jenkins 配置 Jenkins（角色、项目权限） 配置