如何在Ubuntu上使用Jenkins自动构建

Jenkins是一个开源自动化服务器,允许您构建管道以自动化构建,测试和部署应用程序的过程。在本指南中,您将实施基本工作流程,以加快持续集成和持续交付(CI / CD)过程。

准备

  • 设置腾讯云CVM服务器主机名和时区。没有服务器的同学可以在这里购买,不过我个人更推荐您使用免费的腾讯云开发者实验室进行试验,学会安装后再购买服务器
  • 创建标准用户帐户,加强SSH访问并删除不必要的网络服务。
  • 更新您的系统:
sudo apt-get update && sudo apt-get upgrade

注意 本教程是为非root用户编写的。需要提升权限的命令以sudo为前缀。

初步假设

本指南面向DevOps专业人士,因此假定:

  1. 本地工作站将用于开发和测试。
  2. Linode将用于远程Jenkins服务器。
  3. 两者都将使用Ubuntu 16.04。
  4. Jenkins将主要通过较新的Blue Ocean网络界面使用。
  5. 工作站和远程Linode都需要事先安装Docker。有关详细说明,请参阅我们的如何安装docker镜像的指南。
  6. 出于本指南的目的,仅使用Jenkins主服务器。
  7. 您将需要已创建的GitHub帐户,或类似的程序可用于Bitbucket和GitLab。
  8. 您还需要一个Docker Hub或类似的注册帐户。

了解Jenkins的工作原理

在自动化工作流程之前,有必要了解基本的CI / CD过程。下图说明了这一点:

最基本的过程包括三个阶段:构建,测试,部署。每次在分布式版本控制系统上进行更改时,都会在Jenkins服务器上触发自动化循环。运行该流程的整套说明Jenkinsfile位于源存储库的根目录中。该单个文件告诉服务器该做什么,何时做以及如何执行这些任务。

编写一个Node.js应用程序示例

如前一节所述,自动化过程首先提交版本控制系统。

在GitHub中创建一个新的存储库。本指南将使用一个简单的Node.js应用程序来展示Jenkins管道的工作原理。选择.gitignore相应的,不要忘记用以下内容初始化它README

将新存储库克隆到本地工作站:

 git clone git@github.com:<GITHUB_USERNAME>/jenkins-guide.git

打开您喜欢的文本编辑器,并app.js在存储库的根目录下创建该文件。添加以下内容:

~/jenkins-guide/app.js

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21

'use strict'; const express = require('express'); const app = express(); // Server connection const PORT = 9000; const HOST = '0.0.0.0'; // Application content const os = ['Windows','macOS','Linux'] // Web Server app.get('/',function(req,res) { res.json(os); }); // Console output app.listen(PORT, HOST); console.log(`Running on http://${HOST}:${PORT}`);

此应用程序使用Express Web服务器在端口9000上向浏览器提供单个JSON输出。接下来,保存test.js到存储库根目录的相同位置。

~/jenkins-guide/ test.js

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29

var supertest = require("supertest"); var should = require("should"); var server = supertest.agent("http://nodeapp-dev:9000"); // Unit Test describe("Webapp Status",function(){ // Test 1 - HTTP status it("Expect HTTP status 200",function(done){ server .get("/") .expect("Content-type",/text/) .expect(200) .end(function(err,res){ res.status.should.equal(200); done(); }); }); // Test 2 - Control Tests it("Mocha Control Test",function(done){ (1).should.be.exactly(1).and.be.a.Number(); done(); }); });

这是一个使用supertest和的简化测试套件should。它只有两个测试:第一个检查HTTP状态,它预计为200.第二个不是真正的测试,而是一个总是通过的控件。

这个例子将使用两个Docker容器,一个用于app.js使用Express,另一个用于使用Mocha的测试套件。每个图像都有自己的文件夹,其中包含相应的Dockerfilepackage.json

  • 为每个图像创建一个目录: mkdir express-image test-image
  • 创建Dockerfilepackage.jsonexpress-image。 ~/jenkins-guide/express-image/Dockerfile
