持续集成

QQ小程序提供了Docker镜像来对小程序项目进行CI构建（ 文档 ）。文档中提供的Github Actions及Drone CI两种CI工具都对Docker的相关操作进行了深度集成，以至于不需要调用docker自身的命令。 而改写成Jenkinsfile也很简单，在检出代码后，只需要先拉取镜像然后运行即可。 操作步骤 在QQ小程序后台获取AppToken，然后赋值到环境变量 PLUGIN_APPTOKEN 。 在检出代码后，新建一个拉取镜像的stage，拉取镜像。 stage('拉取镜像') { steps { sh 'docker pull qqminiapp/build:latest' } } 追加部署的stage，运行docker镜像，并根据文档设置传递的参数，我这里把小程序版本设置为CI构建的编号，描述为提交的commit id。 注意在设置 workdir 后，还需要 -v 挂载目录，否则在容器内也无法读取到目录文件。 stage('部署') { steps { sh '''docker run --rm --workdir /root/workspace \ --env PLUGIN_VERSION=${CI_BUILD_NUMBER} \ --env PLUGIN_DESC=${GIT_BUILD_REF} \ --env PLUGIN_APPTOKEN=$

一、持续集成概念理解 白话理解：多个开发人员多次将自己写的提交代码到某个文件夹,通过又之前的代码进行整合,发现错误并修改; 持续集成(Continuous integration,简称CI),简单地说就是多个开发人员一天多次地将自己编码的代码提交到主干; 01:快速定位错误(每完成一点代码更新,就提交到主干,通过以之前提交的代码进行集成可以快速发现其中的错误) 02:防止分支大幅度偏离主干(若不经常持续集成,主干又在不断更新,会导致以后集成的难度变大,甚至难以集成); 持续集成的目的就是让产品可以快速迭代,同时还能保持代码的高质量。 二、持续交付概念理解 白话理解：所有开发人员在某个时间代码提交完成后,交给质量团队(测试工程师)进行测试。 持续交付(Continous delivery)指的是,频繁地将软件的新版本,交付给质量团队(测试人员)或者用户,以供评审,如果 评审通过,代码就进入生产阶段。持续交付可以看作是"持续集成"的下一步。它强调的是，不管代码怎样更新，软件 是随时随地可以交付给质量团队(测试人员)和用户进行评审。 三、持续部署概念理解 白话理解：质量团队(测试工程师)测试代码没问题,将代码交给运维人员,运维人员通过工具将代码发布到生产服务器 持续部署(Continuous deployment)是就是"持续交付"的下一步,指的是代码通过评审后,可以自己的部署到生产环境

Jenkins in OpenCASCADE eryar@163.com Abstract. Jenkins是一个开源软件项目，是基于Java开发的一个持续集成工具，用于监控持续复制的工作，旨在提供一个开放易用的软件平台，使软件的持续集成变成可能。 Key Words. OpenCASCADE, Jenkins 1.Introduction OpenCASCADE的开发代码量较大，如何确保程序的持续集成开发，保证质量，必须借助于工具了。像源码的管理使用了Git，Bug管理使用了Mantis Bug Tracker, 还使用了Jenkins： https://tracker.dev.opencascade.org/view.php?id=25609 关于Jenkins的功能介绍，以下内容转换自： http://www.cnblogs.com/clsn/p/7944116.html Jenkins是一个用Java编写的开源的持续集成工具。在与Oracle发生争执后，项目从Hudson项目独立。 Jenkins提供了软件开发的持续集成服务。它运行在Servlet容器中（例如Apache Tomcat）。它支持软件配置管理（SCM）工具（包括AccuRev SCM、CVS、Subversion、Git、Perforce、Clearcase和RTC），可以执行基于Apache

本文字数约810字，阅读约为3分钟 在手工测试几个小项目之后，为了保证后期维护，开始写了一些接口的自动化，因为测试对象主要是小程序，并没有很成熟的用于小程序的自动化工具，就使用了一些框架写的脚本，主要框架使用的是testng，选择好使用的框架，就要完成自己的自动化测试代码，完成的case还是一些主流程和常见会出现bug的case，这些case都是测后端接口返回，而现在负责业务变更频繁，没有做ui相关的自动化，前端展示还是依靠手工来测。 如何将本地写的自动化case能最大化的发挥测试的功能，就是我们这里要说的 在持续集成环境上跑自动化测试 。 因为持续集成，会强制测试通过才能合并代码，在合并代码之前就能知道测试是不是都通过了，可以帮助程序员获得最直观的反馈，知道哪里可能存在问题，这样才能做到防患于未然，吧bug杀死在摇篮里。 但这样说也不是绝对，因为我在之前写自动化case的时候，需要指定一个人的身份id，后来自动化挂掉的原因，是这个人从数据库改了通过id更改了他自己的身份，所以后续我们也将自动化测试和手工测试数据分离，尽量不影响自动化测试。 下面流程描述的是自动化测试配合持续集成的一个标准流程 在提交代码前，先本地跑一边单元测试，这个过程很快，失败了需要继续修改 我的操作一般是，每写完一个@Test都运行一遍，有问题就及时更改，都保证没问题后，运行一遍xml文件

文章目录 软件开发工作流程 持续集成（CI） 持续交付 持续部署（CD） Jenkins介绍 Jenkins概念 Jenkins特性 软件开发工作流程 互联网软件的开发和发布，已经形成了一套标准流程，把开发工作流程分为以下几个阶段： 编码 → 构建 → 集成 → 测试 → 交付 → 部署 持续集成（CI） 上面整个流程中最重要的组成部分就是持续集成（Continuous integration，简称CI）。 持续集成指的是，频繁地（一天多次）将代码集成到主干。将软件个人研发的部分向软件整体部分交付，频繁进行集成以便更快地发现其中的错误。 它的好处主要有两个： 1. 快速发现错误。每完成一点更新，就集成到主干，可以快速发现错误，定位错误也比较容易； 2. 防止分支大幅偏离主干。如果不是经常集成，主干又在不断更新，会导致以后集成的难度变大，甚至难以集成。 持续集成并不能消除Bug，而是让它们非常容易发现和改正。持续集成的目的，就是让产品可以快速迭代，同时还能保持高质量。它的核心措施是，代码集成到主干之前，必须通过自动化测试。只要有一个测试用例失败，就不能集成。Jenkins 是一个开源软件项目，旨在提供一个开放易用的软件平台，使持续集成变成可能。 持续交付 持续交付（Continuous delivery）指的是，频繁地将软件的新版本，交付给质量团队或者用户，以供评审。如果评审通过

概述 敏捷方法论有一个共同的特点，那就是都将矛头指向了“文档”，它们认为传统的软件工程方法文档量太“重”了，称为“重量级”方法，而相应的敏捷方法则是“轻量级”方法。正是因为“轻量级”感觉没有什么力量，不但不能够有效体现灵活性，反而显得是不解决问题的方法论似的。因此，就有了一次划时代的会议，创建了敏捷联盟。 在敏捷方法论领域中，比较知名的、有影响力的，是拥有与 Microsoft 的操作系统相同缩写语——XP的极限编程（eXtreme Programming）。极限编程方法论可以说是敏捷联盟中最鲜艳的一面旗帜，也是被研究、尝试、应用、赞扬、批判最多的一种方法论，也是相对来说最成熟的一种。 这一被誉为“黑客文化”的方法论的雏形最初形成于1996—1999年间，Kent Beck、Ward Cunninggham、Ron Jeffrey 在开发 C3 项目（Chrysler Comprehensive Compensation）的实践中总结出了 XP 的基本元素。在此之后，Kent Beck 和他的一些好朋友们一起在实践中完善提高，终于形成了极限编程方法论。 解析极限编程 那么什么是 XP 呢？XP 是一种轻量（敏捷）、高效、低风险、柔性、可预测、科学而且充满乐趣的软件开发方式。与其他方法论相比，其最大的不同在于： 在更短的周期内，更早地提供具体、持续的反馈信息。 在迭代的进行计划编制

一、 Jenkins 介绍 Jenkins 是一个开源软件项目，是基于 Java 开发的一种持续集成工具，用于监控持续重复的工作，旨在提供一个开放易用的软件平台，使软件的持续集成变成可能。 Jenkins 功能包括： 1 、持续的软件版本发布 / 测试项目。 2 、监控外部调用执行的工作。 特点： 1. jenkins 就是基于 Java 开发的一种持续集成的工具 2. 可以将运维用到的各个脚本整合起来，并且可以通过页面方式集中管理，而且也可以实现和 gitlab 、 github 交互，也可以实现自动编译、部署程序等。 二、持续集成 持续集成是 一种软件开发实践 ，即团队开发成员经常集成他们的工作，通过每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建 ( 包括编译，发布，自动化测试 ) 来验证，从而尽早地发现集成错误。 持续集成： Continuous Intergration （ CI ） 持续交付： Continuous Delivery （ CD ） 持续部署： Continuous Deployment （ CD ） 持续集成流程 1. 提交（ git ） 2. 测试 3. 构建（ jenkins ） 4. 测试 5. 部署（ ansible ， shell ， puppet ） 6. 回滚（ ansible ） 三、 Jenkins

1、安装JDK和配置JAVA_HOME和CLASSPATH 2、安装mysql数据库 3、创建数据库和用户 mysql -u root -p mysql> CREATE DATABASE sonar CHARACTER SET utf8 COLLATE utf8_general_ci; mysql> CREATE USER 'sonar' IDENTIFIED BY 'sonar'; mysql> GRANT ALL ON sonar.* TO 'sonar'@'%' IDENTIFIED BY 'sonar'; mysql> GRANT ALL ON sonar.* TO 'sonar'@'localhost' IDENTIFIED BY 'sonar'; mysql> FLUSH PRIVILEGES; 4、下载sonarqube wget https://sonarsource.bintray.com/Distribution/sonarqube/sonarqube-5.4.zip unzip sonarqube-5.4.zip vi /etc/profile SONAR_HOME=/usr/jenkins/sonarqube-5.4 export SONAR_HOME source /etc/profile 5、配置sonarqube

1 将jenkins和sonar集成 1.1 安装sonar 插件 jenkins上安装sonarqube plugin ,如果没有就安装sonarqube scanner for jenkins这个插件。 1.2 关联sonar 插件 1.2.1 系统设置 设置sonar地址 系统管理 > 系统设置 > Add SonarQube > sonarqube servers 修改如下： 1.2.2 全局设置 设置sonar扫描器位置 系统管理 > Global Tool Configuration > SonarQube Scanner > 新增 SonarQube Scanner 1.2.3 关联项目 选择一个项目 ，配置 > 构建 > Execute SonarQube Scanner >Analysis properties 填写相关参数，保存即可。 sonar.projectKey=demo sonar.projectName=demo sonar.projectVersion=1.0 sonar.sources=/server/tools/sonar-examples-4.5/projects/languages/php/php-sonar-runner-unit-tests sonar.language=php sonar.sourceEncoding=UTF-8

持续集成、持续交付和持续部署 持续集成 Continuous Integration：持续集成，简称CI，是软件开发周期的一种实践，把代码仓库（Gitlab或者Github）、构建工具（如Jenkins）和测试工具（SonarQube）集成在一起，频繁的将代码合并到主干然后自动进行构建和测试。 其实这里最关键的是自动化测试，这个是最难的，因为测试涉及内容很多。 持续交付 Continuous Delivery：持续交付，简称CD，是在CI的基础进行了扩展，在CI环节完成了软件构建和测试工作并形成了新的版本，那么接下来就要进行交付，而这里的交付并不是交付到生产环境，而是类生产环境（STAGING），我们可以理解为灰度环境或者预发环境，进而接受部分真实流量的测试。如果没有问题的话则通过手动的方式部署到生产环境。如下图所示： 持续部署 Continuous Deployment：持续部署，简称CD，它是在持续交付的基础上打通最后一公里的工作，就是把手动部署到生产环境的方式升级为自动部署。看下图和上图在最后部署到生产环境中的区别。 参考 The Product Managers’ Guide to Continuous Delivery and DevOps 持续集成、持续交付、持续部署 来源： https://www.cnblogs.com/rexcheny/p/12214998