FROM node:6-alpine

# Create a server directory
RUN mkdir -p /home/node/app
WORKDIR /home/node/app

# Install server dependencies
COPY /express-image/package.json /home/node/app
RUN npm install

# Copy node Application
COPY app.js /home/node/app

# Open port
EXPOSE 9000

CMD ["npm", "start"]

app.js启动时默认运行此映像。您可以将其视为Web应用程序的“dockerized”版本。

  • Dockerfile package.json将项目目录根目录中的文件复制到新映像中: ~/jenkins-guide/express-image/package.json
{
  "name": "express-image",
  "version": "1.0.0",
  "description": "Example Node Application",
  "author": "Your name",
  "repository": {
    "type": "git",
    "url": "git+https://github.com/<YOUR_USERNAME>/<REPOSITORY_NAME>.git"
  },
  "license": "ISC",
  "scripts": {
    "start": "node app.js"
  },
  "dependencies": {
    "express": "^4.13.3"
  }
}
  • 创建Dockerfiletest-image: ~/jenkins-guide/test-image/Dockerfile
FROM node:6-alpine

# Create feports directory
RUN mkdir -p /JUnit

# Create a server directory
RUN mkdir -p /home/node/tests
WORKDIR /home/node/tests

# Install app dependencies
COPY /test-image/package.json /home/node/tests
RUN npm install

# Copy test source
COPY test.js /home/node/tests

EXPOSE 9000

CMD ["npm", "test"]

此映像创建一个报告文件夹并从中安装依赖项package.json。一开始,它执行Mocha测试。

  • 为测试图像添加文件package.json: { "name": "test-image", "version": "1.0.0", "description": "This is a Mocha Test Server", "scripts": { "mocha": "mocha --reporter spec test.js", "test": "mocha --reporter mocha-junit-reporter --reporter-options mochaFile=/JUnit/reports.xml test.js" }, "repository": { "type": "git", "url": "git+https://github.com/<YOUR_USERNAME>/<YOUR_REPOSITORY>.git" }, "author": "Your name", "license": "ISC", "bugs": { "url": "https://github.com/<YOUR_USERNAME>/<YOUR_REPOSITORY>/issues" }, "homepage": "https://github.com/<YOUR_USERNAME>/<YOUR_REPOSITORY>#readme", "dependencies": { "mocha": "^4.0.1", "mocha-junit-reporter": "^1.15.0", "should": "^13.1.3", "supertest": "^3.0.0" } }

此JSON文件包含所有必需的依赖项,包括mocha-junit-reporterJenkins将用于测试存储所需的依赖项。请注意,测试脚本配置了mochaFile使用图像中指定的图像报告文件夹的选项Dockerfile。 您的最终项目分发将类似于:

注意:文件夹结构的方法和两个Docker容器的实现是不寻常的,但出于教学原因用于展示Jenkins Pipeline功能。

手动运行您的应用程序

在开始真正的自动化过程之前,首先需要了解要自动化的内容。

  • 假设您位于存储库的根目录,请从构建映像开始: sudo docker build -f express-image/Dockerfile -t nodeapp-dev:trunk . sudo docker build -f test-image/Dockerfile -t test-image:latest .
  • 您需要先启动nodeapp-dev容器。该标志--network用于避免与其他容器网络冲突。请注意,端口9000已打开,并且-d标志用于在分离模式下运行它。一旦启动,您可以打开浏览器并输入地址:http://localhost:9000进行检查。 sudo docker run --name nodeapp-dev --network="bridge" -d -p 9000:9000 nodeapp-dev:trunk
  • 接下来,启动test-image容器。--link为了与之通信,使用相同的网络以及标志非常重要nodeapp-dev。您会注意到容器的报告文件夹JUnit将安装在当前的存储库根目录中。这是reports.xml在主机上编写的必要条件。使用-it标志以交互模式运行它以将结果输出到stdout。 sudo docker run --name test-image -v $PWD:/JUnit --network="bridge" --link=nodeapp-dev -it -p 9001:9000 test-image:latest npm run mocha
  • 删除容器(您可能需要sudo -i)并在分离模式下再次运行它以测试JUnit输出。reports.xml之后应保存该文件。 sudo docker rm -f test-image sudo docker run --name test-image -v $PWD:/JUnit --network="bridge" --link=nodeapp-dev -d -p 9001:9000 test-image:latest
  • 测试应用程序后,您可以将其发布到公共注册表中。首先将其标签更改为更合适的标签。 sudo docker tag nodeapp-dev:trunk <YOUR_DOCKERHUB_USERNAME>/nodeapp-prod:latest
  • 假设您已登录Docker Hub,请将图像推送到注册表。 sudo docker push <YOUR_DOCKERHUB_USERNAME>/nodeapp-prod:latest
  • 或者,您可以保存压缩图像以进一步分发。 sudo docker save <YOUR_DOCKERHUB_USERNAME>/nodeapp-prod:latest | gzip > nodeapp-prod-golden.tar.gz
  • 做一些清理工作。sudo -i如有必要,停止使用两个容器。 sudo docker stop test-image nodeapp-dev
  • 最后,修改你的系统。 sudo docker system prune -f

您刚刚完成了这个虚构Web应用程序的整个构建,测试和部署过程。现在是时候实现自动化了。

安装Jenkins和Blue Ocean

Jenkins提供了许多安装选项:

  • 您可以jenkins.war从项目的站点下载自执行文件。这是一个快速有效的解决方案,可以与Jenkins一起使用,只需要很少的先决条件,但更难以维护和更新。
  • 你可以拉出官方的Docker镜像并从那里运行Jenkins。此方法需要额外配置,尤其是Docker功能中的Docker
  • 最后,您可以使用项目维护的包。这提供了更容易升级的好处。这是本指南使用的方法。

安装Jenkins

使用Jenkins项目维护的包允许您使用比分发包管理器中包含的版本更新的版本。

  1. 下载并添加当前稳定版Jenkins的存储库密钥: wget -q -O - https://pkg.jenkins.io/debian-stable/jenkins.io.key | sudo apt-key add -
  2. 将新存储库添加到您的sources.list: sudo sh -c 'echo deb http://pkg.jenkins.io/debian-stable binary/ > /etc/apt/sources.list.d/jenkins.list'
  3. 更新您的系统并安装Jenkins: sudo apt update sudo apt install jenkins
  4. 现在您已经安装了Jenkins,您需要授予其用户运行Docker命令的权限: sudo usermod -aG docker jenkins
  5. 控制你的后台程序使用非常简单:sudo service jenkins与选择startstoprestart,或status。启动您的服务以检查安装: sudo service jenkins start
  6. 如果一切正常,请在启动时启用该服务。 sudo systemctl enable jenkins
  7. 使用Linode Manager重新启动服务器以应用这些更改。 警告:为Jenkins远程安装建立安全参数超出了本指南的范围。但是,请注意需要在生产环境中解决的这些关键点:
    • 当您将jenkins用户添加到Docker组时,您在技术上授予其root权限。
    • 您必须为Jenkins连接强制实施防火墙策略。
    • 保护本地工作站与运行Jenkins的远程Linode之间的连接非常重要。您可以使用SSL和反向代理(如Apache或NGINX)或使用VPN来实现此目的。

设置Jenkins

  • 使用浏览器导航到默认服务器地址: http://<LINODE_IP_OR_HOSTNAME>:8080 您应该看到的第一个屏幕与此类似:
  • 复制临时管理员密码并使用它登录: sudo cat /var/lib/jenkins/secrets/initialAdminPassword
  • 选择安装建议的插件以开始下载标准插件:
  • 插件安装完成后,系统会要求您创建一个新的管理用户:
  • 如果成功,您将看到:
  • 单击开始使用Jenkins显示应用程序仪表板:
  • 如前所述,本指南将使用新的Blue Ocean界面,因此您需要单击侧栏上的Manage Jenkins链接:
  • 将出现一个新菜单。单击Manage Plugins
  • 单击“ 可用”选项卡,然后筛选搜索Blue Ocean的结果。
  • 选中与Blue Ocean插件对应的框,然后单击“ Install without button”按钮。
  • 您应该看到安装进度。完成后,单击“返回首页”链接,然后单击侧栏中的“ 打开蓝色海洋”链接。
  • 然后,您将看到新的Blue Ocean仪表板:

脚本与声明性流水线语法

Jenkins为Jenkinsfile语法提供了两种不同的选择:

  • 遗留的Scripted Pipeline语法。
  • 较新的Declarative Pipeline语法。

两者都支持持续交付和Jenkins插件。脚本语法基于Groovy编程环境,因此更加完整。另一方面,声明性语法“的创建是为了提供一种更简单,更具见解性的语法来创作Jenkins管道”,因此适用于日常自动化构建。您可以在Jenkins文档中了解有关语法比较的更多信息。

本指南将使用Declarative语法来说明Jenkins进程,因为它的设计更易于实现和理解。

Jenkinsfile结构

声明性管道语法非常直观。最基本的布局类似于下面所示的布局:

  • pipeline:所有文件应从顶部的此声明开始。它表示新管道的开始。
  • agent:定义工作环境,通常是Docker镜像。该any语句表明管道可以使用任何可用的代理。
  • stages:这个块是stage指令的集合。
  • stage:组一个或多个steps。您可以根据需要使用多个阶段,当您在需要“每个阶段”进行详细调试的复杂模型中工作时,这非常有用。
  • steps:在这里你定义你的行动。一个阶段可以分组许多步骤,每个步骤通常链接到一个特定的任务/命令。

代码块由大括号({})分隔,不使用分号。每个陈述都必须在它自己的行中,而Jenkinsfile你所执行的步骤的核心。一些常见的步骤是:

  • 运行脚本或代码命令。
  • 编译代码。
  • 运行测试。
  • 从源控件中推或拉。
  • 转移档案。
  • 创建Docker镜像,dockerize应用程序,拉取图像。
  • 几乎所有你能想到的行动都可以通过步骤来实现。

所有这些操作都可以在您内部执行,agent或者您也可以指示Jenkins通过SSH远程执行任何操作。如您所见,有无尽的自动化可能性。在一个简单的场景中,只有一个顺序执行其阶段的管道足以实现所需的最终状态,但您可以定义管道以在需要时并行运行。有关Jenkins声明性流水线语法的详细信息,请参阅官方文档

开始使用Pipelines

  • Jenkinsfilejenkins-guide工作站的目录中创建第一个。这只是一个模板,但它包含启动管道所需的所有代码: pipeline { agent any stages { stage('Build') { steps { echo 'This is the Build Stage' } } stage('Test') { steps { echo 'This is the Testing Stage' } } stage('Deploy') { steps { echo 'This is the Deploy Stage' } } } }
  • 将您的提交推送到GitHub: git add . && git commit -m "Jenkinsfile template" && git push origin master
  • 返回Blue Ocean Dashboard并单击Create a new Pipeline
  • 选择GitHub作为您的CVS:
  • 系统将要求您通过访问密钥连接GitHub帐户。单击链接以创建该密钥。
  • 接下来,您需要登录您的GitHub帐户,为令牌提供说明并生成它。您将看到一个类似于此的屏幕:
  • 复制标记值,然后将其粘贴到Blue Ocean选项卡上的字段中。然后单击“ 连接”按钮:
  • 如果您有多个组织帐户以及您的个人帐户,则需要选择包含您的存储库的组织:
  • 选择存储库位置后,单击“ 创建管道(Pipeline)”。这将自动触发您的第一次构建。
  • 单击构建以查看详细的管道。

从这里,您可以获得以下有价值的信息:1)您的构建号,2)每个步骤的控制台输出,3)选择进一步分析的阶段,4)浏览选项卡,其中包含有关提交更改,测试结果和存储的工件的信息, 5)重放您的构建,6)直观地编辑管道,7)转到您的管道设置。

使用Jenkins自动完成整个过程

Jenkinsfile模板使用一个非常基本的管道结构,只有三个阶段。您可以根据需要自定义它以适应多个阶段。最终的管道结构由项目复杂性和您必须遵循的开发指南决定。既然您已经了解了Node.js示例,那么您就知道如何设计一个自动化每个阶段的管道。出于本指南的目的,最终的管道应该:

  • 建立阶段
    • 如果遇到错误,请创建两个映像并中止任何进一步的测试或部署。
    • 如果发生故障,请通知相应的部门。
  • 测试阶段
    • 执行自动Mocha测试套件。
    • 发布nodeapp-dev图像以便于分发和手动质量测试。
    • 根据自动测试的结果通知相应的部门:成功,不稳定(任何自动测试失败)或阶段完全失败。
  • 部署阶段
    • 仅当在master分支上执行提交并且测试阶段成功完成时才会运行。
    • 发布前更改图像标记。
    • 将dockerized应用程序部署到Docker Hub。
    • 保存压缩的“黄金”图像以进一步分发。
  • 报告阶段
    • 保存JUnit文件并reports.xml进行详细分析。
    • nodeapp-prod-golden.tar.gz压缩图像保存到持久位置。
  • 清理阶段
    • 停止所有容器。
    • 修剪系统。
    • 清理Jenkins工作区。

提交对Pipeline的更改

首先编辑Jenkinsfile并粘贴以下管道。替换<DockerHub Username>为您自己的信息。

〜/詹金斯导/ Jenkinsfile

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101

pipeline { environment { DOCKER = credentials('docker-hub') } agent any stages { // Building your Test Images stage('BUILD') { parallel { stage('Express Image') { steps { sh 'docker build -f express-image/Dockerfile \ -t nodeapp-dev:trunk .' } } stage('Test-Unit Image') { steps { sh 'docker build -f test-image/Dockerfile \ -t test-image:latest .' } } } post { failure { echo 'This build has failed. See logs for details.' } } } // Performing Software Tests stage('TEST') { parallel { stage('Mocha Tests') { steps { sh 'docker run --name nodeapp-dev --network="bridge" -d \ -p 9000:9000 nodeapp-dev:trunk' sh 'docker run --name test-image -v $PWD:/JUnit --network="bridge" \ --link=nodeapp-dev -d -p 9001:9000 \ test-image:latest' } } stage('Quality Tests') { steps { sh 'docker login --username $DOCKER_USR --password $DOCKER_PSW' sh 'docker tag nodeapp-dev:trunk <DockerHub Username>/nodeapp-dev:latest' sh 'docker push <DockerHub Username>/nodeapp-dev:latest' } } } post { success { echo 'Build succeeded.' } unstable { echo 'This build returned an unstable status.' } failure { echo 'This build has failed. See logs for details.' } } } // Deploying your Software stage('DEPLOY') { when { branch 'master' //only run these steps on the master branch } steps { retry(3) { timeout(time:10, unit: 'MINUTES') { sh 'docker tag nodeapp-dev:trunk <DockerHub Username>/nodeapp-prod:latest' sh 'docker push <DockerHub Username>/nodeapp-prod:latest' sh 'docker save <DockerHub Username>/nodeapp-prod:latest | gzip > nodeapp-prod-golden.tar.gz' } } } post { failure { sh 'docker stop nodeapp-dev test-image' sh 'docker system prune -f' deleteDir() } } } // JUnit reports and artifacts saving stage('REPORTS') { steps { junit 'reports.xml' archiveArtifacts(artifacts: 'reports.xml', allowEmptyArchive: true) archiveArtifacts(artifacts: 'nodeapp-prod-golden.tar.gz', allowEmptyArchive: true) } } // Doing containers clean-up to avoid conflicts in future builds stage('CLEAN-UP') { steps { sh 'docker stop nodeapp-dev test-image' sh 'docker system prune -f' deleteDir() } } } }

这个完整的Jenkinsfile是使用声明性语法编写的。如果仔细阅读,您会注意到它描述了在上一节中应用程序部署期间使用的相同过程。本节将更详细地分析Jenkins文件。

代理和环境变量

第一个块定义了一个全局可用的环境变量DOCKER。您可以告诉它全局适用,因为它位于管道块内但在stage块之外。接下来是agent一个声明,这意味着Jenkins可以使用任何(服务器)代理。

〜/詹金斯导/ Jenkinsfile

1 2 3 4 5

pipeline { environment { DOCKER = credentials('docker-hub') } agent any

DOCKER定义通过凭证功能完成。这允许您使用机密登录信息,而不将其包含在Jenkins文件中。要配置此密钥对:

  • 单击齿轮图标(管道设置)。
  • 您将看到项目的设置页面,单击侧栏菜单底部的“ 凭据”链接。
  • 在下一个屏幕中,您可以选择要配置的凭据的范围。这可以限于当前项目或可以定义为全局。在这种情况下,您希望Docker Hub登录信息是全局的。单击左侧栏中的“ 添加凭据 ”。
  • 您将被重定向到类似于下面屏幕截图的屏幕。在那里,您需要输入您的Docker Hub用户名,密码并输入此凭证的唯一标识符(ID)。这个例子的选择是docker-hub。保存凭据后,您可以在管道中的任何位置使用它们。

在这个例子中的管道,DOCKER = credentials('docker-hub')创建两个环境变量,DOCKER_USER并且DOCKER_PWD可用于登录您的泊坞枢纽帐户。

建立阶段

你会注意到关于parallel代码块的第一件事是它不言自明 - 它会并行运行子阶段。这对于使用之前使用的相同shell命令构建两个Docker镜像非常有用。每个图像都在其自己的步骤中声明,这也是独立阶段的一部分。

~/jenkins-guide/Jenkinsfile

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

// Building your Test Images stage('BUILD') { parallel { stage('Express Image') { steps { sh 'docker build -f express-image/Dockerfile \ -t nodeapp-dev:trunk .' } } stage('Test-Unit Image') { steps { sh 'docker build -f test-image/Dockerfile \ -t test-image:latest .' } } } post { failure { echo 'This build has failed. See logs for details.' } } }

关闭平行阶段后,您会遇到post条件。Post意味着定义适用于整个BUILD阶段。在这种情况下,只设置failure条件,因此只有在BUILD阶段的任何部分失败时才会运行。配置Jenkins为通信提供的不同工具超出了本指南的范围。

测试阶段

测试阶段也使用并行执行:

~/jenkins-guide/Jenkinsfile

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33

// Performing Software Tests stage('TEST') { parallel { stage('Mocha Tests') { steps { sh 'docker run --name nodeapp-dev --network="bridge" -d \ -p 9000:9000 nodeapp-dev:trunk' sh 'docker run --name test-image -v $PWD:/JUnit --network="bridge" \ --link=nodeapp-dev -d -p 9001:9000 \ test-image:latest' } } stage('Quality Tests') { steps { sh 'docker login --username $DOCKER_USR --password $DOCKER_PSW' sh 'docker tag nodeapp-dev:trunk <DockerHub Username>/nodeapp-dev:latest' sh 'docker push <DockerHub Username>/nodeapp-dev:latest' } } } post { success { echo 'Build succeeded.' } unstable { echo 'This build returned an unstable status.' } failure { echo 'This build has failed. See logs for details.' } } }

Mocha Tests阶段开始两个图像并执行自动测试,产生了reports.xml保存到詹金斯工作区文件。另一方面,该Quality Tests阶段将trunk您的应用程序版本发布到Docker Hub。它首先发出Docker登录命令(使用预定义的凭据),然后更改图像标记并推送它。

再次,你有post代码块,但这次它有成功完成,不稳定和失败的通知。请记住,您可以在此处使用任何代码,而不仅仅是通知。

部署阶段

这个阶段引入了不同类型的块:when。顾名思义,该子句仅在满足某个条件时才执行。在此示例的情况下,仅在检测到对主分支的更改时才运行代码。提交给其他分支机构不会触发此管道的这一步骤。

在步骤中,您可以选择配置retrytimeout参数。我们上面的示例显示了一个嵌套用法,其中图像构建过程的超时为10分钟,并且在计时器到期时总共有三次重试。

post块设计用于在发生故障时进行清理。没有为此阶段设置通知。

报告和清理阶段

管道的最后两个阶段相对简单。该junit语句允许Jenkins使用reports.xml您的Mocha图像生成的文件,该archiveArtifacts命令将报告和应用程序文件保存到持久位置。默认情况下,该位置是JENKINS_HOME/var/lib/jenkins/jobs/<REPOSITORY>/branches/master/builds/lastStableBuild。如果需要,您可以在Jenkins的常规设置中配置自定义位置。

与分支机构合作

是时候将完整的Jenkins文件提交到Jenkins服务器并触发新管道的运行。为了测试when前面讨论的块,更改将被推送到不同的分支。

  • 在本地存储库上创建一个新分支: git checkout -b trunk
  • 将文件暂存,提交并推送到Jenkins服务器: git add . && git commit -m "Jenkinsfile complete Pipeline" && git push origin trunk
  • 单击Blue Ocean仪表板上的齿轮图标(管道设置),然后单击立即扫描存储库
  • 返回管道视图以观察您的舞台并行运行:
  • 完成后,您将看到整个管道。请注意,此提交是作为分支提交的,因此,DEPLOY跳过了阶段,这是预期的。
  • 如果您浏览菜单选项卡,则可以检查测试结果和存储的工件:

配置自动触发器

您可以将Jenkins设置为定期扫描您的存储库。为此,只需再次单击“管道”视图上的齿轮图标,然后单击“ 配置”。有很多选择。查找扫描存储库触发器如果没有运行,请定期选中此框。您可以选择任意数量的时间,对于此示例,将选择一分钟。

测试失败(不稳定的管道)

到目前为止,一切都应该按预期工作而不会出错。但是遇到错误会发生什么?

  • app.js在本地工作站中编辑。在服务器上,更改根地址//ERROR。这将导致express服务器上的错误404 (找不到页面),因此测试将失败。

~/jenkins-guide/app.js

1 2 3 4 5

// Web Server app.get('/ERROR',function(req,res) { res.json(os); });

  • 将您的更改提交给Jenkins: git add . && git commit -m "404 error" && git push origin trunk
  • 无需手动扫描存储库,因为您已经设置了Jenkins每分钟自动执行一次。等待触发器。运行后你应该看到类似的东西:
  • 导航到Tests选项卡,然后单击V形图以获得完整的控制台输出:
  • 关闭视图(右上角“X”),您将返回到存储库视图。
  • 修复app.js文件并保存。

失败的阶段

现在,在BUILD舞台上引发错误。

  • 编辑你的express-image/package.json。将Express包名称更改express-ERROR为模拟错误输入。

~/jenkins-guide/express-image/package.json "dependencies": { "express-ERROR": "^4.13.3" }

  • 将您的更改推送到Jenkins: git add . && git commit -m "express-image Build error" && git push origin trunk
  • 在管道视图中单击BUILD舞台,然后单击Shell脚本以查看控制台输出:
  1. 向下滚动并检查错误:
  1. 修复错误express-image/package.json

合并Pull Requests

trunk分支合并到master。这将触发整个管道的运行,包括部署阶段:

git checkout master
git merge trunk
git push origin master

蓝海洋仪表板外

Blue Ocean界面仍处于开发阶段,这意味着Jenkins的许多方面都不受新界面的管理。以下是一些最常见的屏幕。

  1. 单击齿轮图标以进入存储库菜单。在那里,单击左侧边栏中的状态。您将看到您的分支机构和一些一般信息:
  1. 如果单击master分支,您将看到更详细的仪表板:

从这个视图中,您可以查看许多有用的信息,如日志,工件,更改,测试结果的趋势等等。

未来的路

本指南介绍了Jenkins和Blue Ocean的基本自动化工作流程,但您可以做很多事情。仅举几个可能性:

  • JUnit插件能够发布XML格式的测试报告(由测试工具生成),并将这些趋势和报告集成到Blue Ocean进行分析。
  • 除了Jenkins GUI和新的Blue Ocean GUI,如果最适合您,您可以使用Jenkins CLI。
  • 管道支持自定义功能,可用于复杂的数据验证,测试,监控等。
  • 可以执行并行管道以加速某些进程以及仅在检查特定分支时触发管道才能运行。
  • post(或任何其他部分)可以从中受益,如电子邮件,松弛,或HipChat通知有用的内置功能。像往常一样,您可以决定触发通知的内容,成功构建,构建失败,更改或自定义条件。
  • 您还可以使用不同agent的特定stages,例如一个用于数据库任务,一个用于编译代码,一个用于webapp更新等。

更多信息

有关此主题的其他信息,您可能需要参考以下资源。虽然提供这些是希望它们有用,但请注意,我们无法保证外部托管材料的准确性或及时性。

想要了解更多信息教程,请前往腾讯云+社区学习更多知识。

参考文献:《https://www.linode.com/docs/development/ci/automate-builds-with-jenkins-on-ubuntu/

本文的版权归 阿小庆 所有,如需转载请联系作者。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏朱慕之的博客

Hello Hexo

Welcome to Hexo! This is your very first post. Check documentation for more info...

811
来自专栏拂晓风起

nodejs搭配phantomjs highcharts后台生成图表

1623
来自专栏JadePeng的技术博客

jenkins X实践系列(1) —— 背景知识

Jenkins X 是一个高度集成化的CI/CD平台,基于Jenkins和Kubernetes实现,旨在解决微服务体系架构下的云原生应用的持续交付的问题,简化整...

6442
来自专栏乐沙弥的世界

基于Linux (RHEL 5.5) 安装Oracle 10g RAC

    本文所描述的是在Red Hat 5.5下使用vmware server 来安装Oracle 10g RAC(OCFS + ASM),本文假定你的RHEL...

1383
来自专栏编程

【依葫芦画瓢】SSM-CRUD-3

继续上一篇的讲解【依葫芦画瓢】SSM-CRUD --- 2 概要: 服务端返回json数据,构建员工列表 完成员工新增功能 增加表单前后端校验(jQuery+J...

3215
来自专栏Hadoop实操

如何在CDH集群安装Anaconda&搭建Python私有源

Anaconda是一个用于科学计算的Python发行版,支持 Linux, Mac, Windows系统,提供了包管理与环境管理的功能,可以很方便地解决多版本p...

1.4K8
来自专栏SpringBoot 核心技术

第三十九章:基于SpringBoot & Quartz完成定时任务分布式单节点持久化

62410
来自专栏云知识学习

TKE容器服务​创建ingress

ingress:通俗的理解是:通过7层负载均衡转发对应url到对应的path中,实现准确转发流量目的。

2902
来自专栏菩提树下的杨过

spring-boot 速成(1) helloworld

一、mac上安装 $ brew tap pivotal/tap $ brew install springboot 安装成功后,可在终端查看命令行 ➜  ~ s...

2245
来自专栏KaliArch

Python构建私有代理IP库

至此我们就利用Python构建了一个属于自己的私有代理库,在进行爬去的时候可方便从数据库中获取使用。

6497

扫码关注云+社区

领取腾讯云代金券