index.xml

<?xml version="1.0" encoding="utf-8" standalone="yes" ?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Wechats on Jenkins 中文社区</title>
    <link>https://jenkins-zh.github.io/wechat/</link>
    <description>Recent content in Wechats on Jenkins 中文社区</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>zh-CN</language>
    <lastBuildDate>Fri, 10 Jan 2020 00:00:00 +0000</lastBuildDate>
    
	<atom:link href="https://jenkins-zh.github.io/wechat/index.xml" rel="self" type="application/rss+xml" />
    
    
    <item>
      <title>完整的 CI/CD 集合[教程]</title>
      <link>https://jenkins-zh.github.io/wechat/articles/2020/01/2020-01-10-the-complete-ci-cd-collection-tutorials/</link>
      <pubDate>Fri, 10 Jan 2020 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.github.io/wechat/articles/2020/01/2020-01-10-the-complete-ci-cd-collection-tutorials/</guid>
      <description> 什么是 CI/CD？  什么是 CI/CD？作者：Izzy Azeri-让我们看一下 CI 和 CD，这是所有 DevOps 商店的基本基石，并看看如何利用这些概念来帮助更好地交付下一个项目。 什么是持续集成和持续交付？作者：Arnab Roy—我们深入探讨了 DevOps 环境的两个基本要素。 什么是持续交付？好处和最佳实践，作者：ATC 团队-看看持续交付如何适合 DevOps 流水线，它与持续部署有何不同以及一些最佳实践。 持续集成与持续交付，作者：Rebecca Pruess—持续集成和交付是最常见的 DevOps 术语中的两个。但是，从字面上和您的业务来讲，它们是什么意思？ 持续交付与持续部署与持续集成之间的差异（以及如何最佳利用它们），作者：Angela Stringfellow—所有这些持续概念之间的真正区别是什么？从 DevOps 专家那里了解有关此内容的更多信息，以充分利用 CI 和 CD。 持续集成和工作流程简介，作者：Rekha Sree—所有这些持续概念之间的真正区别是什么？从 DevOps 专家那里了解有关此内容的更多信息，以充分利用 CI 和 CD。  CI/CD 入门  了解如何从头开始建立 CI/CD 流水线，作者：Samarpit Tuli—作为现代 DevOps 流程的基础，理解 CI/CD 并学习如何从头开始建立流水线非常重要。 持续输送流水线的各个阶段，作者：Pavan Belagatti—使用 CD 流水线是采用敏捷和 DevOps 的重要组成部分，这将提高组织的整体生产力。 AWS 提供的安全且可扩展的 CI/CD 流水线，作者：Chandani Patel—Amazon 和 DevOps 与许多工具和流程紧密结合，可实现高效的 CI/CD 流水线。 使用 Visual Studio 建立 CI/CD 流水线，作者：Mohamed Radwan—了解如何在 Visual Studio Team Services 中设置 CI/CD 流水线以自动执行代码的构建，测试和部署。 Kubernetes、Jenkins、Spinnaker 的 CI/CD，作者：Arvind Rajpurohit 和 Karan Patil—这是一个新工具，可以帮助您将新的构建不断地部署到 Kubernetes 集群。 使持续交付到数据库，作者：Matt Hilbert—无需使用不熟悉的流程和强制执行的策略将其添加到您现有的基础架构中，而是可以将数据库 CD 与现有系统一起实施。 用 Git 和 Jenkins 建立一个持续交付流水线，作者：Lyndsey Padget—了解如何利用 Git 的强大功能和简单性与 Jenkins 建立自动持续交付流水线。 使用 Jenkins、Helm、Kubernetes 轻松自动化 CI/CD 流水线，作者：Eldad Assis—了解如何使用 Jenkins、Helm、Kubernetes 设置工作流以自动化 CI/CD 流水线，以快速轻松地进行部署。 使用 Hashicorp Terraform 和 Jenkins 的不可变基础架构 CI/CD，作者：Radhakrishnan Rk—这篇内容广泛的文章应该会留下一些关于创建基础设施的问题没有得到解答。  CI/CD 工具和技术  20 种最佳持续集成工具：优化 CI/CD 流程的指南，作者：Ben Patterson—CI/CD 流水线是创建可靠的 DevOps 流程的关键，该流程可将稳定的产品更快地推向市场。 CI/CD 工具的淘汰：Jenkins vs、TeamCity vs、Bamboo，作者：Ben Putano—看看 DevOps 的三个顶级 CI/CD 工具-Jenkins、TeamCity、Bamboo-为您提供做出选择的建议。 我应该使用哪种 CI/CD 工具，作者：Anita Buehrle—了解典型的自动化 CI/CD 部署流水线的组件以及为什么需要它。 适用于 DevOps 和持续交付的最佳自动化测试工具（前 10 名），作者：Lavanya C—检查这些自动化测试工具，以在软件开发生命周期中实现持续交付。 前 8 个持续集成工具，作者：Vladimir Pecanac—如果您未来使用 C/I，Vladimir Pecanac 很好地概述了您的组织应考虑使用的 8 种持续集成工具。 Ansible 安装 CI/CD 工具：您需要知道的一切，作者：Evgeny Mekhanikov—了解如何使用 IT 自动化工具 Ansible 为 CI/CD 流水线设置工具。 Kubernetes 的 11 种持续交付工具（第 1 部分），作者：Anita Buehrle—一旦您的 Kubernetes 应用程序启动并运行，您将需要为 CI/CD 流水线构建其余部分。  CI/CD 最佳实践和关注点  CI 失败的 5 大原因，作者：Shashikant Jagtap—使用质量低下的服务器会浪费每个人的时间，因为构建时间太长，无法完成，从而导致测试结果断断续续，并使工程师感到沮丧。 降低持续交付速度的 6 个常见挑战，作者：Ben Putano—按照以下步骤进行持续交付和高质量代码，克服障碍并加速您的成功。 2019 年学习 Jenkins 和 CI/CD 的 5 门课程，作者：Javin Paul—查看这些免费课程，以帮助您了解有关使用 DevOps 工具 Jenkins 的更多信息。 CD/CI 成功所需的基本方法，作者：Ben Putano—如果您希望开始使用 CI/CD 流水线，则需要掌握一些基础知识。这篇文章将帮助您。 选择 CI 平台时应考虑的 10 件事，作者：Pavan Belagatti—持续集成是采用 DevOps 的第一步。选择 CI 平台时，请牢记这十个因素。 持续集成第 3 部分：最佳做法，作者：Deepak Karanth 和 RJ Williams—本文介绍了持续集成的最佳实践，以及采用 DevOps 原则（如自动部署等）的提示和预防措施。  </description>
    </item>
    
    <item>
      <title>使用 Jenkins 实现 CI/CD 多分支流水线</title>
      <link>https://jenkins-zh.github.io/wechat/articles/2019/12/2019-12-31-implement-cicd-for-multibranch-pipeline-in-jenkins/</link>
      <pubDate>Tue, 31 Dec 2019 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.github.io/wechat/articles/2019/12/2019-12-31-implement-cicd-for-multibranch-pipeline-in-jenkins/</guid>
      <description>简介 Jenkins 是一个持续集成服务器，用于从版本控制系统（VCS）中获取最新代码，然后对其进行构建、测试并将结果通知给开发人员。除了作为一个持续集成（CI）服务器之外，Jenkins 还可以做很多其它的事情。最初它被称为 Hudson，是川口耕介（Kohsuke Kawaguchi）基于 Java 编写的一个开源项目，因此，在安装和运行 Jenkins 之前，首先需要安装 Java 8。
多分支流水线是 Jenkins 中的一种流水线类型，它允许您在 Jenkinsfile 的帮助下为源码管理（SCM）库中的每个分支自动地创建一支流水线。
什么是 Jenkinsfile Jenkinsfile 是一个文本文件，被用来定义一个 Jenkins 流水线。在 Jenkinsfile 中可以使用领域特定语言（DSL）编写运行 Jenkins 流水线所需要的步骤，从而将流水线实现为代码。
来自 Jenkins 的定义 使用多分支流水线，您可以为同一项目的不同分支实现不同的 Jenkinsfile，Jenkins 将会自动发现、管理和执行那些分支中包含 Jenkinsfile 的流水线。
创建一个简单多分支流水线任务的步骤  点击 Jenkins 工作台左上角的 New Item 选项：   在 Enter an item name 中填入任务名，向下滚动，然后选择 Multibranch Pipeline，最后点击 OK 按钮：   填写任务描述（可选）。
 添加一个分支源（例如：GitHub）并且填写代码仓库的位置。
 选择 Add 按钮添加凭证并点击 Jenkins。
 键入 GitHub 用户名、密码、ID 和描述。</description>
    </item>
    
    <item>
      <title>欢迎使用流水线指令-矩阵</title>
      <link>https://jenkins-zh.github.io/wechat/articles/2020/01/2020-01-13-welcome-to-the-matrix/</link>
      <pubDate>Sun, 29 Dec 2019 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.github.io/wechat/articles/2020/01/2020-01-13-welcome-to-the-matrix/</guid>
      <description>我经常发现自己需要在一堆不同的配置上执行相同的操作。到目前为止，意味着我需要在流水线上的同一阶段制作多个副本。当我需要修改时，必须在整个流水线的多个地方做相同的修改。对于一个更大型的流水线来说，即便维护很少的配置也会变得困难。 声明式流水线1.5.0-beta1（可以从Jenkins 实验性更新中心获取）添加了一个新的 matrix 部分，该部分能让我一次指定一个阶段列表，然后在多个配置上并行运行同一列表。让我们来看一看！
单一配置流水线 开始我会使用一个带有构建和测试阶段的简单流水线。我使用 echo 步骤作为构建和测试行为的占位符。
Jenkinsfile
pipeline { agent none stages { stage(&#39;BuildAndTest&#39;) { agent any stages { stage(&#39;Build&#39;) { steps { echo &#39;Do Build&#39; } } stage(&#39;Test&#39;) { steps { echo &#39;Do Test&#39; } } } } } }  多平台与浏览器的流水线 我更喜欢在多系统以及浏览器结合的情况下执行我的构建和测试。新的 metrix 指令能让我定义一个 axes 的集合。每个 axis 有一个 name 以及包含了一个或多个 values 的列表。当流水线运行的时候，Jenkins 会将这些托管过来并将每个“轴”上所有可能值的组合运行在我的阶段内。一个“矩阵”上所有的元素都是并行运行的（只受限于可用的节点数量）。 我的“矩阵”有两个“轴”： PLATFORM 和 BROWSER 。PLATFORM 有三个值 BROWSER 有四个值，所以我的阶段会运行12个不同的组合。我已经修改了我的 echo 步骤用来使用每个元素中“轴”的值。
Jenkinsfile</description>
    </item>
    
    <item>
      <title>Jenkins CLI 命令行 v0.0.24</title>
      <link>https://jenkins-zh.github.io/wechat/articles/2019/12/2019-12-26-jcli-v0.0.24/</link>
      <pubDate>Thu, 26 Dec 2019 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.github.io/wechat/articles/2019/12/2019-12-26-jcli-v0.0.24/</guid>
      <description>本次发布，主要增加了 jcli 对凭据、计算节点的管理能力，以及通过 jcli 启动 jenkins.war。 对于部分子命令，还可以通过参数 --doctor 来实现错误诊断。
部分数据指标 * 测试覆盖率：87.1% * 下载量：2.8k+ * 贡献者：9
更多内容，请参考官方文档
🚀 功能  增加对配置即代码插件的支持 (#265) @LinuxSuRen 为 jcli 增加 Docker 镜像 (#260) @LinuxSuRen 增加 Jenkins 的 go 语言客户端的文档 (#256) @1179325921 支持获取 Jenkins 的唯一标识信息 (#292) @LinuxSuRen 支持在命令行中设置 Jenkins 连接地址 (#291) @LinuxSuRen 支持通过管理员为 Jenkins 的其他用户创建令牌 (#289) @LinuxSuRen 支持创建 JNLP 类型的计算节点 (#290) @LinuxSuRen 改进命令行的数据输出 (#285) @LinuxSuRen 增强 Jenkins 任务的搜索功能 (#284) @LinuxSuRen 增加搜索 Jenkins 任务以及文件夹 (#281) @LinuxSuRen 为 casc 命令增加诊断功能 (#280) @LinuxSuRen 增加计算节点的子命令 (#278) @LinuxSuRen 支持对 Jenkins 凭据的管理 (#266) @LinuxSuRen 支持发布插件的子命令 (#276) @LinuxSuRen 增加命令行输出中对配色的支持 (#273) @LinuxSuRen 支持同时取消队列中的多个任务 (#274) @LinuxSuRen 支持在启动 jenkins.</description>
    </item>
    
    <item>
      <title>Webhook 通用触发插件</title>
      <link>https://jenkins-zh.github.io/wechat/articles/2019/12/2019-12-23-generic-webhook-trigger-plugin/</link>
      <pubDate>Mon, 23 Dec 2019 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.github.io/wechat/articles/2019/12/2019-12-23-generic-webhook-trigger-plugin/</guid>
      <description>这篇文章将介绍我在 Jenkins 上遇到的一些常见问题，以及如何通过开发通用 Webhook 触发插件来解决这些问题。
问题 在使用 Jenkins 工作时，我经常遇到同样的问题：
 代码重复和安全性-每个仓库中的 Jenkinsfiles。 分支不是功能-master 上的参数化任务通常会混合与不同功能相关的参数。 记录不良的触发器插件-记录正常服务但记录不佳的使用插件  代码重复和安全性 每个 Git 仓库中都有 Jenkinsfiles，使开发人员可以使这些文件分开。开发人员 push 他们的项目，并且很难维护共享代码的模式。
我几乎用共享库解决了代码重复问题，但是它不允许我设置必须遵循的严格模式。任何开发人员仍然可以决定不调用共享库提供的功能。
还允许开发人员运行 Jenkinsfiles 中的任何代码的安全性方面。例如，开发人员可能会打印从凭据收集的密码。让开发人员在 Jenkins 节点上执行任何代码对我来说似乎不合适。
分支不是功能 在 Bitbucket 中有项目，每个项目都有 git 仓库的集合。像这样：
 PROJ_1  REPO_1 REPO_2  PROJ_2  REPO_3   让我们考虑一下我们要为这些仓库提供的一些功能：
 pull request 验证 构建快照（如果需要的话，也可以预发布） 构建发布  如果开发人员习惯于在 Bitbucket 中像这样组织仓库，我们是否应该在 Jenkins 中以同样的方式组织它们？而且，如果他们浏览 Jenkins，是否不应该为每种功能（例如 pull-request，snapshot 和 release）找到一份构建任务？每个具有仅与该功能相关的参数的任务。我认同！像这样：
 / - Jenkins root  /PROJ_1 - 一个文件夹，列出 git 仓库。  /PROJ_1/REPO_1 - 一个文件夹，列出与该仓库相关的任务。 /PROJ_1/REPO_1/release - 一份构建任务，执行发布。 /PROJ_1/REPO_1/snapshot - 一份构建任务，执行快照发布。 /PROJ_1/REPO_1/pull-request - 一份构建任务，验证 pull-request。   …​  在此示例中，snapshot 和 release 任务都可以在同一 git 分支上工作。不同之处在于它们提供的功能。它们的参数可以很好地记录下来，因为您不必混合与发行版和快照相关的参数。使用多分支流水线插件无法做到这一点，在多分支流水线插件中，您将参数指定为每个分支的 properties。</description>
    </item>
    
    <item>
      <title>使用 Docker 全自动构建 Java 应用</title>
      <link>https://jenkins-zh.github.io/wechat/articles/2019/12/2019-12-19-full-build-automation-for-java-application-using-docker/</link>
      <pubDate>Thu, 19 Dec 2019 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.github.io/wechat/articles/2019/12/2019-12-19-full-build-automation-for-java-application-using-docker/</guid>
      <description>这次的流水线中，我们使用 Docker 容器来构建我们的 Java 应用。
我们会在 Docker 容器里运行 Jenkins，再使用 Jenkins 启动一个 Maven 容器，用来编译我们的代码，接着在另一个 Maven 容器中运行测试用例并生成制品（例如 jar 包），然后再在 Jenkins 容器中制作 Docker 镜像，最后将镜像推送到 Docker Hub。
我们会用到两个 Github 仓库。
 Jenkins-complete：这是主仓库，包含了启动 Jenkins 容器所需的配置文件。 Simple-java-maven-app：使用 Maven 创建的 简单的 Java 应用。  在搭建之前，我们先来了解一下这两个仓库。
了解 Jenkins-complete 这是我们构建 Jenkins 镜像的核心仓库，它包含了所需的配置文件。我们通过 Jenkins 官方提供的 Docker 镜像启动 Jenkins 容器，然后完成一些动作，例如安装插件、创建用户等。
安装好之后，我们会创建用来获取 Java 应用的 Github 凭据，还有推送镜像到 Dockerhub 的 Docker 凭据。最后，开始创建我们应用的流水线 job。
这个过程很长，我们的目标是让所有这些事都自动化。主仓库包含的文件和详细配置会用来创建镜像。当创建好的镜像启动运行以后，我们就有了： 1. 新创建的 admin/admin 用户 2. 已经装好的一些插件 3. Docker 和 Github 凭据 4.</description>
    </item>
    
    <item>
      <title>Jenkins 健康检查顾问</title>
      <link>https://jenkins-zh.github.io/wechat/articles/2019/12/2019-12-11-jenkins-health-advisor-by-cloudbees-is-here/</link>
      <pubDate>Wed, 11 Dec 2019 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.github.io/wechat/articles/2019/12/2019-12-11-jenkins-health-advisor-by-cloudbees-is-here/</guid>
      <description>管理任何软件都面临着独特的挑战。Jenkins Masters 也不例外。例如，
 您如何掌握 Jenkins 环境中发生的所有事情？您是否正在查看问题跟踪器中打开的每个新缺陷？ 您如何确保您的 master 或 agents 不会默默失效？您是否正在监控其日志？监控其所有内部组件？如果出现问题，您该如何解决？ 您如何避免出现 “Angry Jenkins” 图标？  这就是我们通过 CloudBees 创建 Jenkins Health Advisor 的原因。
在 CloudBees，我们拥有多年为使用 Jenkins 的客户提供支持的经验，其中包括基于 Jenkins 构建的专有产品，例如 CloudBees Core。因此，我们的支持团队由拥有 Jenkins 知识的自动化专家组成，您在其他任何地方都无法获得。
当我们的工程师创建一个平台时，便会开始自动运行状况检查，以便他们可以编写规则来检测客户提供的 support bundles 中的已知问题，并将其重定向到所需的知识源以诊断和解决问题。
经过多年的内部使用，我们决定与社区共享此服务，我们很高兴为 每个 Jenkins 用户推出一项新的免费服务：Jenkins Health Advisor by CloudBees。
Jenkins Health Advisor by CloudBees 自动分析您的 Jenkins 环境，主动识别潜在问题，并通过详细的电子邮件报告为您提供解决方案和建议。
Jenkins Health Advisor by CloudBees 可以检测到各种问题，从简单的配置问题到安全性和最佳实践问题-Jenkins 实现的所有关键要素。入门过程分为 3 个步骤，您将在 24 小时内收到第一份报告。
我们希望您会喜欢这项服务，它将帮助您保持 masters 的健康。
花几分钟时间阅读我们的文档，发现服务，并随时通过 Jenkins 社区渠道（Gitter、jenkinsci-users@googlegroups.</description>
    </item>
    
    <item>
      <title>Jenkins CI/CD 集成 Git Secrets</title>
      <link>https://jenkins-zh.github.io/wechat/articles/2019/11/2019-11-29-jenkins-cicd-with-git-secrets/</link>
      <pubDate>Fri, 29 Nov 2019 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.github.io/wechat/articles/2019/11/2019-11-29-jenkins-cicd-with-git-secrets/</guid>
      <description>通常，对我们在代码中使用的机密或凭据进行加密，然后将其保存在安全的地方。我们可以有很多选择来实现这一目标，例如使用 Vault 和 Git-crypt 等工具来。git-secret 是一个简单的工具，我们可以使用它在 Git 仓库中存储密钥。Git-secret 使用 gpg 加密和解密密钥。
git-secret 的工作方式如下。进入仓库中要加密文件的文件夹，然后，运行 git init &amp;amp;&amp;amp; git secret init。这将初始化 .gitsecret 文件夹，然后运行 git secret tell $email，如果您希望其他用户解密密钥文件，则必须导入其 gpg 公钥，然后再次运行 git secret tell $otheruseremailid。现在您可以运行 git secret add $secretfilename 和 git secret hide，这将创建名为 $secretfilename.secret 的加密的密钥文件。
或许你会对在 Git 中存储加密的凭据感兴趣。
现在，您可以提交 master 分支库了。git-secret 自动将 $secretfile 添加到 .gitignore，因此您只需提交 $secretfile.secret 文件。
将 git-secret 集成到 Jenkins 中的主要挑战是 git-secret 使用 gpg 私钥和公钥。如果我们必须运行 git secret reveal，我们应该有一个 gpg 私钥。因此，我们如何在 Jenkins 上运行它，怎样使用一个从节点来拉取仓库并进行构建，如果您必须在从节点展示 git secret，则应该在从节点拥有 gpg 私钥。 我们如何在 Jenkins 流水线中实现这种加密和解密？</description>
    </item>
    
    <item>
      <title>Jenkins CLI 命令行 v0.0.23</title>
      <link>https://jenkins-zh.github.io/wechat/articles/2019/11/2019-11-28-jcli-v0.0.23/</link>
      <pubDate>Thu, 28 Nov 2019 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.github.io/wechat/articles/2019/11/2019-11-28-jcli-v0.0.23/</guid>
      <description>Jenkins CLI 在参加 2019 年谁是最受欢迎的中国开源软件投票，如果您已经是 Jenkins CLI 的用户，请点击下面的链接帮忙投上一票。
https://www.oschina.net/project/top_cn_2019#jenkins-cli
如果，您还没有听说或者使用过 Jenkins CLI，欢迎阅读我们的官方文档，以及下面的 v0.0.23 版本更新内容。
Jenkins 国内镜像中心发布后，收到了很多的反馈。鉴于之前的操作步骤相对较多，本次 Jenkins CLI 给出了一键启动国内镜像源的方案： 只要执行命令：jcli center mirror 即可启动镜像源。如果希望使用原有的地址，也非常简单：jcli center mirror --enable=false
更多有意思的玩法，请参考 Jenkins 中文社区论坛。
🚀 功能  支持创建插件 (#255) @LinuxSuRen 支持子 shell 命令 (#253) @LinuxSuRen 支持启用（或禁用）更新中心镜像源 (#251) @LinuxSuRen 增加以键值对的形式触发参数化流水线 (#249) @LinuxSuRen 支持停止最近一次的构建任务 (#248) @LinuxSuRen 支持命令多语言的描述 (#245) @LinuxSuRen 支持选择以及移除 Jenkins 连接配置项 (#246) @LinuxSuRen 支持命令行自动补全 (#242) @LinuxSuRen 支持下载特定版本的 Jenkins war (#240) @LinuxSuRen 支持配置诊断 (#169) @yJunS 支持从镜像中心下载插件 (#222) @LinuxSuRen 支持从镜像中心下载 Jenkins war (#221) @LinuxSuRen 支持从本地或者 URL 中加载 Jenkinsfile (#220) @LinuxSuRen 支持多种方式编辑流水线 (#206) @LinuxSuRen 支持安装指定版本的插件 (#211) @sbcd90  📝 文档完善  完善 README-zh.</description>
    </item>
    
    <item>
      <title>Jenkins 插件文档即代码：将文档迁移到 GitHub</title>
      <link>https://jenkins-zh.github.io/wechat/articles/2019/11/2019-11-22-plugin-docs-on-github/</link>
      <pubDate>Fri, 22 Nov 2019 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.github.io/wechat/articles/2019/11/2019-11-22-plugin-docs-on-github/</guid>
      <description>在2019年9月，我们宣布了对 GitHub 作为 Jenkins 插件站点文档来源的支持。 感谢 Zbynek Konecny 和 Olivier Vernin 以及其他贡献者， 现在可以将插件文档直接存储在插件储存库中，而不是 Jenkins Wiki 中，对于插件维护者和 Jenkins 基础设施团队来说，这在过去是很难维护的。
这篇博文可能对插件维护者和那些想为 Jenkins 文档做贡献的人来说很有趣。 我将描述如何将插件文档迁移到 GitHub 并获得如下页面:
为什么？ 通过使用插件的 GitHub 仓库存储文档， 插件维护者可以遵循 文档即代码 的方法，将文档更改作为 pull request 的一部分，这样就不会忘记文档的后续工作。 它还提供了一个 review 文档更改以及增加文档贡献者的认可度的机会，尤其是如果 story 与 Release Drafter 结合。
不幸的是，在2019年9月之前，GitHub 文档的使用引起了一些问题。 首先，许多插件维护者已经将他们的文档迁移到 GitHub，这导致了文档的碎片化（Wiki、GitHub、jenkins.io）。 为了解决这个问题，插件维护者仍然需要使用重定向来维护存根 Wiki 页面， 用户不得不花一些时间来找出真正的文档在哪里。 通过支持 GitHub 作为文档来源，我们允许维护者逐步淘汰插件 Wiki 页面，同时改善用户体验。
现在进行迁移还有更紧迫的原因…… 如果你订阅了开发者邮件列表， 你可能还看到了 R. Tyler Croy 关于 Jenkins Wiki 稳定性问题的声明， 并将其设置为只读，作为稳定实例的临时措施邮件列表主题。 虽然功能后来部分恢复了， 基础架构团队一致认为，我们应该逐渐转向替代解决方案。
例子 自从9月份宣布以来，超过50个插件已经从 Wiki 迁移到 GitHub。 几个例子：</description>
    </item>
    
    <item>
      <title>Jenkins CLI，助你轻松管理 Jenkins</title>
      <link>https://jenkins-zh.github.io/wechat/articles/2019/11/2019-11-20-jenkins-cli-help-you-manage-jenkins/</link>
      <pubDate>Wed, 20 Nov 2019 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.github.io/wechat/articles/2019/11/2019-11-20-jenkins-cli-help-you-manage-jenkins/</guid>
      <description>Jenkins CLI，简称 jcli，一个使用 Golang 开发的开源的 Jenkins 命令行工具。 它可以帮忙你轻松地管理 Jenkins。 无论你是 Jenkins 插件开发者，还是 Jenkins 管理员或者只是一个普通的 Jenkins 用户，它都是为你而生！
Jenkins CLI 功能简介 从2019年6月份第一个 git commit 算起，经过不断迭代，截止目前 Jenkins CLI 已经对外发布了18个版本，下载量超过2000，功能也日益增多。 目前主要功能列表如下所示： * 支持多 Jenkins 实例管理 * 插件管理（查看列表、搜索、安装、上传） * 任务管理（搜索、构建触发、日志查看） * 在浏览器中打开你的 Jenkins * 重启你的 Jenkins * 支持通过代理连接
此外，优秀的开源项目应该有着高代码质量。Jenkins CLI 始终坚持内建质量的原则，在开发过程中持续编写单元测试代码，并使用 TravisCI + SonarCloud 对代码质量持续分析，从而保证代码质量。 目前测试覆盖率为81.8%，下一个目标是将测试覆盖率提升到90%。 Go Report Card 给 Jenkins CLI 的代码质量评分为 A+。
如何安装 Jenkins CLI？ Jenkins CLI 目前支持的操作系统有：MacOS、Linux 以及 Windows。
在 Mac 上安装 在 Mac 上可以通过 brew 来安装 jcli：</description>
    </item>
    
    <item>
      <title>Jenkins CI 自动构建与 C-STAT 代码分析的集成</title>
      <link>https://jenkins-zh.github.io/wechat/articles/2019/11/2019-11-18-integration-of-c-stat-code-analysis-with-automated-jenkins-ci-build/</link>
      <pubDate>Mon, 18 Nov 2019 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.github.io/wechat/articles/2019/11/2019-11-18-integration-of-c-stat-code-analysis-with-automated-jenkins-ci-build/</guid>
      <description>介绍 我们大多数人都知道，为嵌入式软件设置 CI/CD 总是有局限性或挑战性的，并且我们还看到在某些情况下仍然没有其他可用的选择，这会导致工作量加大和代码质量缺失。
在本文中，我们将看到一个这样的嵌入式开发工具（IAR 嵌入式工作台），以及如何将 C-STAT 静态代码分析与持续集成版本 Jenkins 集成在一起，以及如何通过自动构建。
先决条件： a. IAR 嵌入式工作台 IDE b. C-STAT 许可证 c. Jenkins 安装
IAR 嵌入式工作台工具为我们提供了命令行执行选项，以实现 IAR 项目的静态代码分析。现在，我们将了解其工作原理。
IAR 命令行应用程序 IAR 系统为我们提供了一个名为 IarBuild.exe 的应用程序，该应用程序用于在命令行中执行分析。您可以在安装路径中找到 IarBuild.exe 应用程序，如下所示。
C:\Program Files (x86) \IAR Systems\Embedded Workbench 8.1\common\bin\  运行代码分析： 首先切换到命令路径中的上述路径，然后执行以下命令来分析整个项目。
IarBuild.exe D:\sample\project\setup\sample.ewp -cstat_analyze Debug   D:\sample\project\setup\sample.ewp 是您的 IAR 项目文件路径 -cstat_analyze 是要执行分析的命令 设置项目模式为 Debug  通过执行上述命令，它将对整个项目执行静态代码分析，并且结果将存储在 cproject.db 文件中，位于路径 ...project\setup\Debug\Obj\ 下。
注意下次运行代码分析时，如果自上次分析以来对源代码文件进行了任何更改，则必须首先清除数据库，以避免由于数据库文件中的新旧数据混合而引起的问题。
清晰的分析结果 要使用命令行清除数据库文件，请执行以下命令，
IarBuild.exe D:\sample\project\setup\sample.ewp -cstat_clean Debug  生成报告 要生成报告，我们可以使用 IAR 提供的 IREPORT 工具，您可以在同一安装目录中找到该工具。IREPORT 工具用于生成 C-STAT 执行的先前代码分析的 HTML 报告。</description>
    </item>
    
    <item>
      <title>了解如何使用 Jenkins-X UpdateBot</title>
      <link>https://jenkins-zh.github.io/wechat/articles/2019/11/2019-11-15-using-jenkins-x-updatebot/</link>
      <pubDate>Fri, 15 Nov 2019 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.github.io/wechat/articles/2019/11/2019-11-15-using-jenkins-x-updatebot/</guid>
      <description>Jenkins-X UpdateBot 是用于在项目源代码中自动更新依赖项版本的工具。假设您正在构建两个项目 A 和 B，B 使用 A 作为依赖项。A 的发布过程可以使用 UpdateBot 更新项目 B 的源，以使用 A 的新版本。在 pull request 中使用 UpdateBot，可以测试和检查更改或自动合并更改。
在 Jenkins-X platform 中，UpdateBot 由 Jenkinsfile 中的 UpdateBot 命令自动显示和调用。但是 UpdateBot 也可以在 Jenkins-X 之外使用，并且单独运行它可以帮助了解它可以做什么并测试版本替换。因此，让我们用一个简单的测试项目来尝试一下。
配置演示 UpdateBot 可以为各种不同的文件类型设置版本-我们不会在这里对它们进行全部测试，但是我们希望一个项目具有多个功能。因此，我们可以使用 JHipster sample app 示例应用程序，因为它具有 Maven pom.xml，npm package.json 和 Dockerfile。我们将对其运行 UpdateBot，以查看 UpdateBot 可以替换这些资源文件中哪些内容。
我们可以下载 UpdateBot jar file（v1.1.31），并为要更新的项目设置指向 GitHub 存储库的简单 UpdateBot 配置文件：
github: organisations: - name: ryandawsonuk repositories: - name: jhipster-sample-app useSinglePullRequest: true  useSinglePullRequest 标记意味着将创建一个包含我们所做的所有更改的 PR。但是我们实际上并不会进行任何更改-我们将在本地运行它，这样我们就不需要 GitHub 对存储库的写权限。通过设置环境变量，我们可以在不推送到 GitHub 的情况下运行：</description>
    </item>
    
    <item>
      <title>Working Hours 插件的第一阶段更新</title>
      <link>https://jenkins-zh.github.io/wechat/articles/2019/11/2019-11-14-gsoc-phase-1-updates-on-working-hours-plugin/</link>
      <pubDate>Thu, 14 Nov 2019 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.github.io/wechat/articles/2019/11/2019-11-14-gsoc-phase-1-updates-on-working-hours-plugin/</guid>
      <description>Working Hour Plugin 提供了一个界面，用于设置允许的构建日期和时间。在配置 Working Hour 之外运行的作业将保留到下一个允许的构建时间为止。
在 Google Summer of Code 的第一个代码阶段，我一直在从事 Working Hours Project 项目，该项目还有待于改善可用性。
当我们想设计一个具有大量可以使用自定义库的 UI 时，React 似乎比经典的 Jelly 页面更受青睐，尤其是日期选择器之类的开源组件。
但是，我们目前正致力于将 React 和 Jenkins 集成在一起，这是一个挑战。
第一阶段的成就 在第一个代码阶段，我们专注于 UI 改进，我们取得了以下主要改进： * 一个独立的 Web 应用程序，可以将其集成。 * 滑块，用于选择时间范围。 * 设置排除日期时间的更多字段。 * 用于选择排除日期的预设。 * Jenkins 样式界面
我们如何将 React 集成到 Jenkins 中 可以在这里找到集成的解决方案文档
最初，我们发现 BlueOcean 是在 Jenkins 中使用 React 的一个很好的例子，但是对于使用插件进行通用开发来说，它并不是一个好的选择。因此，我们需要找到另一种集成方式。
这是进行集成的步骤： * 在你 jelly 文件中的挂载点，通常是具有唯一 ID 的元素。 * 编写您的 React Application，但需要将安装点设置为您在上面设置的 ID。 * 将构建后的插件复制到 webapp 目录。 * 在你的 jelly 文件中，使用 script 标签引入</description>
    </item>
    
    <item>
      <title>致霍格沃兹测试学院的一封感谢信</title>
      <link>https://jenkins-zh.github.io/wechat/articles/2019/11/2019-11-13-a-thanks-letter/</link>
      <pubDate>Wed, 13 Nov 2019 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.github.io/wechat/articles/2019/11/2019-11-13-a-thanks-letter/</guid>
      <description>Jenkins 虽然有着无数潜在的用户群体，但是，在国内直接参与社区的人却寥寥无几，甚至， 都没有一个集中沟通交流的场所。这是非常令人困惑不解的一点，毕竟 Jenkins 已经诞生15年之久， 这比许多人的职业生涯都要长。
为了改善 Jenkins 在国内的使用体验，给大家一个可以集中讨论相关问的场所，Jenkins 中文社区 在一年前成立了。我们从一开始的双周例会（公开讨论社区发展相关的话题），增加了单周技术交流会 （分享交流持续交付相关的经验）。创建了一个零广告、零闲聊的技术交流微信群，目前有410+成员（有愿意 担任群2管理员的，可以与我们取得联系）。这都要感谢新老志愿者的无私贡献，不管是技术文章的翻译， 还是 issue、PR 或者代码、文档，甚至只是一个小小的建议，社区正因为有你们的存在而变得更好。 为了表示对他们的感谢和鼓励，给予贡献者一些小小的激励， 包括：图书、大会免费门票等等。这要感谢人民邮电出版社等对我们长期的大力支持。
我们今天尤其想要表示感谢的是——下面给予 Jenkins 中文社区现金10000元捐赠的企业。
霍格沃兹测试学院是中国领先的测试开发技术在线教育机构， 由知名测试社区 TesterHome 与测吧（北京）科技有限公司合作创办，专注于高级测试人才的培养。
对我们而言，并没有业内专家的驻场，背后也没有大厂的光环，全部是草根个人在努力奉献自己的力量。但是，我们深深地 理解开源的意义所在，开源并不是走秀，并不是只有大佬可以玩。任何一个不只是流于口舌的同学都是社区里的主人， 不满意就提 PR，这就是开源社区所需要的人才。社区大于代码，开源不只是把代码扔到 GitHub 上就可以了。我相信， 霍格沃兹测试学院也正是出于 Jenkins 中文社区下面的行为准则才愿意支持我们的：
 治理开源  公开例会 公开会议记录（文字、视频） 公开奖励 公开支出  活动开源  公开讨论如何组织活动  代码开源  https://github.com/jenkins-zh  文档开源  设计文档 教程   我们会把得到捐赠的资金用于社区基础设施的建设，带给更多关注 Jenkins、关注 DevOps、关注开源的同学们。资金去向请访问下面的地址：
https://jenkins-zh.cn/about/sponsors-list/
最后，我们由衷地希望霍格沃兹测试学院和开源事业发展的越来越好，得到更多人和组织的关注和支持。</description>
    </item>
    
    <item>
      <title>Jenkins 2019 年 Board 和 Officer positions 选举更新</title>
      <link>https://jenkins-zh.github.io/wechat/articles/2019/11/2019-11-12-2019-jenkins-board-and-officer-elections-update/</link>
      <pubDate>Tue, 12 Nov 2019 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.github.io/wechat/articles/2019/11/2019-11-12-2019-jenkins-board-and-officer-elections-update/</guid>
      <description>Jenkins 社区正在进行 2019 年 Board 和 Officer positions 的选举。提名征集已经结束。我们征集到了很多提名。根据愿意接受提名的人和无可争议的 Officer Positions，我们将有 3 票：
 投票选举 3 名board members 投票选举 Jenkins security officer 投票选举 Jenkins events officer  候选人 每位候选人都提供了一份声明，以帮助指导选民为什么要为候选人投票。有关更多详细信息，请参阅候选人宣言。竞选 board members 的候选人为：
 Alex Earl Oliver Gondza Ullrich Hafner Oleg Nenashev Mark Waite 赵晓杰（Rick）  竞选 security officer 的候选人是：
 Daniel Beck Wadeck Follonier  竞选 events officer 的候选人是：
 Alyssa Tong 赵晓杰（Rick）  选民登记 这是近一段时间以来我们第一次进行 Jenkins 选举。我们正在学习。Jenkins 选举旨在实现包容性。我们不仅将选举限于代码提交者。在 2019 年 9 月 1 日之前注册了 Jenkins 帐户的任何人都有资格投票。Jenkins 是一个成功的项目，大约有 10 万个符合该标准的帐户。我们正在与符合条件的选民联系，并要求他们明确 选择性加入 以参加投票。</description>
    </item>
    
    <item>
      <title>Jenkins 插件中心国内镜像源发布</title>
      <link>https://jenkins-zh.github.io/wechat/articles/2019/11/2019-11-11-update-center-mirror-announcement/</link>
      <pubDate>Mon, 11 Nov 2019 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.github.io/wechat/articles/2019/11/2019-11-11-update-center-mirror-announcement/</guid>
      <description>Jenkins 社区的网络基础设施都是架设在国外的服务器上，而且，并没有在国内有 CDN 或者负载均衡的配置。 对所有的 Jenkins 用户而言，1500+的插件可以帮助他们解决很多问题。然而，我相信，对于国内的很多用户来说， 可能有过一些不太愉快的经历——插件下载速度很慢，甚至会超时。难道遇到这种情况下，我们就只能等吗？
程序员，作为天生懒惰的人，总是希望能通过手中的键盘来解决各种各样的问题。凭什么？下载一个插件， 我还的苦苦地等待来自美国的数据包呢？数数你手里的 Jenkins 都安装了多少个插件。30个算少的吧。 经过一番搜索，发现果然已经有前人帮忙把大树种好了。让我们一起感谢“清华大学开源软件镜像站”提供的镜像服务：
https://mirrors.tuna.tsinghua.edu.cn/jenkins/
但是，当我兴冲冲地把 Jenkins 插件管理页面的更新中心的地址修改后，却发现了一个奇怪的情况，好像还是那么慢啊。 不管是换地址，还是换4G，换电脑都解决不了这个网络排队的问题。本着开源的精神（不满意就提 issue 或者 Pull Request）， 我只好继续挖掘这里的秘密。下面，是我向 TUNA 提的一个 issue（可以看到貌似我并不是第一个吐槽的人）：
https://github.com/tuna/issues/issues/659
是的，rsync 可以帮我们把106G的文件同步过来，免去了出国下载插件的麻烦，可没有解决最后一公里的痛。
通过下面的 PR 我们可以大致了解到，Jenkins 是通过解析 update-center.json 文件的方式来获取插件版本， 以及下载插件的。另外，如果你认为只是修改下文件里的 URL 就能解决这个问题的话，那么，请再仔细想一下这个事情。 既然小白兔可以把地址修改为一个比较方便的值，那么，大灰狼为啥不能往那些插件里加点辣椒水呢。 Jenkins 作为一个在 CI/CD 领域里领先了15年之久的大叔，当然不会输给了一些小毛贼。简单来说呢，这个事情 是通过两把钥匙来解决的——官方用其中一把钥匙给文件做了签名，并保管起来；把另外一把钥匙对外公布（保存在发行版中）。 只有通过了公钥验证的 update-center.json 文件，才会被使用到。
https://github.com/jenkins-infra/update-center2/pull/245
知道了问题所在，解决起来自然就容易了。Jenkins 中文社区帮大家把钥匙和地址的问题解决了，按图索骥三步走：
想了解技术细节？担心我们是大灰狼？我们欢迎喜欢学习的同学，更欢迎人民大众的检阅。 提问题，提需求，提代码，提文档，都是可以的。实际上，我们的整套方案中，所有的部分（除了拿一把钥匙以外） 都是开源的，包括还不够完善的设计文档。而且，并不需要花一分钱，完全利用现有的计算、存储资源。 此处，让我们再次感谢清华开源镜像站点、GitHub Actions、码云 Page 等。
https://github.com/jenkins-zh/mirror-adapter
最重要的事情，一定要在最后才说出来（不喜欢认真阅读文档的同学，对不起了）。想要体验极速 安装插件的同学，请认准 Jenkins 简体中文插件的版本：1.0.10
https://plugins.jenkins.io/localization-zh-cn</description>
    </item>
    
    <item>
      <title>在 Kubernetes 中通过 Apache Kafka 插件远程处理 Kafka 启动程序</title>
      <link>https://jenkins-zh.github.io/wechat/articles/2019/11/2019-11-08-remoting-over-apache-kafka-plugin-with-kafka-launcher-in-kubernetes/</link>
      <pubDate>Fri, 08 Nov 2019 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.github.io/wechat/articles/2019/11/2019-11-08-remoting-over-apache-kafka-plugin-with-kafka-launcher-in-kubernetes/</guid>
      <description>我是越南 FPT 大学的 Long Nguyen ，我的 Google Summer of Code 2019 项目是 Remoting over Apache Kafka with Kubernetes features 。这是我第一次为 Jenkins 做贡献，我非常兴奋地宣布在第一阶段已经完成的功能。
项目介绍 当前版本的 Remoting over Apache Kafka plugin 远程处理需要用户手动配置整个系统，包括 zookeeper 、 kafka 和远程处理代理。它也不支持动态代理配置，因此很难实现具有伸缩性的扩展。我的项目旨在解决两个问题： 1. 提供 Apache-Kafka 集群的现成解决方案。 2. Kubernetes 集群中的动态代理配置。
当前状态  支持凭据的 Kubernetes 连接器。 Kubernetes 功能中的 ApacheKafka 预配功能已完全实现。 Helm chart 部分实现。  Kubernetes 中的 Apache-Kafka 配置 此功能是 2.0 版本的一部分，因此尚未正式发布。您可以通过使用 Experimental Update Center 更新到 2.0.0-alpha 版本或直接从 master 分支构建来尝试该功能：</description>
    </item>
    
    <item>
      <title>为 DevOps 构建新的运营模型</title>
      <link>https://jenkins-zh.github.io/wechat/articles/2019/11/2019-11-06-building-new-operating-model-devops/</link>
      <pubDate>Wed, 06 Nov 2019 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.github.io/wechat/articles/2019/11/2019-11-06-building-new-operating-model-devops/</guid>
      <description>我一直在撰写有关企业面临的 DevOps 挑战的文章。从根本上讲，它是关于规模的：当企业尝试将其扩展到大型企业通常拥有的 800 多个应用程序中时，它们正努力实现在小型 DevOps 概念验证中看到的相同收益。 如果 DevOps 能够兑现其诺言并为企业带来可观的价值，那么就必须克服这一规模挑战。
重塑业务 今天，我想看看企业内部的关键变化，在实现 DevOps 的好处之前，这绝对是必须发生的：运营转型。
如今，大多数企业都围绕具有单向命令和控制结构的分层模型工作。这是自去年以来建立企业的方式：公司高层的“高级主管”领导层以相当专制的方式设定了公司的目标和战略。在此模型中，经理和业务部门负责人是高级管理人员意愿的执行者，以确保公司其他所有人都可以执行其战略方向。DevOps 的发展方向相反-从开发人员和运营人员的基层运动开始，然后逐步发展到如今在董事会席位上占有一席之地。
民主发展 为了使 DevOps 大规模发展，需要用更加有机、松散和自治的东西来代替这种结构。如果旧模式是专制的，那么新模式与现代政治革命家在松散连接和组织上“扁平”的结构中融合的方式有更多的共同点。
DevOps 的理想运营模式是一种权力民主化的模式，并且公司中的每个人都有权发挥自己的领导作用。在这里，高级主管确定了出行的方向，但是然后相信他们熟练的开发人员会做些必要的事情。在这种模式下，管理者促进和授权，而不是直接参与；确保开发人员拥有实现目标所需的一切，同时在这里和那里轻轻地推动，以确保他们的工作与整体公司议程和战略路线图保持一致。这涉及到我们在流动的劳动力中看到的宏观变化，并逐渐过渡到非中介的世界。
毋庸置疑，进行这种转换并不容易。这意味着要颠覆数百年来公认的惯例，放弃某些人认为晋升和任期使他们有权获得的精细控制。而且要明确一点：IT 部门将首当其冲。长期以来，控制权的守卫者需要转变为促进者。IT 将围绕应用程序开发设置指南和策略，并在需要时进行干预，但在日常工作中，IT 部门将需要退后一步，让 DevOps 开发人员继续前进，然后一定会建立信任和真正创新的文化，并蓬勃发展。
让专家掌控 开发人员团队比公司中的其他任何人都更了解他们的业务所面临的软件工程挑战。他们是理想的解决方案，同时敏捷的 DevOps 流程将帮助他们做到这一点。但是，如果开发人员大规模利用 DevOps，则需要摆脱来自 IT 和更广泛业务的严格监督。这不是关于信任的问题-人力资源和分析技术可供企业领导者远程监视和分析开发人员的效率。它只是归结为效率：以一种更加敏捷和有效的开发方法来消除障碍。以一种可以为您提供广泛、以业务为中心并且与供应商无关的方式执行此关键操作。如果没有民主变革的能力，并根据我们的经验来衡量结果，您将永远无法完全成功并获得真正的利益。
在我的下一个博客中，我将探讨帮助 DevOps 扩展的另一个关键因素：度量。 因此，请再次访问。</description>
    </item>
    
    <item>
      <title>Jenkins CLI 命令行 v0.0.22</title>
      <link>https://jenkins-zh.github.io/wechat/articles/2019/11/2019-11-04-jcli-v0.0.22/</link>
      <pubDate>Mon, 04 Nov 2019 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.github.io/wechat/articles/2019/11/2019-11-04-jcli-v0.0.22/</guid>
      <description>Jenkins CLI 可以帮忙你轻松地管理 Jenkins。不管你是一名插件开发者、管理员或者只是一个普通的 Jenkins 用户，它都是为你而生的！
项目地址：https://github.com/jenkins-zh/jenkins-cli
本次发布的更新 本次发布，包含了三位贡献者提供的代码以及文档改进。而且，两位贡献者，以该项目的名义向 JetBrains 申请了 Goland 的开源许可证。到目前为止，包含有5位开发者的贡献。期待有更多的 Jenkins 用户参与到这个项目当中。
Windows 用户，现在可以通过 Scoop 来很方便地安装 jcli 了。 安装命令为：scoop install jcli
🚀 功能  支持 HTTP 请求的语言设置 (#183 ) @yJunS 支持通过拷贝的方式创建 Jenkins 任务 (#205) @LinuxSuRen  📝 文档完善  在自述文件中增加 JetBrains 开源许可证的描述 (#209) @LinuxSuRen 完善英文的自述文件 (#210) @scottydocs 在文档中增加对 scoop 的描述 (#208) @LinuxSuRen 增加 godoc 的徽章 (#201) @LinuxSuRen  👻 维护  增加 PR 模板 (#212) @LinuxSuRen 把 dependencies 添加为标签 (#203) @LinuxSuRen 把 gopkg.</description>
    </item>
    
    <item>
      <title>介绍新的文件夹授权插件</title>
      <link>https://jenkins-zh.github.io/wechat/articles/2019/10/2019-10-28-introducing-new-folder-authorization-plugin/</link>
      <pubDate>Mon, 28 Oct 2019 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.github.io/wechat/articles/2019/10/2019-10-28-introducing-new-folder-authorization-plugin/</guid>
      <description>在我的 Google Summer of Code Project 期间，我创建了全新的 Folder Auth 插件，可轻松管理 Folders plugin 对文件夹中组织的项目的权限。这个新插件旨在通过易于管理的角色进行快速权限检查。该插件的 1.0 版本刚刚发布，可以从您的 Jenkins 更新中心下载。
该插件的灵感来自角色策略插件，可改善性能并简化角色管理。开发该插件是为了解决 Role Strategy Plugin 在许多角色上的性能限制。同时，该插件通过文件夹解决了 Jenkins 中组织项目最受欢迎的方式之一。该插件还具有一个新的 UI ，将来会有更多改进。
该插件支持三种类型的角色，分别适用于 Jenkins 中的不同位置。 * 全局角色：适用于 Jenkins 的所有地方 * 代理角色：限制连接到您的实例的多个代理的权限 * 文件夹角色：适用于文件夹内组织的多个作业
角色策略插件的性能改进 与角色策略插件不同，此插件不使用正则表达式来查找匹配的项目和代理，从而改善了我们的性能并简化了管理员的工作。为了减少需要管理的角色数量，通过文件夹角色授予文件夹的权限将继承其所有子项。这对于通过单个角色访问多个项目很有用。同样，一个代理角色可以应用于多个代理，并分配给多个用户。
此插件的设计目的是在权限检查方面优于角色策略插件。这些改进是使用我在 GSOC 项目的第一阶段创建的micro-benchmark framework来衡量的。两个插件相同配置的基准测试表明，与角色策略 2.13 中的全局角色相比， 500 个全局角色的权限检查速度提高了 934 倍，角色策略 2.13 本身包含一些性能改进。将文件夹角色与角色策略的项目角色进行比较，对于 250 个组织在 150 个用户的实例上的两级深层文件夹中的项目，对作业的访问权限检查几乎快了 15 倍。您可以在 此处 看到基准和结果比较。
Jenkins 配置作为代码支持 该插件支持 Jenkins 的“代码即配置”功能，因此您无需通过 Web UI 即可配置权限。YAML 配置如下所示：
jenkins: authorizationStrategy: folderBased: globalRoles: - name: &amp;quot;admin&amp;quot; permissions: - id: &amp;quot;hudson.</description>
    </item>
    
    <item>
      <title>Alpha 版本的插件管理库和 CLI 工具</title>
      <link>https://jenkins-zh.github.io/wechat/articles/2019/10/2019-10-25-plugin-management-tool-alpha-release/</link>
      <pubDate>Fri, 25 Oct 2019 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.github.io/wechat/articles/2019/10/2019-10-25-plugin-management-tool-alpha-release/</guid>
      <description>&amp;ldquo;人人都在重复造轮子，部分像实现插件管理的&amp;rdquo;细节&amp;rdquo;（签名元数据，制品校验和，从核心独立出来的插件&amp;hellip;）。 很明显， Jenkins 应该为实时 Jenkins 实例之外的插件安装提供充足的工具。&amp;rdquo; JENKINS-53767
我的 Google Summer of Code project 项目试图解决这个问题，方法是创建一个库，该库将在 Jenkins 的不同实现中统一插件管理逻辑，并提供一个可以使用户轻松下载插件并在 Jenkins 启动之前查看插件信息的 CLI 工具。 我很高兴分享我们刚刚发布的 Alpha 版本，您可以在此处查看！
GSoC 阶段 1 更新 当我考虑将插件管理器从 Jenkins 核心中移出时，由于依赖项的复杂性和数量，这最终成为了最具挑战性的第一步。相反，我们决定首先将 Jenkins Docker 中的 install-plugins.sh bash 脚本转换为 Java。 install-plugins.sh 脚本存在多个问题，即它是 bash 脚本并且扩展性有限，此外，它不会检索所有最新的更新中心的元数据。
Alpha 版本详情 模仿官方 Jenkins Docker 镜像中 install-plugins.sh 脚本中的操作，新的插件管理库接收插件列表、它们的版本和（或） URL，从中可以下载插件，并下载所需的插件及其依赖。插件从更新中心下载到指定目录，然后可以加载到 Jenkins 中。当前，可以通过 plugins.txt 文件和（或） -plugins 的 cli 选项指定要下载的插件，我们计划进一步扩展可以接收的输入格式。 还支持用于不同更新中心的自定义版本说明符。
该库将首先检查当前是否在用户指定的下载位置或用户指定的 Jenkins war 文件中安装了任何请求的插件。如果要求更高版本或更高版本作为依赖项，则将忽略或升级已安装的插件。确定插件下载 URL 后，库将下载插件并解析和下载其依赖。
这仅仅是个开始：插件管理器库和 cli 工具仍在开发中。 有关 CLI 选项以及如何运行该工具的最新信息，请参见存储库 README.</description>
    </item>
    
    <item>
      <title>Jenkins 线上技术交流</title>
      <link>https://jenkins-zh.github.io/wechat/articles/2019/10/2019-10-20-online-activity/</link>
      <pubDate>Sun, 20 Oct 2019 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.github.io/wechat/articles/2019/10/2019-10-20-online-activity/</guid>
      <description>在 Jenkins 中文社区微信技术交流群里，看到有人提出各种各样的问题，有一些问题快速得到了解答， 有一些则可能由于各种原因没有收到回答。大家都能看出来，在各种群里交流有很多的弊端，例如：
 某个时段大家在忙工作上的事情 文字性的问题描述不够清晰 难以记录交流成果 其他  为了能让更多 Jenkins 的用户有一个集中交流的地方，掌握正确的学习以及使用方法，了解常见问题如何排查。 我们会定期组织线上交流会，时间为两周一次，时长一个小时。参与者需要提前准备好 zoom 软件。如果希望 提问的话，则一定要提前找一个周围没有噪音的地方，否则主持人会禁掉你的麦克风。
那么，分享的内容是什么呢？具体的活动流程是什么样的？
值得您注意的是，任何人都可以在下次活动发布之前，申请作为分享人。您可以通过如下的几种方式进行申请：
 Jenkins 公众号后台留言 在社区活动微信群中留言 发送邮件到 admin@jenkins-zh.cn  您需要说明要分享的主题，时间控制在半个小时以内；如果内容较多的话，可以以系列的形式来分享。我们希望尽可能 给其他参与者多留一些提问时间。作为分享人，需要至少提前十分钟进入会议。
因此，活动流程非常简单。首先是技术分享，然后参与者提问互动。活动中会有视频录制，并在结束后上传到 Jenkins 中文社区的哔哩哔哩账号下。
而本次的线上分享活动，由 Jenkins 中文微信技术群的群主来分享有关 Jenkins 多分支流水线的内容。 大致内容包括：
 流水线概要 多分支流水线的使用场景 多分支流水线的应用 多分支流水线的优缺点  活动时间：每个单周周三21:00~22:00 参与方式：请访问 https://jenkins-zh.github.io/event/
注意
每次活动时间开始后，五分钟内没有人加入的话，活动取消。 具体活动的动态，我们会在微信*活动群*中给出通知。</description>
    </item>
    
    <item>
      <title>Jenkins CLI 命令行</title>
      <link>https://jenkins-zh.github.io/wechat/articles/2019/10/2019-10-17-jcli-v0.0.21/</link>
      <pubDate>Thu, 17 Oct 2019 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.github.io/wechat/articles/2019/10/2019-10-17-jcli-v0.0.21/</guid>
      <description> Jenkins CLI 可以帮忙你轻松地管理 Jenkins。不管你是一名插件开发者、管理员或者只是一个普通的 Jenkins 用户，它都是为你而生的！
项目地址：https://github.com/jenkins-zh/jenkins-cli
本次发布的更新 本次发布，主要增加了下载归档文件以及命令行补全的功能。
🚀 功能  增加为 jcli 生成完整文档的子命令 (#174) @LinuxSuRen 支持流水线 input 的输入 (#164) @LinuxSuRen 增加下载归档文件的子命令 (#185) @LinuxSuRen  🐛 缺陷修复  为每个请求增加权限信息 (#187) @yJunS 修复了首次安装后无法打印版本信息的问题 (#186) @zirmax  📝 文档完善  增加中、英文项目自述文件的链接 (#194) @LinuxSuRen  👻 维护  移除无用的代码行 (#178) @LinuxSuRen 为 job 客户端增加测试代码 (#190) @LinuxSuRen 为idea 增加 git 提交时忽略的文件配置 (#199) @LinuxSuRen 增加 jcli completion 的命令描述 (#188) @LinuxSuRen 绑定代码质量和构建状态 (#184) @LinuxSuRen 为 user client 增加测试代码 (#180) @LinuxSuRen 增加代码仓库自动备份的流水线 (#173) @LinuxSuRen 增加下载数量以及代码仓库大小的徽标 (#168) @LinuxSuRen  </description>
    </item>
    
    <item>
      <title>Jenkins 喊你参加 Hacktoberfest</title>
      <link>https://jenkins-zh.github.io/wechat/articles/2019/09/2019-09-27-jenkins-in-hacktoberfest/</link>
      <pubDate>Fri, 27 Sep 2019 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.github.io/wechat/articles/2019/09/2019-09-27-jenkins-in-hacktoberfest/</guid>
      <description>Hacktoberfest 是一场为期一个月的开源软件庆祝活动，该活动由 DigitalOcean 和 DEV 共同组织。
 Hacktoberfest 面向全球社区的每一位贡献者 至少须要向公开的 GitHub 仓库提交四个正式的 Pull Request 你可以在十月一日到三十日之前的任意时间注册  如何开始？ 在 https://hacktoberfest.digitalocean.com/ 注册账号，并提交 PR 到 GitHub 的公共仓库。推荐提交高质量的 PR。
而作为 Jenkins 的用户，我们的首选当然是 Jenkins 社区的相关代码仓库了。
我们非常地欢迎各位认可、热爱开源的朋友们，共同完善 Jenkins 简体中文插件、Jenkins 中文网站等本地化的内容。
除了上一届活动的项目以外，今年社区还推荐了一个由 Golang 编写的 Jenkins CLI 项目。下面是 jcli 这个命令行工具的功能特点：
 管理多个 Jenkins 服务器 支持搜索、安装、卸载、升级以及下载 Jenkins 插件 支持搜索、编辑、触发流水线任务，查看构建历史 支持查看、移除队列中的任务 支持命令行补全 支持代理设置  如果你用的是 MacOS 的话，可以通过 brew 很方便地安装该工具，命令如下：
brew tap jenkins-zh/jcli brew install jcli  对于其他操作系统的用户，也可以在项目首页 https://github.com/jenkins-zh/jenkins-cli/ 上找到对应的安装帮助信息。</description>
    </item>
    
    <item>
      <title>2019 DEVOPS WORLD和JENKINS WORLD 获奖者公布</title>
      <link>https://jenkins-zh.github.io/wechat/articles/2019/09/2019-09-23-devops-world-jenkins-world/</link>
      <pubDate>Mon, 23 Sep 2019 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.github.io/wechat/articles/2019/09/2019-09-23-devops-world-jenkins-world/</guid>
      <description>15个组织和个人荣获DevOps杰出成就，开源贡献和渠道合作伙伴绩效
 DEVOPS WORLD | JENKINS WORLD，2019年8月15日在旧金山，由CloudBees，企业DevOps领导者推动经济持续发展，今天宣布了2019 DevOps world 和 Jenkins world 获奖者。该奖项表彰3个类别的成就：Jenkins 社区奖，表彰对 Jenkins 项目做出重大贡献的人；CloudBees 创新奖，表彰在 DevOps 转型中取得优秀成果的组织；和CloudBees 渠道合作奖，重点介绍在创收和帮助组织实现DevOps转型方向表现出色的合作伙伴。
CloudBees创新将的获得者包括各种规模的组织，从风险投资的小型创业公司到全球技术巨头。Jenkins 社区将授予了4个人，他们为 Jenkins 社区做出了贡献。最后5个渠道合作伙伴因在勤奋卓越获得认可。
JENKINS 社区奖 Jenkins 社区奖由 Jenkins 创始人兼 CloudBees 首席科学家 Kohsuke Kawaguchi 和 Jenkins 大使组成的小组选出。Jenkins 大使每年都会被提名，他们都是有影响力的 Jenkins 爱好者，热衷于与他人分享 Jenkins 的技术专长。
“2019 Jenkins社区奖表彰了社区成员的努力，他们在几个关键领域为推进 Jenkins 做出了重大贡献“，Kawaguchi 表示，”今年的提交的质量比以往任何时候都要好。”
2019 Jenkins 社区奖得主：  2019最有价值的 Jenkins 贡献者 - Oliver Gondža 2019Jenkins 安全 MVP - Victor Gazdag 2019最有价值的 Jenkins 倡导者 – 赵晓杰 2019最有创新的 Jenkins X 实现 - Vincent Behar  *CloudBees创新奖** CloudBees 创新奖由一个评委团选出，评委团成员包括 CloudBees 首席执行管兼联合创始人 Sacha Labourey，DevOps.</description>
    </item>
    
    <item>
      <title>React Plugin Template，让你可以使用 React 来编写 Jenkins 插件</title>
      <link>https://jenkins-zh.github.io/wechat/articles/2019/09/2019-09-19-introduce-react-plugin-template/</link>
      <pubDate>Thu, 19 Sep 2019 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.github.io/wechat/articles/2019/09/2019-09-19-introduce-react-plugin-template/</guid>
      <description>模板地址
React Plugin Template https://github.com/jenkinsci/react-plugin-template
起因 这个模板是笔者在今年的 Google Summer of Code 中的项目 Working Hours - UI Improvement 中产出的。由于我们想使用 React 的一些组件来优化用户体验，例如在 Working Hours 里面我们想用 ReactDatepicker 来帮助用户选择日期，于是整个 Working Hours 插件的前端部分都试图用 React 来编写，而由于 Jenkins 的传统插件编写主要还是用的 Jelly ，一套类似 JSP 的后端渲染引擎，因此笔者在一开始也踩了不少坑。以至于想到，可以抽象出一套插件的脚手架来帮助有相似需求的同学。
链接：
GSoC：Working Hours UI Improvement https://summerofcode.withgoogle.com/projects/#6112735123734528
Github：Working Hours 插件 https://github.com/jenkinsci/working-hours-plugin
概述 在以往，我们可以使用 Jelly 来开发 Jenkins 插件的前端部分，同时一些请求可以绑定到对应的类，但是当我们想要更高程度地去自定义插件界面的时候，Jelly 就显得捉襟见肘了。这就是这个模板的目的，帮助开发者使用 React 来开发一个插件。
同时，有了 React ，我们就可以使用很多基于 React 的库，webpack 也可以帮助我们更安全更高效地使用 js 库。
特点 | 集成 React | 开发者可以使用 React 充分控制 UI | 使用了 Iframe | Iframe 隔离了之前 Jenkins 添加的一些 js 库会造成的影响，例如 Prototype.</description>
    </item>
    
    <item>
      <title>Jenkins World 贡献者峰会及专家答疑展位</title>
      <link>https://jenkins-zh.github.io/wechat/articles/2019/09/2019-09-16-jenkins-world-contributor-summit-and-ask-the-experts-booth/</link>
      <pubDate>Sun, 15 Sep 2019 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.github.io/wechat/articles/2019/09/2019-09-16-jenkins-world-contributor-summit-and-ask-the-experts-booth/</guid>
      <description>Jenkins 15周岁啦！Jenkins World 将 DevOps 思想领袖、IT 主管、持续交付实践者以及 Jenkins 社区和生态系统齐聚这场全球活动，让与会者有机会学习、探索以及面对面交流，帮助塑造 Jenkins 的下一次发展以及针对 DevOps 的解决方案。
此外，Jenkins 贡献者峰会也于旧金山举行。Jenkins 贡献者峰会是现有贡献者以及未来贡献者围绕 Jenkins 项目，以最新思考和最大努力来共同探讨、学习和协作的地方。上午峰会安排是由核心贡献者进行一系列展示介绍。这些介绍突出了每项工作的内容，以及社区成员可以提供哪些帮助。下午分组讨论会上，与同好小组进行了深入讨论，并同子项目贡献者进行合作。
我非常荣幸能成为其中一员。 第一天 第一天以贡献者峰会开场。这让大家有机会聚在一起讨论对社区的贡献，把脑海中熟悉的名字和本人对上号。大多数人我只通过视频聊天和在 gitter 上见过，所以当时我特别激动。我们聚在一起了解 Jenkins 开源画卷的起点。
接下来是同好讨论/非正式会议。我主导这些讨论会，个人认为进展十分顺利。成员组织管理员 Martin d’Anjou 和 Jeff Pearce 为我们带来一场有关 Google 编程夏令营（Google Summer of Code，以下简称 GSoC）项目的演讲。
GSoC 学生 Natasha Stopa 介绍了她的项目——Plugin Installation Manager Library/CLI Tool。这是一个超酷的项目，在社区受到广泛欢迎。
讨论会结尾是博思艾伦咨询公司（Booz Allen Hamilton）的 Steven Terrana 的展示和精彩的 Jenkins 模板引擎。如果你还没有试过这个，请一定不要错过https://github.com/boozallen/jenkins-templating-engine。
主展厅 从第二天起，我和其他几位 Jenkins 组织管理者将在 Jenkins 社区的专家答疑（Ask the Expert）展位。
这真的是一场非常有意思的体验，让我有机会了解社区正在做什么，帮助他们解决面对的问题。问题涉及的范围很广，从 Jenkins X 到我负责维护的种种插件，如 Jenkins Prometheus 和 Sysdig Secure Scanning 插件。也有很多关于 Kubernetes 的问题。有很多关于 Kubernetes 使用情况提高的市场营销方面的数据，但对 Kubernetes 上 Jenkins 的超高兴趣度真的让我大吃一惊。当然，也有机会拍点儿自拍。</description>
    </item>
    
    <item>
      <title>介绍新的 GitLab 分支源插件</title>
      <link>https://jenkins-zh.github.io/wechat/articles/2019/09/2019-09-11-introducing-gitlab-branch-source-plugin/</link>
      <pubDate>Wed, 11 Sep 2019 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.github.io/wechat/articles/2019/09/2019-09-11-introducing-gitlab-branch-source-plugin/</guid>
      <description>GitLab 分支源插件已经走出 beta 阶段，并已发布到 Jenkins 更新中心。 它允许您基于 GitLab 用户 或 组 或 子组 项目创建任务。 您可以:
 从 GitLab 用户/组/子组导入单个项目的分支作为任务（多分支流水线任务） 从 GitLab 用户/组/子组导入所有或部分项目的分支作为任务（GitLab 组任务或 GitLab 文件夹组织）  GitLab 组项目对项目进行扫描， 根据设置的规则导入流水线任务。 导入项目之后， Jenkins 立即基于 Jenkinsfile 流水线脚本运行任务并且将状态通知到 GitLab 流水线状态。 这个插件与其他分支源插件不同，它提供了 GitLab 服务器配置，可以在系统配置中配置。 Jenkins 配置即代码 (JCasC) 也可以用于配置服务器。 要想了解更多关于服务器配置的信息，请参考我之前的博客。
要求  Jenkins - 2.176.2 (LTS)
 GitLab - v11.0+
  创建任务 要创建多分支流水线任务（使用 GitLab 分支源）或 GitLab 组任务，您必须将 GitLab 个人访问令牌添加到服务端配置。 凭据用于获取项目的元数据，并在 GitLab 服务器上设置 hook。 如果令牌具有管理访问权限，您还可以设置 系统 Hook，而 Web Hook 可以从任何用户令牌设置。</description>
    </item>
    
    <item>
      <title>Jenkins 中文社区第二届明星贡献者名单</title>
      <link>https://jenkins-zh.github.io/wechat/articles/2019/09/2019-09-05-award/</link>
      <pubDate>Thu, 05 Sep 2019 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.github.io/wechat/articles/2019/09/2019-09-05-award/</guid>
      <description>有这样一群人，他们是一群富有热情的英雄，他们本着内心的使命感，从四面八方汇聚到开源社区，并且为社区贡献自己的一份力量。他们就是“Jenkins 中文社区贡献者”
Jenkins 中文社区贡献激励活动是一个旨在长期为社区贡献者谋福利的活动。在社区伙伴们的积极参与下，第二届社区激励活动结果新鲜出炉了!
让我们用热烈的掌声恭喜五位明星贡献——donghui、李楠、yJunS、李煜东、书生。他们在社区运营、活动组织、技术交流等方面有着卓越的贡献，并得到社区伙伴们的广泛认可。
为了表示对五位明星贡献者的感谢和认可，社区将给予五位奖励。奖品是由赞助方——人民邮电出版社提供的精美书籍一本（由贡献者自行挑选），同时明星贡献者名单将在 Jenkins 中文社区官网进行展示。
奖品展示    成员 奖品     donghui 《人生护城河 如何建立自己真正的优势》   李楠 《持续交付 2.0 业务引领的 DevOps 精要》   yJunS 《精通 jQuery(第二版)》   李煜东 《算法 第四版》   书生 《极简主义——风靡欧美的工作与生活理念》    通过此次活动，让我们再次感觉到了伙伴们参与社区活动的热情! 社区也更加充满动力，会持续举办明星贡献者激励活动!
为对 Jenkins 中文社区做出卓越贡献的伙伴们谋取更多福利! 第三届激励活动已经在路上，敬请期待。。。
欢迎广而告之，让更多有着同样理想的伙伴们加入我们的社区! 让更多人一起共建开放、包容、活跃的 Jenkins 社区！
相关说明: 感谢 Jenkins 中文社区赞助商—人民邮电出版社提供的奖品赞助，感谢积极参与投票的各位社区伙伴。如果有好的意见或者建议欢迎随时联系我们!!
历次的激励名单请查看 https://jenkins-zh.cn/about/star-plan/</description>
    </item>
    
    <item>
      <title>庆祝开源人线下见面会圆满结束</title>
      <link>https://jenkins-zh.github.io/wechat/articles/2019/08/2019-08-30-open-source-meeting/</link>
      <pubDate>Fri, 30 Aug 2019 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.github.io/wechat/articles/2019/08/2019-08-30-open-source-meeting/</guid>
      <description>什么是开源精神、为什么以及如何参与开源、开源与个人以及企业之间的关系、开源社区存在的重要意义、996是否与开源背道而驰。
 活动介绍 于2019年8月24日（周六）下午2点举办的开源人线下见面会圆满结束啦。本次活动是由Jenkins 中文社区与开源社首次联合主办的一次以社区、开源为主题的活动。
活动主要分为几个部分： * 签到 * 嘉宾演讲 * Panel * 活动复盘
嘉宾介绍 赵晓杰 Jenkins 中文社区发起人
热衷于传播开源理念、开源技术。多年研发经验，目前关注于 DevOps 领域，尤其是持续交付方面。
刘天栋 Ted 开源社理事长暨联合创始人、Apache 软件基金会正式会员
开源社理事长暨联合创始人， Apache 软件基金会正式会员，ASF孵化器项目委员会成员/导师，ASF 筹款委员会成员/赞助伙伴大使，中国信息通信研究院。云计算开源产业联盟.特聘开源治理个人顾问。于2014年10月联合创始开源社。于2018年当选 ASF 正式成员，随后加入 ASF 筹款委员会并成为赞助伙伴大使，2019年成为 ASF 孵化器项目委员会成员，并担任孵化项目（ECharts）导师。 曾历任微软中国战略业务总监、微软开放技术公司及微软亚太研发集团负责开源技术布道及开源社区发展工作；甲骨文(中国)渠道及联盟总监、甲骨文(中国) Linux 战略总监、甲骨文大中华区中间件事业部总经理；Turbolinux 亚太区副总裁等。
慕睿涛 北京卓晟互联网络技术有限公司 CTO
毕业于北京工业大学，2003年加入 Sun Microsystems，负责嵌入式 Java 虚拟机的研发。曾于2008年创建了 PSP 上的JavaME 模拟器项目——PSPKVM，在 PSP 自制软件社区有很高的普及度。目前在北京卓晟互联网络技术有限公司任 CTO ，创建并主持了 JOSH 开源项目，致力于为微小型物联网终端设备提供 Java 应用开发与运行环境。
曹勇华 Chatopera 软件工程师
从事3年软件开发工作，掌握全栈开发技能，熟悉JavaScript、Java和Node.js等。目前在Chatopera从事春松客服，聊天机器人平台。春松客服是帮助中小型企业快速而低成本的获得好用的智能客服系统。
演讲环节  赵晓杰分别从扁平~等级、自由～局限、多样~单一、社区精神等几个层面为我们讲解了他对于开源以及开源社区的理解，很客观地从这几个方面把开源的意义进行了剖析。  刘天栋 Ted为我们讲解了Apache 之道：从孵化器到顶级项目之路，生动地讲解了 Apache 之道20年如一日的态度持续为公众提供软件以及软件项目社区提供服务和支持。并且讲解了 Apache 如何从一个孵化器逐步成长为全球最大的开源基金会，令在场的听众听的可谓是如痴如醉。  慕睿涛为我们讲解了他在 Sun 公司的一些经历，以及跟开源开始结缘的一些事宜。从自由软件运动回顾、自由的代价、开放标准与开源代码、Android 与 Java 的纷争、Android 与 Linux 社区的分歧几个方面回顾与分析了开源与开放的本质区别。   panel 环节 此环节的主题为开源社区的发展和维护，由赵晓杰、刘天栋、慕睿涛、曹勇华等4位嘉宾进行了小组讨论。大家就社区而言比较了国内社区与国外社区环境的差别、从公司与社区等不同角度进行了分析，大家分别发表了自己的一些见解和看法。并且对于国内996的环境因素纷纷发表了自己对一些看法。 活动复盘环节 在复盘环节，现场观众纷纷发表了大家对一些看法，以及对于本次活动对一些态度。据现场观众描述，活动举办还是比较成功的，纷纷表示均有不少收获。 以下是现场观众对本次活动的一些建议： * 活动话题&amp;ndash;因为是 Jenkins 中文社区举办，所以大家在潜意识中认为可能会跟 Jenkins 相关，希望可以在活动介绍中把活动主题注明 * 活动议题&amp;ndash;在未参加活动前，大家对活动的议题不太了解，希望可以提前获知，并且可以提前将自己的问题准备好，提高效率 * 分享内容不完整&amp;ndash;因为时间关系，有些演讲嘉宾的内容没有全部分享完，令现场观众心中会有遗憾 * 互动比较少&amp;ndash;在活动中，嘉宾与现场观众的互动较少，提问环节时间较短 * 提前发通知&amp;ndash;希望可以在活动开始前几天提前通知。我们是通过邮件通知的，如果能在活动前加到微信群里的话，效果会好一些 * 设置专场&amp;ndash;希望可以设置不同专场，大家根据不同的专场参加</description>
    </item>
    
    <item>
      <title>AWS 上的云原生 Jenkins</title>
      <link>https://jenkins-zh.github.io/wechat/articles/2019/08/2019-08-23-cloud-native-jenkins-on-aws/</link>
      <pubDate>Fri, 23 Aug 2019 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.github.io/wechat/articles/2019/08/2019-08-23-cloud-native-jenkins-on-aws/</guid>
      <description>我们使用 Jenkins 搭建持续交付流水线，和其他很多团队一样，这些年我们围绕 Jenkins 创建了很多工作流程和自动化。Jenkins 是我们团队取得成功的关键，让我们能够在上一季度顺利进入生产677次，搭建及部署时长平均为12分钟。
我们的大部分应用和基础设施可以看作云原生，但当时 Jenkins 服务并不完全适合这个分类：服务在单个服务器上运行，同时很多任务直接在 master 上运行，其部分手动配置包括 secret、插件、定时任务和 startup hacking 的普通膨胀，该膨胀是自2014年首次搭建起不断累积而成。
Jenkins 不仅变成了单体服务和单点故障，而且拆除及重建 Jenkins 对企业也是很大的风险。
我们决定必须做出改变。这篇博客说明了我们如何运用 Terraform、Packer、Docker、Vault、和 ELB、ASG、ALB 或 EFS 等 AWS 服务实现 Jenkins Cloud-native，以及我们一路走来的收获。
Jenkins 状态 当时不得不面对的关键问题是：如果我们将 Jenkins 服务置于一个容器/自动缩放实例中，我们需要恢复何种状态？
问题的答案并不简单，值得一提的是，有个 Jenkins 特别兴趣小组（SIG）已经识别出所有导致这一 Jenkins 状态的存储组件。这是一个很棒的起点，因为我们至少得确保那篇文章列出的所有存储类型都考虑在内。
捷径 这不是新问题。很多团队使用 Docker 容器运行 Jenkins，官方 Jenkins Docker 镜像也得到良好维护。如《Jenkins Dokcer 镜像》文档中解释的：
docker run -p 8080:8080 -p 50000:50000 -v jenkins_home:/var/jenkins_home jenkins/jenkins:lts  这会把 workspace 存在 /var/jenkins_home。所有的 Jenkins 数据（包括插件和配置）都存在上述目录里。创建一个明确的 volume 可以方便管理和附加到另一个容器进行升级。
上述示例装载主机上的 jenkins_home，其中包括所有 Jenkins 状态。然后该目录可以存在一个外部磁盘上，比如 Kubernetes 持久化存储卷。或者，如果 Jenkins 在 EC2 上运行，该目录可存在一个外部 EBS 或 EFS 卷上。</description>
    </item>
    
    <item>
      <title>开源持续交付黑客松，5000大奖等你来拿</title>
      <link>https://jenkins-zh.github.io/wechat/articles/2019/08/2019-08-19-hackathon-signup/</link>
      <pubDate>Mon, 19 Aug 2019 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.github.io/wechat/articles/2019/08/2019-08-19-hackathon-signup/</guid>
      <description> 你是否希望与顶尖编程高手同场较量，是否想体验创意与技术的碰撞？黑客松编程比赛释放你的激情，满足冠军梦想。
黑客松编程比赛报名正式拉开帷幕。本次赛事以 DevOps 为主题集结研发、测试、运维、产品、文档、HR等各路人马，秉承开源开放的方式，旨在为各个行业面临的 IT 挑战提出解决方案，鼓励人人参与开源社区，展现开源之魅力。
本次比赛为期两天，由 Jenkins 中文社区联手 CloudBees、京东云、阿里云、码云、开源社和微软组织承办。选手要在48小时内根据所选议题设计解决方案，在有限的时间内激发无限创意想法。
比赛规则  活动中创建的新代码仓库均在码云上的 Jenkins 中文社区进行托管，任何人都可以根据对应开源协议进行修改、分发等操作。 所有代码工作（包括文档、设计等）必须当场完成。若提前准备或抄袭，一经发现，将取消当年及次年的比赛资格。 所有项目必须可以做到持续构建，持续交付和灰度发布则为加分项。 推荐与不同技能的小伙伴组建3人左右的团队，一起完成项目。  评选标准 团队协作、完整性、创新程度、难易程度、大众评分
报名方式 本次比赛通过第三方平台“活动行”进行线上报名。组团报名满3人可享9折优惠，欢迎公司组团报名。 请点击开源持续交付黑客松或扫描下列二维码报名参赛。
报名说明 选手须年满十八周岁且熟练使用码云。需要注意的是，报名者选定项目提议后，在报名时必须提供与所选项目相关且于活动发布后合并了的 PR 链接，我们将根据该链接决定是否通过报名。
报名成功后，选手需给出明确项目提议，即有待完成的具体功能列表和需要修复的缺陷列表等。请注意，只有审核通过的项目提议可以在最后的线下活动继续比赛。
上述流程必须在报名截止日期9月30日之前完成。后续通知可通过关注 Jenkins公众号获得。如果你对 Jenkins 技术交流感兴趣，可以在公众号后台回复“社区活动”来加入我们的微信群。
奖项设置  冠军项目，5000元 亚军项目，2000元 入围项目，500*2元  项目提议  Kubernetes 插件优化  所需技能：Kubernetes、Java  Jenkins 中文社区网站改版  所需技能：Hugo、Markdown、JavaScript、CSS  Jenkins 命令行工具 jcli  所需技能：Golang、Jenkins API  Jenkins 微信公众号后端服务  所需技能：Golang、微信公众号 API  Jenkins Java 语言客户端  所需技能：Java、Jenkins API  微信机器人  所需技能：JavaScript   </description>
    </item>
    
    <item>
      <title>提名 Jenkins 中文社区激励候选人</title>
      <link>https://jenkins-zh.github.io/wechat/articles/2019/08/2019-08-17-award/</link>
      <pubDate>Sat, 17 Aug 2019 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.github.io/wechat/articles/2019/08/2019-08-17-award/</guid>
      <description>Jenkins 中文社区是由 Jenkins 国内的爱好者、贡献者组成，共同推广以及完善 CI/CD 技术的学习试用和落地。我们非常欢迎每一位同学为社区贡献自己的一份力量，相应的我们会给予杰出贡献者奖励以表示认可和感谢，同时也欢迎更多对社区活动感兴趣的同学加入! 社区贡献激励是一个旨在长期为社区贡献者谋福利的活动，因此社区每三个月就会举办一次激励活动，惊不惊喜，激不激动! 第一期激励活动已经圆满落下帷幕，让我们再次恭喜三位明星贡献者——donhui，zacker330，yJunS，感谢三位对社区做出的杰出贡献，此处应该有掌声!!
Hold on!! 没有赶上第一期活动的同学们，请往这里看——第二期激励投票活动马上开始了，在这个炎热的夏天，让我们一起行动起来吧!
评选规则: 社区秉承公平、公正、公开的原则，希望每位社区贡献者都有机会参与评选，本次活动将采取邮件征集投票的方式，选出本期社区突出贡献者
参评标准:  翻译 Jenkins 相关文章 Jenkins 中文本地化 发表 Jenkins 原创文章 Review PR 在 Jenkins 中文社区有开源贡献（eg: 提交新的特性代码，提交补丁优化代码，撰写和改进项目的文档 etc.） 积极参与 Issue 的讨论，如答疑解惑、提供想法或报告无法解决的错误 组织社区活动 Meet up 其他重大贡献  投票规则:  请各位同学请选出心目中最佳贡献者，发送邮件至 admin@jenkins-zh.cn 可以推荐一位或者多位候选人 请在邮件正文中标注推荐的候选人信息:  GitHub ID 微信号 推荐理由（理由要切实与本社区相关的哟，不要因为小哥哥小姐姐太好看就给投票哈）  邮件投票截止时间2019年8月28日23点59分——我们会在社区的例会上对从邮件中征集的候选人进行公开投票，最终选出五位最佳贡献者给予奖励（从直接参与社区贡献的人中挑选四位，从社区技术群积极帮助他人的人中挑选一位） 贡献激励: 加入 Jenkins 社区贡献者名单，并展现在 Jenkins 中文社区官网——获得由与社区合作的人民邮电出版社提供的技术书籍 有机会成为线下技术沙龙特邀嘉宾   相关说明: 评选结果将在 “Jenkins 官方微信公众号”进行公布——合作的出版社将直接邮寄奖品。
激励让社区活动更加有趣，让我们一起构建伟大，无所不能。还不快快行动，让更多的人因为你的贡献打开通往新世界的大门!</description>
    </item>
    
    <item>
      <title>持续交付黑客松--导师招募</title>
      <link>https://jenkins-zh.github.io/wechat/articles/2019/08/2019-08-16-tutor-recruitment/</link>
      <pubDate>Fri, 16 Aug 2019 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.github.io/wechat/articles/2019/08/2019-08-16-tutor-recruitment/</guid>
      <description>  Jenkins 中文社区计划于2019年10月25日发起一场以 DevOps 为主题的黑客松编程比赛，我们将以开源、开放的方式策划、组织本次活动。开源&amp;ndash;黑客松上产生的所有代码、文档甚至想法都是开源的，都会托管在国内最大的代码托管网站&amp;ndash;码云上。开放&amp;ndash;任何岗位、背景的人都可以参与我们的活动，不仅仅只有研发、测试、运维等岗位的同学，我们非常欢迎文档工程师、产品经理、敏捷教练的加入，甚至 HR、PR 的同学也可以来参与。
 集结这么多具有不同技能的同学后，我们希望能解决什么问题呢？我们希望让大家切实地体会到，参与开源并没有你想的那么困难、无趣，也绝不仅仅只有键盘侠的 Coding 独秀，人人都可以参与开源社区。通过开源社区可以集中解决很多通用性的问题，通过开源的黑客松活动，更是可以集中地解决我们在使用开源的持续交付方案中遇到的诸多通点。
主办方  Jenkins 中文社区  合作方  CloudBees 码云 京东云 开源社 微软  导师招募 如果你在 - Java、JavaScript、Golang、css、Hugo - K8S 、Jenkins、Jenkins API - CI/CD、敏捷等 DevOps
等相关领域有丰富的经验、独到的见解，包括且不限于以上领域，欢迎踊跃报名成为黑客松活动的导师。我们会认真、仔细地筛选符合条件的报名者。
我们热切期盼你的到来，指导参赛队取得好成绩！
 要求导师在某个领域工作至少5年以上
 报名方式 发送邮件到event@jenkins-zh.cn，内容如下，请如实填写（注： GitHub ID 示例：https://github.com/githubId）：
活动名称： 姓名： 公司名称： 所在地： 部门： 职务： 联系电话： 微信号： GitHub ID: T 恤尺码: 个人简介（若您被选中导师，以下信息将发布在网站及海报上，请仔细填写）：如工作经验、是否带过团队等信息 技术指导方向：参考项目提议选择指导方向 是否指导过黑客松比赛：  导师相关义务  积极配合议题的评审工作，以确保解决方案的高质量 比赛期间（10.25晚-10.27晚），请与指导团队准时到达比赛现场 协助活动组织者在微信等宣传渠道宣传本次活动 比赛结束后分享比赛心得及经验  你将获得  收获业内同行间最有价值的碰撞结果 K8S、Jenkins、Docker 等先进工具最佳实践案例 DevOps 、敏捷等方法的实际落地法 建立同行业人脉关系 树立个人行业影响力 为您的团队招揽精英  </description>
    </item>
    
    <item>
      <title>Jenkins 可视化阶段视图的改进</title>
      <link>https://jenkins-zh.github.io/wechat/articles/2019/08/2019-08-15-jenkins-pipeline-stage-result-visualization-improvements/</link>
      <pubDate>Thu, 15 Aug 2019 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.github.io/wechat/articles/2019/08/2019-08-15-jenkins-pipeline-stage-result-visualization-improvements/</guid>
      <description>最近发布了的一些变更给了流水线编辑者新的工具以改善在 Blue Ocean 中的流水线可视化，有一个备受瞩目关注的工单JENKINS-39203，这会导致当流水线的构建结果为不稳定时所有的阶段都被设置为不稳定的。这个缺陷导致无法快速地识别为什么构建是不稳定的，使得用户必须查看完整的日志和 Jenkinsfile 才能弄明白究竟发生了什么。
为了修复这个问题，我们引入了一个新的流水线 API 用于为单个流水线步骤添加额外的结果信息。像 Blue Ocean 这样的可视化工具在决定阶段如何显示时会使用到这新的 API。像 junit 这样的步骤只能设置整个构建结果，现在可以通过新的 API 设置步骤级别的结果信息。我们创建了新的步骤 unstable 和 warnError，这样流水线编辑者在更复杂的场景下仍然可以利用这个新的 API。
该问题涉及到的重要的修复包含在如下的插件中，它们都需要 Jenkins 2.138.4 以及更新的版本：
 Pipeline: API 2.34 Pipeline: Basic Steps 2.18 (需要同步更新到 Pipeline: Groovy 2.70) Pipeline: Graph Analysis 1.10 Pipeline: Declarative 1.3.9 Blue Ocean 1.17.0  这里是一条使用了 unstable 步骤的流水线在 Blue Ocean 中的截图，只会把失败的阶段标识为不稳定的：
例子 这里给出一些如何在你的流水线中使用该特性的示例：
 使用新的步骤 warnError 用于捕获错误，并把构建和阶段标记为不稳定的。 warnError 只需要一个 字符串 的参数，用于当捕获到错误时以日志的形式输出。当 warnError 捕获到一个错误时，它会记录该消息以及错误，并设置构建和阶段的结果为不稳定的。效果如下：  warnError(&#39;Script failed!&#39;) { sh(&#39;false&#39;) }   使用新的步骤 unstable 设置构建和阶段结果为不稳定的。可以使用该步骤直接替换 currentBuild.</description>
    </item>
    
    <item>
      <title>持续测试的那些事</title>
      <link>https://jenkins-zh.github.io/wechat/articles/2019/08/2019-08-14-continuous-testing-what-why-and-how/</link>
      <pubDate>Wed, 14 Aug 2019 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.github.io/wechat/articles/2019/08/2019-08-14-continuous-testing-what-why-and-how/</guid>
      <description>敏捷，DevOps 和持续交付已然存在于现今每个技术人员的词汇当中。我们都想要像硅谷里的巨头和初创公司一样，敏捷开发，快速发布软件，做出创新的产品。 向敏捷转型在多方面都已有总结，并且到了能被顺利实践的程度。然而，测试仍然是一个有思想困惑和实践挑战的领域。 当软件发布周期从以年、月缩短到以周、天为单位，或者更短时； 我们该如何重塑测试实践，以保证当软件发布到生产环境时能令用户满意， 而不是掉链子？
鉴于大多数 DevOps 实践仍然把测试视为软件生产中最令人头疼的瓶颈，显然，这是一个常见的挑战。
持续测试就是答案，但持续测试究竟是什么？你又如何实现它呢？ 维基百科定义持续测试为「在软件交付流水线中执行自动化测试的过程，目的是为了获得关于预发布软件业务风险的即时反馈」。 但是这个定义缺少了本质，缺少了持续测试所示意的转变的量纲。 除了自动化是一个重要的部分以外，持续测试从根本上转变了测试， 它把线性过程中的时间点事件嵌入到整个过程当中去，作为基础贯穿于整个软件交付周期的所有活动中。
敏捷环境里持续测试的目标应该是「迭代内测试（in-sprint testing）」。 不管你的迭代是两周还是四周，目标都应该是完成迭代内所有类型的测试，这样每个迭代都可以得到一个测试完备的，准备交付的软件。 事实上很多持续交付的最佳实践都会告诉你，你不能简单的在没有持续测试的情况下去做持续交付。 如果你认为你的迭代时间不允许你去做一个综合的测试，很有可能是你对它的理解有误。
七个步骤实现持续测试 1. 尽早规划测试，甚至早于写代码 描述不清的要求或者有不正确的理解，都可能导致返工甚至延期。 使用像行为驱动开发(BDD)， 验收测试驱动开发(ATDD)和 基于模型的测试这类技术所使用的工具，如 cucumber/gherkin 和 CA Agile Requirements Designer (ARD)， 可以确保业务主管，产品经理，开发人员和测试人员充分沟通并记录需求，定义清晰的测试用例，提早编写测试脚本，以达到一个流畅的测试过程。
2. 优化测试覆盖率 一些组织默认「每次运行所有的测试」来保证代码覆盖率。这不但浪费资源还延长了测试周期，而且没有真正的保证代码覆盖率。 测试那些需要测试的部分，以节省时间、金钱和资源。可视化模型可以让各种路径被探索优化，以便只用少量的测试用例就能提供最大化的覆盖率。 可以借助 Rally, Jira, HP ALM, JIRA 等此类工具导入测试用例、移除重复用例、分发优化过的用例。
3. 测试左移 为了实现「迭代内(in-sprint)」测试，将测试前置——这样测试可以在开发周期的早期运行。开发人员自己测自己的；卓越中心提供专家，定制系统和服务。 自动化测试覆盖 UI, 功能，性能和安全。各个团队一起工作，一起以要交付给客户的业务价值为专注点。这需要对开发者友好的工具以及文化转变。
4. 提供完整的测试环境 提供测试环境的能力对实现持续测试是至关重要的。 通过友好型（例如编码、CI/CD 集成、被开源支持的软件）开发工具按照需求提供的完整的测试环境来消除障碍和减少等待时间。 这些环境应该包括：
 虚拟服务——给那些不可达，不可访问的，还在开发中的服务提供鲁棒的模拟。开发和测试可以根据虚拟服务模拟实际服务返回的结果持续并行工作。 按照需求测试数据——帮助并保证各个团队可以使用与生产环境类似的数据来运行综合的测试。 预发环境——准备上线的需求，使用后退役。  5. 获取正确的测试数据 在很多应用发布周期，获取鲁棒性测试数据能力的缺乏会造成严重延期。为了准确的测试新功能，测试数据应该尽可能的跟生产环境时所应用遇到的数据相近。 如果测试数据缺乏特定真实世界的特征（例如具体字段、数据定义、负面场景等），测试就很难找到许多潜在问题和应用的弱点。 理解数据模型并提取出正确的数据是一种特殊的技巧。尽管使用生产环境数据测试是最接近真实的，但数据隐私条例通常都会限制使用生产数据。 下面，我们来看看 CA Test Data Manager 是如何复制生产数据，抹掉敏感信息的同时保持了测试所希望的生产数据特征（接近现实，并且多行指征完整）的。 生产数据不可用时，测试数据也可以使用 TDM 工具根据模版生成。</description>
    </item>
    
    <item>
      <title>持续交付黑客松--志愿者招募</title>
      <link>https://jenkins-zh.github.io/wechat/articles/2019/08/2019-08-09-volunteer-recruitment/</link>
      <pubDate>Fri, 09 Aug 2019 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.github.io/wechat/articles/2019/08/2019-08-09-volunteer-recruitment/</guid>
      <description>Jenkins 中文社区计划于2019年10月25日发起一场以 DevOps 为主题的黑客松编程比赛，我们将会以开源、开放的方式策划、组织本次活动。开源——黑客松上产生的所有代码、文档甚至想法都会是开源的，都会托管在国内最大的代码托管网站——码云上。开放——任何岗位、背景的人都可以参与我们的活动，不仅仅只有研发、测试、运维等岗位的同学，我们非常欢迎文档工程师、产品经理、敏捷教练的加入，甚至 HR、PR 的同学也可以来参与。
 集结这么多具有不同技能的同学后，我们希望能解决什么问题呢？我们希望让大家切实地体会到，参与开源并没有你想的那么困难、无趣，也绝不仅仅是只有键盘侠的 Coding 独秀，人人都可以参与开源社区。并且，通过开源社区可以集中地解决很多通用性的问题，通过开源的黑客松活动，更是可以集中地解决我们在使用开源的持续交付方案时遇到的诸多痛点。
主办方  Jenkins 中文社区  合作方  CloudBees 码云 开源社 微软  志愿者招募 如有意愿参与黑客松活动，欢迎踊跃报名。我们会认真、仔细地筛选符合条件的报名者。
报名方式 发送邮件到event@jenkins-zh.cn，内容如下，请如实填写（注： GitHub ID 示例：https://github.com/githubId）：
活动名称： 姓名： 公司名称（选填）： 所在地： 职业： 联系电话： 微信号： GitHub ID: T 恤尺码: 个人擅长： 参加志愿者的初衷：  志愿者职责划分  文案、宣传 拍照/摄像 签到、场地布置 场地秩序维护、活动事项解答、物品库存管理等  志愿者职责说明 依据不同志愿者的职责分工，志愿者需提前对自己对职责做一个大概对计划表，提前与社区活动相关负责人员相互沟通，尽量减少在活动中遇到突发事件对情况以及对可能遇到突发事件的情况做好应对方案。
志愿者福利 我们会根据志愿者的实际参与情况，给予志愿者相应福利： * 免费参加自本活动启动时一年内的所有活动 * 活动纪念品 * 赠送与本社区有合作关系的其他公司或者社区组织的活动门票</description>
    </item>
    
    <item>
      <title>Jenkins X 新 logo</title>
      <link>https://jenkins-zh.github.io/wechat/articles/2019/08/2019-08-08-jenkins-x-new-logo/</link>
      <pubDate>Thu, 08 Aug 2019 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.github.io/wechat/articles/2019/08/2019-08-08-jenkins-x-new-logo/</guid>
      <description>早在2018年3月，Jenkins X 项目作为 Kubernetes 自动化 CI/CD 的 Jenkins 对应项目突然出现。作为这次发行的一部分，它的 logo 是 Jenkins logo 的一个变种，一个叼着烟斗的船长，他的帽子上有 Kubernetes logo。
在软件中，我们喜欢说命名是困难的——因为确实如此。另一件同样困难的事情是试图在 logo 中捕捉项目的本质。Logo 在一个小空间里有很多意义。Icon ，例如 Jenkins logo，与许多开发人员建立强烈的情感联系。因此，考虑到这一点，我们总是密切听取有关新 logo 的反馈，以及人们如何看待这个项目。
为什么我们要改变 logo 在听取各种不同来源的各种反馈时，我们听到了许多积极的事情，但也强调了一些问题和困惑。
 并不是每个人都喜欢这个 logo，我们听到了不少关于人们不喜欢它的方面的反馈意见，其中“叼着烟斗”这个反馈意见排在最前面。 与 Jenkins 项目的混淆——我们也看到这个 logo 与 Jenkins 的其他吉祥物更加一致，这导致了关于 Jenkins X 是什么类型的项目的混淆——一些人认为这是生态系统中的另一个插件。 我们还听说，使用 Kubernetes logo 令人困惑，或可能并非完全在 Kubernetes logo 指南的范围内。 从实用的角度来看，我们也听说这个 logo 太详细了，因此不能很好地作为一个 icon，尤其是一个 favicon。它被看作是吉祥物而不是 logo。  随着持续交付基金会的成立，Jenkins X 是基金会创始项目之一，区别于 Jenkins，我们觉得是时候处理这个反馈了。所以我们真的回到了画板上，思考什么样的 logo 可以更好地代表 Jenkins X 作为一个项目。我们考虑了我们希望人们与项目相关联的内容：开源、持续交付、速度、自动化、稳定性、团队等等。我们也想要一个 logo，可以提高代表性，所以我们想要避免一个基于人的 logo，它可能会无意间编码性别、年龄和其他因素。此外，“X” 已经成为项目 logo 的一个独特部分，所以我们想在新 logo 中真正强调它。</description>
    </item>
    
    <item>
      <title>开源持续交付黑客松--号角声起</title>
      <link>https://jenkins-zh.github.io/wechat/articles/2019/08/2019-08-07-hackathon-startup/</link>
      <pubDate>Wed, 07 Aug 2019 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.github.io/wechat/articles/2019/08/2019-08-07-hackathon-startup/</guid>
      <description>  Jenkins 中文社区计划于2019年10月25日发起一场以 DevOps 为主题的开源黑客松编程比赛，该活动旨在为当下金融、能源、政务、交通等场景面临的 IT 挑战提出解决方案，我们希望本次赛事期间您也能够收获业内同行间最有价值的碰撞成果。
 本次活动由 Jenkins 中文社区主办，并由受到 Cloudbees、码云、京东云以及开源社等合作伙伴的大力支持。我们非常欢迎关心和关注开源以及持续交付的企业以及社区加入或者支持我们。有意与我们合作，可以在 Jenkins 公众号后台回复，或者发送电子邮件到 admin@jenkins-zh.cn。
比赛规则 活动中创建的新代码仓库，都会托管在 Jenkins 中文社区托管在码云上的组织下 。因此，任何人都可以根据对应的开源协议进行修改、分发等。
 所有的代码（或文档、设计等）工作，必须在现场完成，如有发现提前准备或者抄袭者，将会被取消当年以及次年的比赛资格 所有项目必须可以做到持续构建，能做到持续交付、灰度发布的项目可以加分 推荐与不同技能的小伙伴组成3人左右的团队，一起完成项目  评选标准：团队协作、完整性、创新、难度、大众评分
报名说明 年满十八周即可报名参加，鉴于我们的所有项目都会托管在码云上，因此，参赛者必须能够熟练地使用码云。而为了能够证明你能够完成本次活动中的项目，当你从下面的项目提议中选定一个后，在报名时必须提供一个与你所选项目相关的、自本活动发布后的、已经合并了的 PR 链接，我们会根据该 PR 链接来决定你的报名是否可以通过。
报名成功后，需要给出明确的项目提议——要做的具体功能列表、修复的缺陷列表等。请注意，只有审核通过的项目提议才可以在最后的线下活动中继续参加比赛。
上述过程必须在“报名截止”之前完成。具体报名方式，请关注 Jenkins 公众号后续的通知，或者在 Jenkins 公众号后台回复“社区活动”后加入我们的微信群。
项目提议  Kubernetes 插件优化  所需技能：Kubernetes、Java  Jenkins 中文社区网站改版  所需技能：Hugo、Markdown、JavaScript、CSS  Jenkins 命令行工具 jcli  所需技能：Golang、Jenkins API  Jenkins 微信公众号后端服务  所需技能：Golang、微信公众号 API  Jenkins Java 语言客户端  所需技能：Java、Jenkins API  微信机器人  所需技能：JavaScript   奖项设置  悬赏项目（1～2个） 冠军项目（1个） 亚军项目（2个） 入围项目（若干）  活动安排  8月1日～8月31日  议题征集  9月30日  报名截止  10月25日～10月27日  比赛时间（以下为比赛日的时间）  10月25日（周五）晚上七点～八点  签到  10月25日（周五）晚上八点～九点  比赛动员宣讲  10月25日（周五）晚上九点～10月27日（周日）下午四点  持续创作  10月27日（周日）下午四点～晚上七点  作品评选  10月27日（周日）晚上七点～晚上八点  颁奖仪式   </description>
    </item>
    
    <item>
      <title>在大型企业里维护多分支流水线</title>
      <link>https://jenkins-zh.github.io/wechat/articles/2019/08/2019-08-05-jenkins-multi-branch-pipeline/</link>
      <pubDate>Mon, 05 Aug 2019 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.github.io/wechat/articles/2019/08/2019-08-05-jenkins-multi-branch-pipeline/</guid>
      <description>Jenkins 是 DevOps 领域里非常好的 CI/CD 工具，它凭借其独特的功能，几乎可以满足你一切的的业务要求。其中一个独特的功能是多分支流水线(Multi-branch 流水线)，可以动态配置流水线。但是，随着公司的发展，单独的多分支流水线并不能完全满足你的所有需求，特别是在涉及大型企业时，你需要考虑流水线的集中管理，治理，稳定性，限制和安全性等其他事项。因此对于具有 Jenkins 流水线的大规模 CI/CD 环境，你需要添加之前没有想到的更多功能。
动态配置流水线 当一个开发人员创建一个新分支并将其推送到远程代码仓库时，Jenkins 会为这个新分支动态创建流水线。根据代码仓库，甚至也可以作为动态创建 Pull Request 流水线。这个动态功能在使用 Feature 分支或其他类似功能的团队中非常有用，由于本文的主题不是多分支流水线，你可以在端到端多分支流水线项目创建中找到详细信息和一些示例。
流水线即代码 在多分支流水线中，脚本存储在项目代码仓库中，这就是“流水线即代码”的概念。此外，当你拥有小型开发人员团队或项目没有大量分支时，它非常有用。这样，开发人员可以根据需要更改流水线，将更改推送到分支，并立即看到更改生效，但对于拥有数百或数千名拥有大量项目的开发人员的大型企业而言，这种方案就完成不可行了。
集中式库 当你的团队或项目增加时，是时候考虑一种方法，比如通过共享的的方式应该在所有项目中。从长远来看，这种“集中式库”变得非常关键，因为随着规模的扩大，流水线中出现了新的要求或变化，在这种情况下，手动更改每个流水线或脚本对管理员来说将是一场噩梦。因此，如果你在一个地方进行更改并且每个流水线都得到更新，那么拥有该集中式库将更加实用。这是 Jenkins 共享库概念的用武之地。有关详细信息，你可以访问该站点。
即使你只有一个流水线，仍然可以使用集中式库。
治理与稳定 如果你的团队有对 CI/CD 一定了解的开发人员，并且你确信他们不会做出重大更改或编写脚本错误导致影响环境的稳定性，那么将流水线脚本放在代码中是很好的。但是，你真的确定吗？
有人很可能会意外删除流水线文件或者可能出现小错误，这些小错误都会影响 CI/CD 的稳定性。如果你在早期发现这些错误时很容易解决这些错误，如果没有，这些微小的变化或错误将可能比你想象的更严重的影响 CI/CD，它将被传播到不同项目中的所有分支或 tag，这会变得很难解决。
你需要将正确的流水线脚本推送到所有分支和/或代码仓库，或是要求每个开发人员提取最新的脚本，这种类型的问题集中式库这种更高级的方式来解决，除此之外，你的环境会因为有人可能会删除 Jenkins 文件或输入一些拼写错误带来风险。
远程文件插件 为了消除不必要的更改的风险并降低使用的库的复杂性，我们需要以某种方式将流水线脚本与项目/代码代码仓库分开，同时仍继续使用多分支流水线功能。为此，我们有远程文件插件。
这个插件使多分支流水线能够从其他代码仓库运行/加载流水线脚本，而不是将它们放在项目/代码代码仓库中，通过这个功能，你可以拥有一个单独的代码仓库，你可以在其中放置所有流水线脚本，并且只能为你自己提供访问权限。这样，你将拥有与集中式库相同的集中式流水线脚本代码仓库。此外，你可以将流水线脚本存储在集中式库本身中。
这个功能的好处是除了有访问权限的人之外，没有人能够在流水线脚本中进行更改。你在集中流水线脚本中所做的任何更改都将影响使用该脚本文件的所有多分支流水线。这样，你无需等待所有开发人员获取更新版本或将脚本推送到所有代码仓库上的所有分支。
另一个好处是，如果你将集中式流水线脚本放入 BitBucket 或 GitHub 等代码仓库中，你还将拥有代码审查功能。这样，你可以与其他人共享代码仓库，同时仍可限制或查看其他人所做的更改。
结论 在大型企业中创建 CI/CD 流水线并不容易，你需要考虑治理，限制，稳定性和安全性等概念。在此上下文中，借助 Jenkins 的其他功能，Remote File Plugin 提供了一个独特的功能，用于集中，维护和共享流水线脚本。
有关插件的详细信息，你可以访问插件的 Wiki 页面。</description>
    </item>
    
    <item>
      <title>Jenkins 流水线配置历史插件介绍</title>
      <link>https://jenkins-zh.github.io/wechat/articles/2019/07/2019-07-31-pipeline-config-history-plugin/</link>
      <pubDate>Wed, 31 Jul 2019 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.github.io/wechat/articles/2019/07/2019-07-31-pipeline-config-history-plugin/</guid>
      <description>流水线是在 Jenkins 中创建任务的有效的和现代的方式。 为了快速、简单地识别流水线变更，我们开发了流水线配置历史插件。 这个插件检测流水线的变更，并为用户提供一个选项，以明显地、可追溯地查看流水线配置两次构建（差异）之间的变更。
一切是如何开始的 这一切开始于十年之前 —— 经典的任务类型 (例如：自由风格、Maven 等等)。 每隔一段时间，用户就会联系我们，因为他们的任务无法在一夜之间完成。 为什么这个任务失败了呢？ 这次失败和任务配置变更有关系吗？ 用户典型的回答是：&amp;rdquo;我们没有改任何东西&amp;rdquo;，但这是真的吗？ 我们思考了这个问题，并决定开发一个插件来帮助我们解决这个问题。 这就是plugin:jobConfigHistory[任务配置历史]的想法和开始。
现在可以查看任务配置的变更(例如其他分支、JDK版本等)，而且更常见的情况是，破坏构建的原因是任务配置的变更。
多年来，该插件得到了开发，目前仍在开发中。 添加了新的功能，不仅可以查看任务配置，还可以查看全局和代理配置的变更。 还可以恢复旧的配置版本。 如今，这个插件已经有超过30,000次安装量。 多年来，JobConfigHistory 减轻了我们的日常工作 —— 我们有超过3000个 Jenkins 任务！ 然后出现了一种新的任务类型：流水线。
流水线 —— 需要一些新的东西 流水线任务和经典的任务类型有根本地区别。 经典的任务类型是通过 Jenkins GUI 配置的，而流水线任务是配置即代码。 实际上，每个流水线任务都是通过 Jenkins GUI 创建的，然而这并不一定是流水线配置的位置。 流水线可以被配置：
 直接在 Jenkins 任务中作为脚本。 代码将直接插入任务配置页面。 作为源代码管理系统（SCM）中的 Jenkinsfile：流水线配置在 SCM 中的文本文件（Jenkinsfile）中定义。 在任务本身中，只配置了 Jenkinsfile 存储库的路径。 在构建过程中，Jenkinsfile 从 SCM 中被检出并被处理。 作为共享库：流水线配置的一部分被移动到单独文件中，它可以由多个任务使用。 这些文件也保存在 SCM 中。 即使这样仍然需要 Jenkinsfile（或者任务中的流水线脚本）。  对于任务配置的每次保存操作，如果发生了变更，JobConfigHistory 将创建实际任务配置的副本。 只有当流水线配置作为脚本插入到任务配置页面时，该方法才适用于流水线任务。 JobConfigHistory 未检测到 Jenkinsfile 或共享库中的变更。 您必须使用 SCM 系统查看 Jenkinsfile 或共享库的变更。 在构建时间和对 Jenkinsfile 或共享库的变更之间找到相关性是复杂且耗时的。</description>
    </item>
    
    <item>
      <title>开源人线下见面会</title>
      <link>https://jenkins-zh.github.io/wechat/articles/2019/07/2019-07-30-jenkins-meetup/</link>
      <pubDate>Tue, 30 Jul 2019 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.github.io/wechat/articles/2019/07/2019-07-30-jenkins-meetup/</guid>
      <description>本次活动是由 Jenkins 中文社区与“开源社”联合主办的一次关于如何参与开源的见会。
大家共同探讨什么是开源精神、为什么以及如何参与开源、开源与个人以及企业之间的关系、开源社区存在的重要意义、996是否与开源背道而驰。
我们的观点是：社区重于代码。是否与你的想法一致？欢迎来辩！
分享嘉宾 赵晓杰 Jenkins 中文社区发起人
热衷于传播开源理念、开源技术。多年研发经验，目前关注于 DevOps 领域，尤其是持续交付方面。
刘天栋 Ted 开源社理事长暨联合创始人、Apache 软件基金会正式会员
开源社理事长暨联合创始人， Apache 软件基金会正式会员，ASF孵化器项目委员会成员/导师，ASF 筹款委员会成员/赞助伙伴大使，中国信息通信研究院。云计算开源产业联盟.特聘开源治理个人顾问。于2014年10月联合创始开源社。于2018年当选 ASF 正式成员，随后加入 ASF 筹款委员会并成为赞助伙伴大使，2019年成为 ASF 孵化器项目委员会成员，并担任孵化项目（ECharts）导师。 曾历任微软中国战略业务总监、微软开放技术公司及微软亚太研发集团负责开源技术布道及开源社区发展工作；甲骨文(中国)渠道及联盟总监、甲骨文(中国) Linux 战略总监、甲骨文大中华区中间件事业部总经理；Turbolinux 亚太区副总裁等。
慕睿涛 北京卓晟互联网络技术有限公司 CTO
毕业于北京工业大学，2003年加入 Sun Microsystems，负责嵌入式 Java 虚拟机的研发。曾于2008年创建了 PSP 上的JavaME 模拟器项目——PSPKVM，在 PSP 自制软件社区有很高的普及度。目前在北京卓晟互联网络技术有限公司任 CTO ，创建并主持了 JOSH 开源项目，致力于为微小型物联网终端设备提供 Java 应用开发与运行环境。
彭志雄 平安云 GitHub 产品专家
13年IT行业工作经验，领域包括系统集成、售前支持和咨询、云计算和 DevOps 等业务。
时间地点  日期 2019.8.24 地点 北京市朝阳区东直门外斜街56号 A座302  活动流程    时间 流程     13:00-13:30 签到   13:30-14:00 Jenkins 社区在国内的发展——赵晓杰   14:00-14:30 Apache 之道：从孵化器到顶级项目之路——刘天栋 Ted   14:30-14:45 茶歇   14:45-15:45 Panel 开源社区的发展和维护   15:45-16:00 茶歇   15:45-16:00 开源等于开放吗？——关于开源与开放之关系的思考——慕睿涛   16:00-16:30 用平安云 GitHub 转变企业软件开发模式——彭志雄   16:30-17:00 活动复盘    现场更有好礼相送  平安云赞助的保温杯   Jenkins 中文社区定制的笔、本以及贴纸  主办方 赞助企业 想更多地了解本次活动，请在 Jenkins 公众号后台回复“社区活动”，让我们社区的小伙伴把你拉进微信群。</description>
    </item>
    
    <item>
      <title>在 Kubernetes 上使用 Jenkins </title>
      <link>https://jenkins-zh.github.io/wechat/articles/2019/07/2019-07-29-leveraging-jenkins-on-kubernetes/</link>
      <pubDate>Mon, 29 Jul 2019 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.github.io/wechat/articles/2019/07/2019-07-29-leveraging-jenkins-on-kubernetes/</guid>
      <description>​有几种方法可以在 DevOps 环境中管理您的云基础架构。 DevOps 是一种鼓励快速流动的应用程序开发以及促进 IT 团队开发、测试、发布过程无缝无缝衔接的方法。
Jenkins 通过自动化将持续集成（CI）和持续交付（CD）无缝集成到开发流程中来优化工作流程。
可以使用 Kubernetes 中的 Jenkins pod 部署这些技术， Jenkins pod 可以根据团队的具体需求进行扩展。
CI/CD 流水线 Jenkins 是 CI/CD 的同义词，它是自动化开发、部署应用程序和微服务的完美工具，目前是市场上最流行的自动化工具。 Jenkins 拥有1000多个插件，可以轻松地与其他系统（包括 Kubernetes ）集成。插件不仅提供多系统集成，而且显著增强了 Jenkins 的能力，使 Jenkins 能够帮助您构建和部署几乎任何类型的项目。我们在另一篇文章中介绍了生活中最需要的20个 Jenkins 插件。
​由于 Jenkins 和 Kubernetes 的原生兼容性，设置自己的 CI/CD 流水线非常容易。与基于 VM 的部署相比，在 Kubernetes 上部署 Jenkins 优势更明显。例如，获得按需拥有特定于 Jenkins slaves (代理)项目的能力，而不是让一个 vm 池空闲等待任务。它将使用 master-agent 体系结构来完全自动化微服务的创建和部署以及测试和部署所需的环境。
​可以使用 Helm、kubectl 或 GUIs 部署 Jenkins ，以便将新的 pods 部署到集群中。安装后，下一步是为 K8s 配置 Jenkins 插件。我们需要配置系统设置，例如，代理在哪里找到 Jenkins master ，代理将使用的 Docker 镜像等。当然，将 Jenkins 配置为与 CI/CD 工作流一起工作也是至关重要的，包括设置测试和部署参数以及要如何设置 Jenkins 控制的集群。一旦 Jenkins 启动并运行，就可以实现一个完全自动化的连续交付环境。</description>
    </item>
    
    <item>
      <title>让我们庆祝 Jenkins 对 Java 11的支持</title>
      <link>https://jenkins-zh.github.io/wechat/articles/2019/07/2019-07-15-let-s-celebrate-java-11-support/</link>
      <pubDate>Mon, 15 Jul 2019 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.github.io/wechat/articles/2019/07/2019-07-15-let-s-celebrate-java-11-support/</guid>
      <description>NOTE：这是由 Java 11支持团队准备的联合博客文章：Adrien Lecharpentier、Ashton Treadway、Baptiste Mathus、Jenn Briden、Kevin Earls、MaríaIsabelVilacides、Mark Waite、RamónLeón 和 Oleg Nenashev。
  我们为此努力工作，现在就在这里。我们非常激动地宣布，从 Jenkins 2.164（2019年2月10日发布）和 LTS 2.164.1（ETA：3月14日）开始，在 Jenkins 中全面支持 Java 11。这意味着您现在可以使用 Java 11 JVM 运行 Jenkins master 和代理程序。
从2018年6月开始，组织了许多活动来改进 Jenkins 代码库并添加 Java 11支持。除了这些事件之外，Core/Plugins 维护者和许多其他贡献者都在努力工作，确保他们发现并解决与 Java 11支持相关的尽可能多的问题。
支持 Java 11的努力导致在 Jenkins 中创建了 JEP-211: Java 10+ support in Jenkins。它还促使平台特别兴趣小组的成立，以协调 Java 11工作和其他平台支持工作。
庆祝活动 我们想花点时间感谢参与这些任务的每个人：代码贡献者、问题记者、测试人员、活动策划者和与会者以及社区中所有慷慨地为这项工作提供时间和支持的人。谢谢你们！
以下是一些帮助完成此任务的贡献者（按字母顺序排列）：
Alex Earl, Alyssa Tong, Ashton Treadway, Baptiste Mathus, Carlos Sanchez, Daniel Beck, David Aldrich, Denis Digtyar, Devin Nusbaum, Emeric Vernat, Evaristo Gutierrez, Gavin Mogan, Gianpaolo Macario, Isabel Vilacides, James Howe, Jeff Pearce, Jeff Thompson, Jenn Briden, Jesse Glick, Jonah Graham, Kevin Earls, Ksenia Nenasheva, Kohsuke Kawaguchi, Liam Newman, Mandy Chung, Mark Waite, Nicolas De Loof, Oleg Nenashev, Oliver Gondža, Olivier Lamy, Olivier Vernin, Parker Ennis, Paul Sandoz, Ramón León, Sam Van Oort, Tobias Getrost, Tracy Miranda, Ulli Hafner, Vincent Latombe, Wadeck Follonier</description>
    </item>
    
    <item>
      <title>持续交付落地实践工作坊</title>
      <link>https://jenkins-zh.github.io/wechat/articles/2019/07/2019-07-14-jenkins-pipeline-workshop/</link>
      <pubDate>Sun, 14 Jul 2019 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.github.io/wechat/articles/2019/07/2019-07-14-jenkins-pipeline-workshop/</guid>
      <description>Jenkins 中文社区第二次线下持续交付落地实践工作坊在召唤每一位希望学习并掌握持续交付技术的同学，就在 2019年7月27日（周六）。
Kubernetes 已经成为容器技术中必不可少的平台，甚至会作为未来的“操作系统”。相信每一次 IT 从业人员都有理由把 Kubernetes 掌握，本次活动首先由 Linux 基金会与 CNCF 基金会官方认证 Kubernetes CKA 培训讲师（LFAI）的孟凡浩为我们分享 Kubernetes 的入门介绍。
之后，分享如何基于 Kubernetes 强大的平台下实践持续交付。
在上次的工作坊实践中，我们首先完整地介绍了 Jenkins 的流水线功能，然后大家一起通过四个练习项目加强并巩固了 Jenkins 流水线 Jenkinsfile 文件的编写。
上次练习的项目包括：
 构建 Maven 项目 制品归档 构建 Docker 镜像 参数化构建，指定 Docker 镜像 Tag  过程中录制的视频，可以从我们的优酷地址上找到 https://i.youku.com/jenkinszh
而对于参加本次工作坊实践活动的同学，可以根据自身的情况选择练习上面的题目或者下面进阶的题目：
 构建 Maven 项目并发布到 Nexus 使用私有 Nexus 中的依赖进行构建 构建 Docker 镜像并推送到 Harbor 构建 Heml Charts 并推送到 Chartmuseum  我们期望每一位参加的同学都可以从中学习并掌握基于 Jenkins 的持续交付技术，助力你所在团队的 DevOps 实践。更多的实训项目请参考 https://jenkins-zh.cn/about/course/#17
最后，让我们一起感谢京东云为我们本次活动提供的 Kubernetes 云计算资源。因此，每一位参加练习的同学，只需要带上自己的笔记本，以及 SSH 客户端即可。</description>
    </item>
    
    <item>
      <title>Jenkins 每周版更新</title>
      <link>https://jenkins-zh.github.io/wechat/articles/2019/07/2019-07-18-jenkins-weekly-release/</link>
      <pubDate>Tue, 09 Jul 2019 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.github.io/wechat/articles/2019/07/2019-07-18-jenkins-weekly-release/</guid>
      <description>2.184 (2019-07-07)  注销时，移除过期的会话 cookies ，阻止头信息中的相关错误太大。 (issue 25046) 当运行在 Java 11 上时，增加缺失类相关的 telemetry 实验。 (issue 57223) 修复使用“记住我”时的性能问题（于 2.160 中退化） (issue 56243) 开发者：清理 AbstractCloudSlave 的构造器 (pull 4086)  2.183 (2019-06-30)  在 Jenkins 的 URL 配置增加对 IPv6 地址的支持。 (issue 58041) 更新 args4j 2.0.31 到 2.33。 (issue 57959) 开发者：允许插件为 CodeMirror 文本域控制提供 onBlur() 的支持。 (issue 58240) 开发者：使得 WindowsUtil 可以让插件使用。 (pull 4038) 内部：更新 maven-war-plugin 3.0.0 到 3.2.3 (issue 47127)  2.182 (2019-06-23)  当删除目录时，移除 Windows 下的只读标记。 (issue 57855) 更新 Remoting 3.</description>
    </item>
    
    <item>
      <title>Jenkins 长期支持版更新</title>
      <link>https://jenkins-zh.github.io/wechat/articles/2019/07/2019-07-09-jenkins-release/</link>
      <pubDate>Tue, 09 Jul 2019 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.github.io/wechat/articles/2019/07/2019-07-09-jenkins-release/</guid>
      <description>2.176.1 (2019-06-10)  自 2.176 以来的变更：
 恢复安装向导中用到的中文本地化资源。 (issue 57412) Robustness: 当 ComputerListener#onOnline() 发生运行时异常后不把节点设置为离线状态。 (issue 57111)  CLI 中通过参数 (-remoting option) 对远程模式的支持已经被移除。 (pull 3838, 博客发布)
 移除符号 nonStoredPasswordParam 对密码参数定义的误导，因为，它会存储加密后的数据。 (issue 56776)
 移除对 CCtray (cc.xml) 文件的默认支持。 要使用该功能，需要按照插件 CCtray XML Plugin。 (issue 40750)
 增加 CLI 命令 stop-job 终止构建。 (issue 11888)
 在日志配置中支持关闭一项日志记录器。 (issue 56200)
 为 REST API 的响应增加运行参数过滤器。 (issue 56554)
 构建结束后更新状态图标。 (issue 16750)
 在 Jenkins 节点的界面上移除对 Java Web Start and JNLP 的误导性引用。 (pull 3998)</description>
    </item>
    
    <item>
      <title>Jenkins 中文社区技术交流微信群问题集之一</title>
      <link>https://jenkins-zh.github.io/wechat/articles/2019/07/2019-07-08-wechat-answer-1/</link>
      <pubDate>Mon, 08 Jul 2019 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.github.io/wechat/articles/2019/07/2019-07-08-wechat-answer-1/</guid>
      <description>申明：下文中的问题是群友发起的，回答则是由笔者收集整理的。
1. 同一流水线，如何做某个阶段定时执行代码扫描 这个需求的意思是存在一条流水线，流水线中的阶段为：构建阶段 &amp;ndash;&amp;gt; 代码扫描阶段 &amp;ndash;&amp;gt; 发布测试环境阶段 &amp;ndash;&amp;gt; &amp;hellip; 而提问者希望当有代码提交时，就执行整条流水线。当到某个时间点时，就只执行扫描阶段。
回答一 当代码没有变化，我们为什么要重复执行扫描呢？
回答二 换成两个流水线，一个提交触发，一个定时触发
回答三 一条流水线加个开关设置是否跳过扫描。
2. 有人做过增量包构建么？  有人做过增量包构建么？问下要用哪些插件，怎么做？ 经确认，提问人的需求是有一个代码仓库 x，然后 x 里有 a,b,c 三个模块，开发提交了 a 模块的代码，这时，只打包 a 模块的制品。
 回答一 要做的是在流水线里判断提交代码中修改了哪个模块，然后执行你的 ant 命令指定构建某个模块就好了。代码 demo 如下：
pipeline{ agent any stages{ stage(&#39;build a&#39;){ when{ changeset &amp;quot;a/**&amp;quot; } steps{ echo &amp;quot;build a&amp;quot; } } stage(&#39;build b&#39;){ when{ changeset &amp;quot;b/**&amp;quot; } steps{ echo &amp;quot;build b&amp;quot; } } } }  回答二 增量包，四五年前我有过相关实践，构建工具也是 ant。记得当初是根据修改的文件路径，解析出 ant target 列表，然后根据事先声明好的依赖关系对它排序，然后执行 ant 构建命令，最后将生成的二进制包挑出来生成增量包，大致这么个思路。</description>
    </item>
    
    <item>
      <title>Jenkins 插件的微基准测试框架</title>
      <link>https://jenkins-zh.github.io/wechat/articles/2019/07/2019-07-04-performance-testing-jenkins/</link>
      <pubDate>Thu, 04 Jul 2019 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.github.io/wechat/articles/2019/07/2019-07-04-performance-testing-jenkins/</guid>
      <description>Jenkins 插件的微基准测试框架 作为我 Google 编程夏令营的一部分，我一直致力于改进角色策略插件（Role Strategy Plugin）的性能。 由于没有现有的方法来度量性能以及在 Jenkins 插件上做基准测试， 我在项目第一阶段的工作是创建一个框架在一个 Jenkins 实例中运行 Jenkins 插件中的基准测试。 为了让我们的工作更容易些，我们选择了 Java微基准测试工具来运行这些基准。 这使我们能够可靠地度量对时间要求严格的功能的性能，将有助于让 Jenkins 为每个人更快的运转。
最近在 Jenkins 单元测试工具2.50中发布了微基准测试框架。 下面的博客文章展示了如何在插件中运行基准测试。
介绍 该框架通过为 JMH 基准的每个 fork 启动一个临时的 Jenkins 实例来运行， 就像 Jenkins 测试工具中的 JenkinsRule。 基准测试是直接从 JUnit 测试运行的，它允许在运行过程中失败构建，并且很容易从 IDE 中运行基准测试，就像单元测试一样。 你可以很容易地通过使用 Java 方法或使用 Jenkins plugin:configuration-as-code:[配置即代码插件]来配置基准并将路径传递到 YAML 文件。
要从您的插件运行基准测试，您需要做以下工作：
 将所需的最低 Jenkins 版本升级到2.60.3或更高版本 将 Plugin-POM 升级到 ≥ 3.46 的版本或手动更新 Jenkins 测试工具到 ≥ 2.51 的版本  现在，要运行基准测试，您需要有一个包含 @Test 的基准测试运行程序，以便它可以像 JUnit 测试一样运行。 从测试方法内部，可以使用 JMH 提供的 OptionsBuilder 来配置基准。 例如：</description>
    </item>
    
    <item>
      <title>多分支流水线任务对 GitLab SCM 的支持</title>
      <link>https://jenkins-zh.github.io/wechat/articles/2019/07/2019-07-10-phase-1-multibranch-pipeline-support-for-gitlab/</link>
      <pubDate>Thu, 04 Jul 2019 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.github.io/wechat/articles/2019/07/2019-07-10-phase-1-multibranch-pipeline-support-for-gitlab/</guid>
      <description>这是在 GSoC 2019中的一个 Jenkins 项目。 我们正致力于增加多分支流水线任务和文件夹组织对 GitLab 的支持。 这个计划是创建以下插件： * GitLab API 插件 - 包装 GitLab Java APIs。 * GitLab 分支源插件 - 包括两个包： * io.jenkins.plugins.gitlabserverconfig - 管理服务器配置和 Web hooks 管理。理想情况下应该在另一个名为 GitLab Plugin 的插件中。 未来，这个包应该移动到新的插件中。 * io.jenkins.plugins.gitlabbranchsource - 为多分支流水线任务（包括 Merge Requests ）和文件夹组织添加 GitLab 分支源。
现状  完全支持自由风格的任务和流水线（单分支）任务。 部分支持多分支流水线任务（没有 MRS 检测）。 不支持 Gitlab 文件夹组织。  这个项目的目标  实现一个依赖于 Gitlab API 插件的轻量级 Gitlab 插件。 遵循3个独立插件的约定，即 GitLab 插件，GitLab API 插件，GitLab 分支源插件。 实现 Gitlab 分支源插件，支持多分支管道作业。 支持新的 Jenkins 特性，例如 Jenkins 代码即配置 (JCasC)， 增量式工具。 清晰高效的设计。 支持新的 SCM 特性 APIs。 支持 Java 8 及更高版本。  构建插件 这个插件还没有二进制文件可用，因为这个插件还处于非常早期的 alpha 阶段，还没有为公众准备好。 如果您想尽早介入，可以尝试自己从源代码构建它。</description>
    </item>
    
    <item>
      <title>介绍 Jenkins 模板引擎</title>
      <link>https://jenkins-zh.github.io/wechat/articles/2019/07/2019-07-01-introducing-the-jenkins-templating-engine/</link>
      <pubDate>Mon, 01 Jul 2019 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.github.io/wechat/articles/2019/07/2019-07-01-introducing-the-jenkins-templating-engine/</guid>
      <description>在企业范围内实施 DevSecOps 实践具有挑战性。由于组织内的不同应用程序正在使用多种编程语言、自动化测试框架和安全遵从性安全合规工具，因此每个团队构建和维护流水线变得很难。
无论应用程序使用哪个特定的技术栈，大多数流水线都将遵循相同的通用工作流。模板引擎插件（简写为 JTE ，用于 Jenkins 模板引擎）允许您通过创建不依赖于工具的模板化工作流来获取效率，每个团队都可以重用这些工作流。
作为公共部门和私营部门客户的技术顾问，我们在 Booz Allen 发现，每个新项目都要从头开始建造 DevSecOps 流水线。通过开发 Jenkins 模板引擎，我们已经看到流水线开发从几个月减少到几天，现在我们可以重用工具集成，同时为 Jenkins 流水线带来新的治理级别。
流水线模板 组织受益于让应用程序开发人员专注于他们最擅长的工作：构建应用程序。支持这个，意味着建立一个集中式的 DevOps 团队，负责维护平台基础设施，并创建开发团队使用的 CI/CD 流水线。
随着基于微服务的体系结构的兴起，一个集中的 DevOps 团队可以同时支持许多不同的开发团队；所有这些团队都可能利用不同的编程语言和自动化测试工具。
虽然开发团队之间的工具可能不同，但工作流通常是相同的：单元测试、静态代码分析、构建和发布制品、部署它，然后针对部署的应用程序执行不同类型的测试。
 模板引擎插件允许您从每个被团队定义可继承通用工作流的存储库中删除 Jenkinsfile 。作为替代每个存储库需定义整个流水线，团队提供一个使用工作流的工具配置文件。
 JTE 实战 让我们通过一个简单的示例来演示模板的可重用性： 流水线模板例子：  unit_test() build() static_code_analysis()  模板利用库提供的步骤概述工作流团队必须实现的步骤。虽然模板的执行方式与任何其他 Jenkinsfile 都一样（这意味着支持标准的脚本化和声明性语法），但模板的目标应该是以纯英语的方式阅读，并避免任何技术实现。
 通过这种方式利用模板，您可以将流水线的业务逻辑（应该在什么时候发生）与技术实现（实际将要发生什么）分开。其结果是一个 CI/CD 管道，当同时支持多个团队时，该流水线被证明非常容易管理。
 此模板（ unit_test 、 build 和 static_code_analysis ）概述的步骤是专门命名的。通过这种方式，团队可以使用的不同库共享同一流水线。
实现模板 使用模板引擎实现可共享流水线需要几个关键组件： 1. 流水线模板：概述要执行的工作流 2. 库：提供工作流步骤的技术实现 3. 配置文件：指定要使用的库及其配置
步骤1、创建流水线配置存储库 流水线配置存储库用于存储团队继承的常见配置和流水线模板。
这个示例流水线配置存储库稍后将被配置为治理层的一部分：JTE 的机制中允许您构建表示组织的层次结构配置。</description>
    </item>
    
    <item>
      <title>使用Active-Choices-Plugin插件将十个Job合成一个</title>
      <link>https://jenkins-zh.github.io/wechat/articles/2019/06/2019-06-26-using-active-choices-plugin-merge-jobs/</link>
      <pubDate>Wed, 26 Jun 2019 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.github.io/wechat/articles/2019/06/2019-06-26-using-active-choices-plugin-merge-jobs/</guid>
      <description>现在Spring Cloud越来越火爆，许多公司也都在如火如荼投入使用中，而微服务最大的一个特点，就是多，同一大项目之下，可能会被拆分成十几二十几个子服务，对于运维而言，可能也需要一个对应一个地在Jenkins中创建十几二十几个Job。
刚刚还在一个博主的自我介绍里看到这样一句话：喜欢一切优雅的运维方式···
于是，我一直在想着，通过一些合理的参数变幻，从而将刚刚提到的十几二十几个服务，汇集到一个Job当中就能完成。
1，环境说明  主机：CentOS-7.5 Jdk：jdk1.8.0_192 Tomcat：8 Jenkins：2.177  如上环境的准备工作本文就不赘述了。
2，安装插件。  官方地址：https://wiki.jenkins.io/display/JENKINS/Active+Choices+Plugin 安装方式：在Jenkins插件当中直接搜索即可安装。 功能说明：根据所选参数，自动调出对应参数所依赖的后续参数。  3，使用前介绍。 插件安装之后，可以在项目配置中的参数化配置中看到一些新增了的选项。
 1，Active Choices Parameter（主动选择参数） Active Choices参数使用Groovy脚本或Scriptler目录中的脚本动态生成构建参数的值选项列表。 2，Active Choices Reactive Parameter（主动选择反应参数） 根据主动选择参数的选项而提供不同的对应值或者列表选项。 3，Active Choices Reactive Reference Parameter（主动选择反应参考参数） 根据主动选择参数的选项而展示对应参数的一些说明，与第二项的区别在于本参数只作为说明信息，而不能够作为变量往下传递。  可能刚刚这些说明都比较抽象，接下来容我通过项目实战，来对其进行一一解析。
4，配置前分析。 优秀的插件，它的优秀之处，往往是需要我们结合生产实际，开动聪明的大脑，打破常规使用套路来成就的。
因此，如何才能更好地应用插件的优秀功能，需要我们先对项目进行分析，从全局的眼光，判断项目前后该配置什么样的参数来进行联动。
这里我说明一下我准备的实验项目情况，为了简便测试，我这里仅使用两个项目来进行举例，聪明的你也一定能够通过案例进行举一反三，将二合一推广为十合一的。
两个项目的情况如下：
1，eureka  Gitlab地址：git@192.168.10.0:ishangjie/ishangjie-eureka-server.git port：8761 包名：ishangjie-eureka-server-1.0.0.jar  2，user  Gitlab地址：git@192.168.10.0:ishangjie/ishangjie-user-service.git port：6666 包名：ishangjie-user-service-1.0.0.jar  从刚刚这些配置里边可以看出，有不少共同点，也有不少不同点，我们只需把眼光放在不同点上，通过一些统一的变量控制，就能达到二合一的目的。
另外说明一点，这个项目已经部署在k8s环境当中，因此我的脚本内容也就展示成了k8s项目部署的流程了。
5，创建项目。 首先创建一个自由风格的Jenkins项目，然后配置一下项目构建保存历史。
6，字符参数。 添加一个名为branch的字符参数以用于控制代码分支的变量。
7，选项参数。 添加一个名为mode的选项参数以用于控制部署或者回滚的变量。
8，选择参数。 1，主动选择参数 首先添加一个主动选择参数，用于控制项目名称这个变量。
 Name：project Groovy Script:  return[ &amp;quot;eureka&amp;quot;, &amp;quot;user&amp;quot; ]  Description：选择对应的应用名称部署对应的应用。 Choice Type：Radio Buttons  2，主动选择反应参数 接着添加一个主动选择反应参数，用于控制项目类型这个变量。</description>
    </item>
    
    <item>
      <title>10节课带你深入学习 DevOps 工程</title>
      <link>https://jenkins-zh.github.io/wechat/articles/2019/06/2019-06-17-10-courses-to-learn-devops-engineering-in-depth/</link>
      <pubDate>Mon, 17 Jun 2019 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.github.io/wechat/articles/2019/06/2019-06-17-10-courses-to-learn-devops-engineering-in-depth/</guid>
      <description>DevOps 现在真的很热门，对于杰出的工程师和 DevOps 专业人员来说有许多工作机会。 如果你想成为一名 DevOps 工程师，那么你来对地方了。在本文中，我将分享一下最好的在线培训课程， 让你成为 DevOps 专业人员。
Devops 最重要的优势，它可以帮助你更好地发布软件并且利用现代自动化工具对环境和软件开发过程中提供更多控制。这就是 DevOps 专业人员需求呈指数增长的原因。除了 Data Science 和 Machine Learning 外，它也是薪酬最高的 IT 工作之一。
根据 Glassdoor 的数据，DevOps 的工程师每年的收入从105000美元到146000美元不等。这意味着，如果你正在寻找加薪或想在美好年纪从事一些令人兴奋的工作赚更多的钱，学习 DevOps 可能是一个不错的选择。
学习像 Jenkins 这样的持续集成工具和像 Docker 这样的容器以及一般的 DevOps 技能，在技术领域获得了巨大的动力。这与几年前的移动应用程序开发类似。
公司希望新的开发人员能够管理 Web 应用程序的整个生命周期。这意味着开发和部署应用程序。
为了成为一名有效的 DevOps 工程师，您必须扩展对软件开发中使用的不同工具的知识，包括构建工具（如 Maven、 Ant 和 Gradle ）、单元测试工具（如 Junit 和 Selenium ）、部署工具（如 Docker ）、监控工具（如 New Relic ）、基础设施自动化工具（如 Chef 和 Puppet ）、源代码控制工具，如 Git 和 Github，以及持续集成工具，如 Jenkins 和 TeamCity。这些课程为基本的 DevOps 工具提供了很好的介绍。
十节面向经验丰富的开发人员 DevOps 课程 在不浪费更多时间的情况下，这里列出了一些学习 DevOps 的最佳课程以及在软件开发和部署过程中实现自动化所需的基本工具。</description>
    </item>
    
    <item>
      <title>30分钟搞定 Jenkins CI</title>
      <link>https://jenkins-zh.github.io/wechat/articles/2019/06/2019-06-14-setup-jenkins-ci-in-30-minutes/</link>
      <pubDate>Fri, 14 Jun 2019 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.github.io/wechat/articles/2019/06/2019-06-14-setup-jenkins-ci-in-30-minutes/</guid>
      <description>你想在本地设置中使用 Jenkins CI 进行实验吗？在本文中，我们将设置一个本地 Jenkins CI 服务，为一个简单的 Spring Boot Maven 项目创建一个构建工作，并将创建的 Docker 镜像推送到 DockerHub。这将是一个本地实验的设置，但如果你想尝试一个 Jenkins 插件，它会非常方便。
1.先决条件 开始之前，我们需要以下先决条件：
 我们使用了 Ubuntu 18.04； 必须安装 Docker，有关安装说明，请参见此处； 我们需要在 Docker registry 来推送我们的 Docker 镜像。最简单的方法是在DockerHub上创建一个帐户。你可以免费创建帐户。也不会收到垃圾广告邮件； 构建工作的 Spring Boot 应用程序。我们将使用前一篇文章中的 Spring Boot MVC 应用程序。源代码可以在GitHub上找到，相应的Docker图像可以在DockerHub上找到。该应用程序包含 http://localhost:8080/hello 上的一个 HTTP 端点，并只返回一条 Hello Kubernetes 欢迎消息。  2.运行 Jenkins CI 我们将使用 Jenkins CI Docker 官方镜像运行 Jenkins 服务。完整的文档可以在这里找到。用以下命令启动容器:
$ docker run -p 8080:8080 --name myjenkins -v jenkins_home:/var/jenkins_home -v jenkins_downloads:/var/jenkins_home/downloads jenkins/jenkins:lts  让我们来仔细看看我们正在做什么:</description>
    </item>
    
    <item>
      <title>还在苦恼不会写 Jenkins 流水线？来场工作坊！</title>
      <link>https://jenkins-zh.github.io/wechat/articles/2019/06/2019-06-10-jenkins-pipeline-workshop/</link>
      <pubDate>Mon, 10 Jun 2019 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.github.io/wechat/articles/2019/06/2019-06-10-jenkins-pipeline-workshop/</guid>
      <description>前段时间，Jenkins 中文社区建了一个“Jenkins 中文社区技术交流”的微信群。
群里不温不火，不时有人抛出几个关于 Jenkins 流水线的问题。比如以下聊天记录：
而这些问题都共同说明另一个问题：Jenkins 的流水线的普及度还很低。大家都苦恼着不知道如何写 Jenkins 流水线呢。
所以，Jenkins 中文社区决定6月22日组织一场工作坊，手把手教大家如何写 Jenkins pipeline。工作坊内容包括： * 流水线基础讲解及其练习。 * 流水线高级部分讲解及其练习。 * 案例实战（注意啦，可是有案例的。不是虚的。）
问题来了？谁是这次工作坊的教练呢？
赵晓杰：jenkinsci Contributor，Jenkins 中文社区发起人。
想参加的同学，请点击阅读原文报名参加。
如果无法现场参加的同学可以发邮件至 events@mail.jenkins-zh.cn 申请 ZOOM 网络会议接入。另，我们鼓励由一人申请，并组织好其他人一起参与。这样多人一起进行工作坊，效果更佳。申请邮件中写明：申请人所在公司、地点、参与人数。
对了想入伙加群？很简单，Jenkins 公众号后台回复“微信群”，扫码入群。趁现在群没满，你懂的！~</description>
    </item>
    
    <item>
      <title>在线分享 - 作为一名开源贡献者是如何使用 GitHub 的？</title>
      <link>https://jenkins-zh.github.io/wechat/articles/2019/06/2019-06-09-github-share/</link>
      <pubDate>Sun, 09 Jun 2019 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.github.io/wechat/articles/2019/06/2019-06-09-github-share/</guid>
      <description> 本次在线分享活动，是由 Jenkins 中文社区与开源社共同发起，旨在向每一位有意了解、参与开源社区活动的朋友们普及 GitHub 的使用。
GitHub 作为全球最大、最为专业的开源社交平台，不仅仅是研发或者技术相关岗位人员的专利，文案、市场相关同学同样可以利用这个 有着无限潜力的开源平台来为开源事业贡献自己的一份绵薄之力。
社区重于代码，这是很多资深开源人士的共同观点。除了可以在 GitHub 上托管我们的源代码之外，到底还可以让 GitHub 为大家所在的 开源社区、项目提供哪些便利的服务呢？除了如何使用 GitHub 以外，这也是我希望与大家分享、共同探讨的。
分享人 瑞克，Jenkins 中文社区发起人，热衷于传播开源理念、开源技术。多年研发经验， 目前关注于 DevOps 领域，尤其是持续交付方面。
分享概要  GitHub 基本介绍  常用功能 开源礼仪  非技术类使用概要  熟悉一个项目 了解如何做贡献 常规的贡献流程  更高效的实践经验  Git 基本介绍 客户端利器 hub 的几种模式  互动环节  合作企业 平安云 GitHub
报名 感兴趣的同学，请及时点击“阅读原文“进行报名，名额有限。我们会在活动前通过邮件的方式告知参与链接。
活动时间为：2019年6月14日 19:00～20:00
注意事项 为了能够让大家能够共同完成一次高效的在线分享活动，请各位准备参加的同学仔细阅读下面的事项：
 提前安排好时间，找一个安静的环境 检查网络是否通畅 准备好你的问题或者疑问 安装好客户端 https://github.com/github/hub 有任何技术细节、疑问，请关注 Jenkins 公众号，回复：微信群  </description>
    </item>
    
    <item>
      <title>2019年 DevOps 面临的挑战以及如何战胜它们</title>
      <link>https://jenkins-zh.github.io/wechat/articles/2019/06/2019-06-05-devops-challenges-in-2019-how-to-overcome-them/</link>
      <pubDate>Wed, 05 Jun 2019 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.github.io/wechat/articles/2019/06/2019-06-05-devops-challenges-in-2019-how-to-overcome-them/</guid>
      <description>随着 DevOps 逐渐成为主流，许多团队都在问自己应该从哪里开始采用 DevOps ， 他们将在此过程中面临哪些挑战，以及如何解决那些挑战。 每年都有越来越多的公司希望从传统的瀑布式方法转向 DevOps 。
许多软件开发公司将 DevOps 看作是一个公司在效率方面所能达到的顶峰，并且这有点难。 应对挑战可能大大降低你的生产力，同时适应 DevOps 方法会导致各种自动化工具和开发过程之间缺乏协调。
在本文中，我们将讨论 DevOps 在2019年面临的一些重大挑战，以及可以采取哪些措施来战胜它们。
关注遗留的应用程序和系统 DevOps 团队面临的第一个和主要挑战涉及到遗留应用程序的构建， 这些应用程序是在没有考虑 DevOps 的情况下构建的。 这似乎看起来有益无害，但这对于转变来说是相当棘手的。 即使你关注使用 DevOps 的新应用程序和系统，你也需要维护这些遗留系统。
对于遗留应用程序的转变这里还有其他原因。 一开始，你需要努力逐步将淘汰它们，或者逐渐将客户转移到使用 DevOps 系统维护的新版本。 否则，你可以尝试创建一个新的系统来维护遗留的应用程序，它不会干扰你的 DevOps 系统。 你也可以使用 Scala 性能度量工具，比如 AppOptics ，它有助于逐步淘汰非 DevOps 系统。
选择适合的项目 对于一个新的 DevOps 团队来说，为每个新项目选择 DevOps 似乎很明智，但事实并非总是如此。 DevOps 不是强制性的，因为如果没有正确地实现 DevOps ，有时会降低整个生产过程的速度。 因此，在选择要使用 DevOps 的项目时，你应该非常勤奋。 在考虑 DevOps 是否必要时，最好记住 DevOps 是一种运营策略，并不总是适合的。
如果你正在努力快速规模化的软件，并从其敏捷性中获得更快的速度，那么 DevOps 是一个明智的选择。 同样地，DevOps 并不是一直起作用，所以不应该把它当作解决所有问题的首选解决方案。 例如，如果你正在使用一个较旧的系统，那么最好坚持使用旧的方法和流程，因为不可能总是为这些方法和流程找到自动化的系统。
除此之外，规划和设计工作被认为不适合 DevOps ，因为进行设计和 UX 是处理流程的更成功的方法，而不是不断改进。</description>
    </item>
    
    <item>
      <title>Jenkins 2.176~2.178版本更新</title>
      <link>https://jenkins-zh.github.io/wechat/articles/2019/05/2019-05-29-jenkins-release/</link>
      <pubDate>Wed, 29 May 2019 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.github.io/wechat/articles/2019/05/2019-05-29-jenkins-release/</guid>
      <description>2.178 (2019-05-20)  将 jmDNS 从3.4.0-jenkins-3更新到3.5.5，以防止不必要的 DNS 组播错误消息。 (issue 25369) 将 WinP 从1.27更新到1.28，以修复 Windows 优雅进程关闭逻辑中缺少 DLL 和控制台窗口闪烁的问题。 (issue 57477, 完整的变更日志) 确保独立的插件(插件曾经是 Jenkins 本身的一部分功能)在 Jenkins 启动时(需要时)作为已经存在的其他插件的隐含依赖项安装。 这简化了不使用更新中心的特殊安装场景的兼容性，例如当 Jenkins 从预先打包了一些插件的 Docker 镜像运行时。 (issue 57528) 将脚本安全插件的捆绑版本与最新的安全警告一起更新，在不太可能的情况下，它确实是从 WAR 而不是更新中心安装的。 (pull 4000)  2.177 (2019-05-12)  支持在流水线或其它任务类型的 fingerprint() 构建步骤中设置排除和区分大小写。 (文档, pull 3915) 允许通过不同的阴影构建球区分新任务、禁用的任务和中止构建的任务。 (pull 3997) 将 Windows 代理安装程序从1.10.0更新到1.11，当在 .NET 4.6 或更新版本运行时，在代理下载时启用 TLS 1.2。 (issue 51577, 完整的变更日志) 将 Winstone-Jetty 从5.2更新到5.3以更新 Jetty 到 9.4.18。 (pull 4016, 完整的变更日志, Jetty 9.</description>
    </item>
    
    <item>
      <title>如何对 Jenkins 共享库进行单元测试</title>
      <link>https://jenkins-zh.github.io/wechat/articles/2019/05/2019-05-28-jenkins-pipeline-shared-lib-unit-test/</link>
      <pubDate>Tue, 28 May 2019 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.github.io/wechat/articles/2019/05/2019-05-28-jenkins-pipeline-shared-lib-unit-test/</guid>
      <description>Jenkins 共享库是除了 Jenkins 插件外，另一种扩展 Jenkins 流水线的技术。通过它，可以轻松地自定义步骤，还可以对现有的流水线逻辑进行一定程度的抽象与封装。至于如何写及如何使用它，读者朋友可以移步附录中的官方文档。
对共享库进行单元测试的原因 但是如何对它进行单元测试呢？共享库越来越大时，你不得不考虑这个问题。因为如果你不在早期就开始单元测试，共享库后期可能就会发展成如下图所示的“艺术品”——能工作，但是脆弱到没有人敢动。
[图片来自网络，侵权必删]
这就是代码越写越慢的原因之一。后人要不断地填前人有意无意挖的坑。
共享库单元测试搭建 共享库官方文档介绍的代码仓库结构 (root) +- src # Groovy source files | +- org | +- foo | +- Bar.groovy # for org.foo.Bar class +- vars | +- foo.groovy # for global &#39;foo&#39; variable | +- foo.txt # help for &#39;foo&#39; variable +- resources # resource files (external libraries only) | +- org | +- foo | +- bar.json # static helper data for org.</description>
    </item>
    
    <item>
      <title>Jenkins 文档特别兴趣小组</title>
      <link>https://jenkins-zh.github.io/wechat/articles/2019/05/2019-05-27-docs-sig-announcement/</link>
      <pubDate>Mon, 27 May 2019 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.github.io/wechat/articles/2019/05/2019-05-27-docs-sig-announcement/</guid>
      <description>我们很高兴地宣布 Jenkins 文档特别兴趣小组的成立。 文档特别兴趣小组鼓励贡献者和外部社区创建和 review Jenkins 文档。
更多详情和计划，请参见：文档特别兴趣小组简介。
我能帮什么忙呢？ Jenkins 文档特别兴趣小组希望从以下方面得到您的帮助：
 review 及修复 打开的 bug 报告 review Jenkins 文档 pull requests review Jenkins X 文档 pull requests  我该如何修复文档 bug？ 关于如何为 Jenkins 文档做贡献的说明，请参见站点仓库中的 CONTRIBUTING 文件。 按照说明文件，提交 pull requests 以供 review 。
关于如何为 Jenkins X 文档做贡献的说明，请参见站点仓库中的 Jenkins X 文档站点。 按照说明文件，提交 pull requests 以供 review 。
我该如何评估 pull request？ Jenkins 项目的 pull requests 会在 Jenkins 文档仓库进行 review 。 使用您的凭据登录到 GitHub，向 pull requests 中添加评论。</description>
    </item>
    
    <item>
      <title>使用 Jenkins X、Kubernetes 和 Spring Boot 实现 CI/CD</title>
      <link>https://jenkins-zh.github.io/wechat/articles/2019/05/2019-05-24-achieve-cicd-with-jenkins-x-kubernetes-and-spring/</link>
      <pubDate>Fri, 24 May 2019 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.github.io/wechat/articles/2019/05/2019-05-24-achieve-cicd-with-jenkins-x-kubernetes-and-spring/</guid>
      <description>过去五年中的变化，如迁移到公有云以及从虚拟机向容器的转变，已经彻底改变了构建和部署软件的意义。
以 Kubernetes 为例。Google 于2014年开源，现在所有主流的公有云供应商都支持它&amp;mdash;它为开发人员提供了一种很好的方式，可以将应用程序打包到 Docker 容器中，并部署到任意 Kubernetes 集群中。
使用 CI/CD、Kubernetes 和 Jenkins X 进行高性能开发 在技术上，高性能团队几乎总是成功的必要条件，而持续集成、持续部署(CI/CD)、小迭代以及快速反馈是构建模块。为你的云原生应用程序设置 CI/CD 可能比较困难。通过自动化所有内容，开发人员可以花费宝贵的时间来交付实际的业务。
如何使用容器、持续交付和 Kubernetes 成为高效团队？这就是 Jenkins X 的切入点。
“Jenkins X 的理念是为所有开发人员提供他们自己的海军航海管家，可以帮助你航行持续交付的海洋。” - James Strachan
Jenkins X 帮助你自动化你在 Kubernetes 中的 CI/CD - 你甚至不需要学习 Docker 或 Kubernetes！
Jenkins X 能做什么？ Jenkins X 在 Kubernetes 上自动安装，配置和升级 Jenkins 和其他应用程序（Helm，Skaffold，Nexus 等）。它使用 Docker 镜像、Helm 图表和流水线来自动化应用程序的 CI/CD。它使用 GitOps 来管理环境之间的升级，并通过在拉取请求和生产时对其进行评论来提供大量反馈。
Jenkins X 入门 要安装 Jenkins X，首先需要在你的机器或云供应商上安装 jx 二进制文件。从 Google Cloud 可以获得300美元的积分，所以我决定从那里开始。</description>
    </item>
    
    <item>
      <title>Jenkins 中文本地化的重大进展</title>
      <link>https://jenkins-zh.github.io/wechat/articles/2019/05/2019-05-23-chinese-localization/</link>
      <pubDate>Thu, 23 May 2019 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.github.io/wechat/articles/2019/05/2019-05-23-chinese-localization/</guid>
      <description>我从2017年开始，参与 Jenkins 社区贡献。作为一名新成员，翻译可能是帮助社区项目最简单的方法。 本地化的优化通常是较小的改动，你无需了解项目完整的上下文， 甚至都不需要在任务跟踪系统中添加任务。 但很快，就遇到了一些问题，那就是并没有以中文为母语的人帮助 review 我的 PR。因此，有时候， 我提交的 PR 过很久才能够被合并到 master 中。
后来，有贡献者告诉我，可以在邮件列表中发一份邮件来描述当前遇到的问题，然后大家来讨论如何解决。 后来，我才了解到，在邮件列表中公开地讨论社区里的事情， 正是开源社区的做事风格。任何人都可以发表自己的观点， 我们并不受某个公司的限制，大家共同作出一致的决定。下面，我想与各位分享一下我们讨论后得出的一些成果。
JEP-216 JEP 是 Jenkins Enhancement Proposoals 的缩写，也就是 Jenkins 增强提议。所有针对 Jenkins 社区的增强或者改进的想法都可以通过这样的一种 提议机制来推动，特别兴趣小组（SIG）就是其中的一项提议。JEP-216 是关于 改进本地化的一项提议。
在之前，所有语言的本地化资源文件都是集中保存在 Jenkins Core 以及各个插件中的。而在 该提议中，每个语言都可以有一个单独的本地化插件，例如：简体中文插件。 终于，经过半年多的时间， 本地化支持插件和 简体中文插件已经可以支持各种类型的本地化资源文件（包括： Messages、属性以及帮助文件等）。从 插件网站上， 你可以看到 简体中文插件已经有超过1.3万的安装量，而且还在持续增长中。到目前为止，我们已经把 Jenkins Core 里所有简体中文的资源文件 迁移到了简体中文插件中，具体可以查看 PR-4008。
我相信，这对于每一位 Jenkins 的中文用户都是一件意义重大的事情，Jenkins 中文社区也会努力带给大家带来更好的使用体验。当然， 我们欢迎并期待任何一位有志参与开源社区的朋友！
在享受成果的同时，请与我一起感谢社区里为此作出重要贡献的朋友们。在 Daniel Beck 的帮助下，完成了“本地化支持插件”的发布； 在 Liam Newman 的帮助下完成了 JEP-216， 当然还包括社区中很多参与到中文本地化工作的贡献者。
中文本地化特别兴趣小组 我们相信，这个特别兴趣小组能够给 Jenkins 的中文用户带来更好的使用体验，并聚集更多来自中国的贡献者。这里的贡献者，并不只是开发者的专利和特权， 实际上开源社区需要很多有不同技能的人加入，包括当不仅限于：测试、运维、文档工程师 甚至是设计师、市场运营等等。不管你是尚未毕业的在校学生， 还是懵懂初入职场，或者已经是具有多年丰富的从业经历，在这里 都是平等、公开的。</description>
    </item>
    
    <item>
      <title>基于 Jenkins &#43; JaCoCo 实现功能测试代码覆盖率统计</title>
      <link>https://jenkins-zh.github.io/wechat/articles/2019/05/2019-05-22-jacoco-coverage-for-functional-test/</link>
      <pubDate>Wed, 22 May 2019 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.github.io/wechat/articles/2019/05/2019-05-22-jacoco-coverage-for-functional-test/</guid>
      <description>使用 JaCoCo 统计功能测试代码覆盖率？ 对于 JaCoCo，有所了解但又不是很熟悉。 &amp;ldquo;有所了解&amp;rdquo;指的是在 CI 实践中已经使用 JaCoCo 对单元测试代码覆盖率统计： 当代码 push 到代码仓库后，用 JaCoCo 进行单元测试代码覆盖率统计，并将相应数据推送到 SonarQube。 &amp;ldquo;不是很熟&amp;rdquo;指的是应用场景也仅限于此，并未进行过多研究与实践。
前不久，有测试同事提出，想要在实际测试时，用 JaCoCo 统计功能测试代码覆盖率。 其主要目的是在经过功能测试后，通过查看代码覆盖率统计的相关指标，增强对软件质量的信心。 经查阅资料，证明这是可行的。
由于对 JaCoCo 不甚了解，于是查阅官网资料对 JaCoCo 进一步了解。
进一步了解 JaCoCo JaCoCo，即 Java Code Coverage，是一款开源的 Java 代码覆盖率统计工具。 它由 EclEmma 团队根据多年来使用和集成现有库的经验教训而创建。
JaCoCo 愿景 JaCoCo 应该为基于 Java VM 的环境中的代码覆盖率分析提供标准技术。 重点是提供一个轻量级的、灵活的、文档良好的库，以便与各种构建和开发工具集成。
JaCoCo 产品功能  指令(C0)、分支(C1)、行、方法、类型和圈复杂度的覆盖率分析。 基于 Java 字节码，因此也可以在没有源文件的情况下工作。 通过基于 Java agent 的实时检测进行简单集成。其他集成场景(如自定义类加载器)也可以通过 API 实现。 框架无关性：平稳地与基于 Java VM 的应用程序集成，比如普通 Java 程序、OSGi 框架、web 容器或 EJB 服务器。 兼容所有已发布的 Java 类文件版本。 支持不同的 JVM 语言。 支持几种报告格式( HTML、XML、CSV )。 远程协议和 JMX 控件，以便在任何时间点从覆盖率 agent 请求执行数据 dump 。 Ant 任务，用于收集和管理执行数据并创建结构化覆盖报告。 Maven 插件，用于收集覆盖信息并在Maven构建中创建报告。  非功能特性  使用简单和与现有构建脚本和工具集成。 良好的性能和最小的运行时开销，特别是对大型项目。 轻量级实现，对外部库和系统资源的依赖性最小。 全面的文档。 完整文档化的 API ( JavaDoc ) 和用于与其他工具集成的示例。 回归测试基于 JUnit 测试用例，具有完整的功能测试覆盖率。  对 JaCoCo 可以与现有构建脚本和工具进行集成这里做进一步说明： 官方提供了 Java API、Java Agent 、CLI、Ant 、Maven、Eclipse 这几种集成方式； 第三方提供了诸如与 Gradle、IDEA、Jenkins 等其它工具的集成方式。</description>
    </item>
    
    <item>
      <title>使用 Jenkins &#43; Ansible 实现 Spring Boot 自动化部署101</title>
      <link>https://jenkins-zh.github.io/wechat/articles/2019/05/2019-05-20-jenkins-ansible-springboot/</link>
      <pubDate>Mon, 20 May 2019 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.github.io/wechat/articles/2019/05/2019-05-20-jenkins-ansible-springboot/</guid>
      <description>本文要点： 1. 设计一条 Spring Boot 最基本的流水线：包括构建、制品上传、部署。 1. 使用 Docker 容器运行构建逻辑。 1. 自动化整个实验环境：包括 Jenkins 的配置，Jenkins agent 的配置等。
1. 代码仓库安排 本次实验涉及以下多个代码仓库：
% tree -L 1 ├── 1-cd-platform # 实验环境相关代码 ├── 1-env-conf # 环境配置代码-实现配置独立 └── 1-springboot # Spring Boot 应用的代码及其部署代码  1-springboot 的目录结构如下：
% cd 1-springboot % tree -L 1 ├── Jenkinsfile # 流水线代码 ├── README.md ├── deploy # 部署代码 ├── pom.xml └── src # 业务代码  所有代码，均放在 GitHub：https://github.com/cd-in-practice
2. 实验环境准备 笔者使用 Docker Compose + Vagrant 进行实验。环境包括以下几个系统： * Jenkins * 1 Jenkins master，全自动安装插件、默认用户名密码：admin/admin。 * Jenkins agent * 2 Jenkins agent 运行在 Docker 容器中，共启动两个。 * Artifactory * 1 一个商业版的制品库。笔者申请了一个 30 天的商业版。</description>
    </item>
    
    <item>
      <title>转载规范及声明</title>
      <link>https://jenkins-zh.github.io/wechat/articles/2019/05/2019-05-20-translation-norms/</link>
      <pubDate>Mon, 20 May 2019 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.github.io/wechat/articles/2019/05/2019-05-20-translation-norms/</guid>
      <description>转载声明 首先感谢大家对 Jenkins 中文社区内容的认可。传播有道，我们希望每一篇文章的发声不仅能被看见，也都能得到尊重。因此，若需转载本社区的文章，请先获取本社区授权，未经授权禁止转载。如未经许可私自转载，我们会有专人负责沟通进行整改，对于不听劝解的将会被添加到社区官网的黑名单中以作公示。
如需转载，请仔细阅读并遵守以下转载须知： 1. 本站发文均于Jenkins 中文社区首发，然后由微信公众号、CSDN、简书、开源中国、掘金等渠道发出 2. 不论通过何种渠道获得本站文章，若想要转载，均可在文章下方留言，获得授权后方可进行在转载 3. 文章转载首行，需添加本文转自 [Jenkins 中文社区]，Jenkins 中文社区需加入链接 http://jenkins-zh.cn 4. 转载文章标题不得进行修改 5. 转载文章内容不得做任何修改，如有文章内容问题，请与本社区相关联系人沟通后，再进行下一步处理 6. 为了保护作者权益，作者署名必须保留 7. 如是微信公众号转载，请在获得授权的情况下，使用微信的转载功能进行转载 8. 文章在推送三天后方可进行转载</description>
    </item>
    
    <item>
      <title>从 Jenkins 到 Jenkins X</title>
      <link>https://jenkins-zh.github.io/wechat/articles/2019/05/2019-05-17-from-jenkins-to-jenkins-x/</link>
      <pubDate>Fri, 17 May 2019 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.github.io/wechat/articles/2019/05/2019-05-17-from-jenkins-to-jenkins-x/</guid>
      <description>这是一个关于 dailymotion 从 Jenkins 到 Jenkins X 的旅程，我们遇到的问题，以及我们是如何解决它们的故事。
我们的上下文 在 dailymotion ，我们坚信 devops 最佳实践，并且在 Kubernetes 投入了大量投资。 我们的部分产品已经部署在 Kubernetes 上，但并不是全部。 因此，当迁移我们的广告技术平台的时候，我们想要完全采用“ Kubernetes 式”——或者云原生，以追随技术趋势！ 这意味着要重新定义整个 CI/CD 流水线，从静态/永久环境迁移，转向动态按需分配环境。 我们的目标是授权给我们的开发人员，缩短我们的上线时间以及降低我们的运营成本。
对于新的 CI/CD 平台我们的初始需求是: - 尽可能避免从零开始：我们的开发人员已经习惯使用 Jenkins 和声明式流水线，并且它们可以很好地满足我们当前的需求。 - 以公有云基础设施为目标——Google 云平台和 Kubernetes 集群 - 与 gitops 方法论兼容——因为我们喜欢版本控制、同行评审和自动化
在 CI/CD 生态系统中有相当多的参与者，但是只有一个符合我们的需求，Jenkins X ，它基于 Jenkins 和 Kubernetes ，原生支持预览环境和 gitops
Kubernetes 之上的 Jenkins Jenkins X 的设置相当简单，并且在他们的官方网站上已经有很好的文档（译注：译者曾对 Jenkins X 文档中文本地化做了一些贡献，同时也期待更多的人参与以完善中文文档）。 由于我们已经使用了 Google Kubernetes Engine (GKE)，所以 jx 命令行工具自己创建了所有东西，包括 Kubernetes 集群。 这里有一个小小的*哇哦效果*，在几分钟内获得一个完整的工作系统是非常令人印象深刻的。</description>
    </item>
    
    <item>
      <title>与云无关的用于 Kubernetes 的自动化 CI/CD </title>
      <link>https://jenkins-zh.github.io/wechat/articles/2019/05/2019-05-16-cloud-agnostic-automated-cicd-for-k8s/</link>
      <pubDate>Thu, 16 May 2019 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.github.io/wechat/articles/2019/05/2019-05-16-cloud-agnostic-automated-cicd-for-k8s/</guid>
      <description>在本文中，我想讨论一种在云环境中为 Kubernetes 工作负载实现自动化端到端 CI/CD 的方法。 这里可能有其它解决方案，而像 AWS、Microsoft Azure 和 GCP 这样的云提供商也提供了自己的一套框架，以实现与 Kubernetes 相同的目标。
它的部署模型的核心是 Rancher，Rancher 负责为托管在不同云环境和裸机环境中的多个 Kubernetes 集群提供集中管理与运营的能力。 根据应用程序和业务需要，这里提到的工具可以替换为自己选择的工具。
在详细介绍之前，这里有张部署模型的快照：
持续集成组件 我们使用 JIRA、BitBucket、Bamboo 和 Nexus 作为自动化持续集成组件。 需求和用户故事来自 JIRA ； 开发人员将他们的代码放进 BitBucket ； 代码被代码评审工具和静态分析工具构建与集成，Bamboo 生成的 Docker 镜像被推送到 Nexus。 这些镜像会经过特定的容器安全检查。
当你有许多微服务/应用程序需要构建时，那么处理 Kubernetes 集群工作负载的部署、升级和回滚可能会复杂。 版本控制是我们需要考虑的另一个挑战。 Helm 有助于克服这些大多数挑战，并使部署变得简单。
如果你想知道你是否需要有一个 chart 将所有 deployments 包含在其中， 或者允许每个应用程序和微服务都有一个单独的 chart ， 那么我们希望将这些 charts 放到特定的应用程序或微服务的仓库中， 这样我们就不需要有单独的仓库来维护 Helm 制品。 这就省去了为实际的代码和 Helm 模板维护两个独立仓库的工作。 开发人员可以对任何应用程序代码更改所需的模板更改有更多的控制权。
Nexus 作为 Docker 镜像和 Helm chart（使用的是 Helm Nexus 插件）的仓库。 每次成功构建应用程序后，镜像和 chart 都是可用的并被推送到 Nexus 。</description>
    </item>
    
    <item>
      <title>19年 GSoC 中 Jenkins 的七个项目</title>
      <link>https://jenkins-zh.github.io/wechat/articles/2019/05/2019-05-15-gsoc-annoncement/</link>
      <pubDate>Wed, 15 May 2019 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.github.io/wechat/articles/2019/05/2019-05-15-gsoc-annoncement/</guid>
      <description>Google Summer of Code (GSoC) 项目是一个年度性的全球化活动，该项目旨在鼓励高校学生在暑假期间参与到开源项目中来。
通过审核的学生会收到由 Google 提供的带薪工作，参与到设计好的项目中以改进或提升 Jenkins 项目。作为回报，数名 Jenkins 社区成员会志愿作为学生“导师”来帮助他们融入开源社区并成功完成他们的夏令营项目。
Jenkins 社区从2009年开始以开源社区的身份参与到 GSoC 中，并分别在16年有5个项目、18年有3个项目被选中。 而今年的项目、导师的数量是最多的一年，相信在这个夏天里，Jenkins 社区可以给我们的用户带来很多不错的 成果，其中也许正有你或者你们团队所希望有的功能或者改进。
2019年被选中的七个项目包括：
 支持制品升级的流水线插件 基于云的外部工作空间管理器插件 多分支流水线对 Gitlab 的支持 插件安装管理器的 CLI 工具以及库 基于 Apache Kafka 以及 Kubernetes 的远程协议 基于角色策略的插件的改进 时间窗口插件——UI 改进  上面的每个项目都有一位学生主导进行，至少两位具有相关经验的导师加以指导，每周会有两次的同步会议来 保证方向与进度。当然，在开源社区里任何人都可以通过 PR 的形式对代码或者文档进行 Review。
今年负责 GSoC 的管理员为：
 Martin d’Anjou Jeff Pearce Lloyd Chang Oleg Nenashev  我本人是“多分支流水线对 Gitlab 的支持”项目的领队导师，请大家与我一起期待这七位高校学生的精彩表现，后续社区也会及时发布上面项目的介绍以及进展。</description>
    </item>
    
    <item>
      <title>基于 Jenkins 的 DevOps 平台应该如何设计凭证管理</title>
      <link>https://jenkins-zh.github.io/wechat/articles/2019/05/2019-05-14-devops-jenkins-credential-manage/</link>
      <pubDate>Tue, 14 May 2019 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.github.io/wechat/articles/2019/05/2019-05-14-devops-jenkins-credential-manage/</guid>
      <description>背景 了解到行业内有些团队是基于 Jenkins 开发 DevOps 平台。而基于 Jenkins 实现的 DevOps 平台，就不得不考虑凭证的管理问题。
本文就此问题进行讨论，尝试找出相对合理的管理凭证的方案。
一开始我们想到的方案可能是这样的：用户在 DevOps 平台增加凭证后，DevOps 再将凭证同步到 Jenkins 上。Jenkins 任务在使用凭证时，使用的是存储在 Jenkins 上的凭证，而不是 DevOps 平台上的。
但是，仔细想想，这样做会存在以下问题： * Jenkins 与 DevOps 平台之间的凭证数据会存在不一致问题。 * 存在一定的安全隐患。通过 Jenkins 脚本命令行很容易就把所有密码的明文拿到。哪天 Jenkins 被注入了，所有的凭证一下子就被扒走。 * 无法实现 Jenkins 高可用，因为凭证存在 Jenkins master 机器上。
那么，有没有更好的办法呢？
期望实现的目标 先定我们觉得更合理的目标，然后讨论如何实现。以下是笔者觉得合理的目标： &amp;gt; 用户还是在 DevOps 管理自己的凭证。但是 DevOps 不需要将自己凭证同步到 Jenkins 上。Jenkins 任务在使用凭证时，从 DevOps 上取。
实现方式 Jenkins 有一个 Credentials Binding Plugin 插件，在 Jenkins pipeline 中的用法如下：
withCredentials([usernameColonPassword(credentialsId: &#39;mylogin&#39;, variable: &#39;USERPASS&#39;)]) { sh &#39;&#39;&#39; curl -u &amp;quot;$USERPASS&amp;quot; https://private.</description>
    </item>
    
    <item>
      <title>Jenkins 公众号送书福利</title>
      <link>https://jenkins-zh.github.io/wechat/articles/2019/05/2019-05-13-jenkins-book-gift/</link>
      <pubDate>Mon, 13 May 2019 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.github.io/wechat/articles/2019/05/2019-05-13-jenkins-book-gift/</guid>
      <description>Jenkins 中文社区是一个开放、包容、活跃的社区，包含大量的 Jenkins 干货。
当然，它也会为公众号的粉丝们发放福利。
本次福利是《Jenkins 2.x实践指南》x 5，以下是介绍：
本次活动书籍均由博文视点（Broadview）提供，特此感谢。
参与方式：  关注本公众号，并在后台回复【抽奖】，根据二维码进入小程序抽奖。 开奖时间为：5月19日晚上7点自动开奖（记得填自己的手机号，地址以便中奖后邮寄发出）。  中奖的同学，不要忘记发朋友圈分享支持噢~
等不急的同学，还可以扫二维码直接购买：</description>
    </item>
    
    <item>
      <title>持续交付峰会 Call For Papers</title>
      <link>https://jenkins-zh.github.io/wechat/articles/2019/05/2019-05-13-cdf-call-for-papers/</link>
      <pubDate>Mon, 13 May 2019 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.github.io/wechat/articles/2019/05/2019-05-13-cdf-call-for-papers/</guid>
      <description>持续交付峰会是一个为期一天的活动，将开源 CI/CD 社区汇集在一起。这一天将包括主题演讲，项目展示和终端用户的故事，以及 BoF 会议。与同行会面并推动未来持续交付的方向。
重要日期  CFP 开始：4月29日，星期一 CFP 关闭：太平洋标准时间 5月17日，23:59，星期五 CFP 通知：5月29日，星期三 日程通知：5月30日，星期一 幻灯片截止：6月17日，星期四 活动时间：6月24日  建议的话题  CDF 的项目  Jenkins Jenkins X Tekton 和 Spinnaker 讲述你正在使用的这些项目的功能或者集成的功能，分享你为什么要使用以及如何利用这些项目解决了哪些问题  你们团队的持续交付  我们希望能听到真实项目中的使用，以及你们团队所推荐的持续交付实践  安全与合规性最佳实践  分享在持续交付中改善你们的软件供应链中的安全性的案例和技巧  帮助我们的同时也帮助自己 描绘你希望看到的 CI/CD 景象   点击这里提交你的演讲题目
点击这里查看其他更多的同场活动。</description>
    </item>
    
    <item>
      <title>Jenkins 版本发布</title>
      <link>https://jenkins-zh.github.io/wechat/articles/2019/05/2019-05-09-jenkins-release/</link>
      <pubDate>Thu, 09 May 2019 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.github.io/wechat/articles/2019/05/2019-05-09-jenkins-release/</guid>
      <description> 2.175 (2019-04-28)  当构建完成后，更新状态图标 (issue 16750) 插件管理页面提供了更方便的插件更新选项，包括：“全选”、“兼容的“或”全不选“。 “兼容”的选择（之前为“全选”）已经不再包括含有任何兼容性警告的插件。 (issue 56477) 从连接 Jenkins 节点的界面上移除会误导到 Java Web Start 和 JNLP 的链接等引用。 (pull 3998) 再次启用 Stapler 请求分发 telemetry。 (pull 3999) 确保远程对象仅通过远程通道被序列化。 确定永远不会设计以 XML 形式持久化到磁盘中的类包括： FilePath, [Stream]TaskListener, and ProcessTree. (issue 47896) 修复在 Linux 代理安装器中看到的一些错误。 (issue 57071) 使得 Debian/Ubuntu 启动器脚本对 Java 11 兼容。 (issue 57096) 开发者：使得 mvn -f war hudson-dev:run支持${port}。 (pull 3984)  2.174 (2019-04-21)  重命名一个代理节点，保持旧的配置，导致重启后旧的代理节点再次出现。 (issue 56403) 嵌套的视图现在也可以根据名称搜索了。 (issue 43322)  </description>
    </item>
    
    <item>
      <title>Jenkins 插件开发之旅：两天内从 idea 到发布(下篇)</title>
      <link>https://jenkins-zh.github.io/wechat/articles/2019/05/2019-05-08-jenkins-plugin-develop-within-two-days-part02/</link>
      <pubDate>Wed, 08 May 2019 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.github.io/wechat/articles/2019/05/2019-05-08-jenkins-plugin-develop-within-two-days-part02/</guid>
      <description>本文分上下两篇，上篇介绍了从产生 idea 到插件开发完成的过程； 下篇将介绍将插件托管到 Jenkins 插件更新中心的一系列过程。
托管插件 托管插件包括一系列流程步骤。 笔者完成了它所有步骤（包括非必须的步骤），其中主要有两个具有标志性的任务： - 插件代码被托管在 jenkinsci GitHub 组织的一个仓库，然后作者拥有它的管理权限。
笔者插件的代码仓库为：jenkinsci/maven-snapshot-check-plugin 。 - 你可以将插件发布到 Jenkins 项目的 Maven 仓库，它是 Jenkins 项目所使用的更新站点的数据来源。
准备工作 在请求插件托管之前，需要完成以下几个步骤。
查找类似的插件 Jenkins 社区欢迎任何人的贡献，但为了让 Jenkins 用户受益， 它要求查找解决相同或类似问题的插件，看看是否可以与现有的维护人员联手。 可以在 https://plugins.jenkins.io 查看所有的插件， 以确认是否已有类似的插件实现了你计划实现的功能。 笔者在之前已进行过查找，并没有找到可以实现笔者计划实现的功能的类似插件。
命名规约 Jenkins 制定了一些与插件相关的命名规约。 插件开发者要确保遵循这些命名规约。
artifactId 插件的 artifactId 被用于文件基本名称，是 Jenkins 插件和更新站点的唯一标识。
它需要遵循一些发布规约： - 使用小写 ID ，并根据需要使用连字符分隔术语。 - 除非名称有任何意义，否则不要在 ID 中包含 jenkins 或 plugin 。
插件名称 插件的名称在 Jenkins UI 和其它地方（如：插件站点）展示给用户。
如果可以，建议使用简短的描述性名称，如 Subversion 。
笔者所写的插件的名称为：Maven SNAPSHOT Check 。</description>
    </item>
    
    <item>
      <title>Jenkins 自动化安装插件</title>
      <link>https://jenkins-zh.github.io/wechat/articles/2019/05/2019-05-07-jenkins-install-plugins-shell/</link>
      <pubDate>Tue, 07 May 2019 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.github.io/wechat/articles/2019/05/2019-05-07-jenkins-install-plugins-shell/</guid>
      <description>手工安装 Jenkins 插件的方法 通常，我们有两种方法安装 Jenkins 插件。第一种方法是到 Jenkins 插件管理页面搜索插件，然后安装。第二种方法是上传 Jenkins 插件的 hpi 文件安装。这两种方法能满足大多数人的需求。
第一种方法，如下图所示： 第二种方法，如下图所示： 但是对于需要保证 Jenkins 稳定或在 Jenkins 上进行二次开发的同学来说，以上方法是无法满足需求的。
第一种方法是无法指定插件的版本。第二种方式必须自己找到该插件的依赖树，然后根据依赖关系一个个地安装。是的，手工上传插件的这种方法，Jenkins 是不会自动下载依赖的。
还有，就是这两种方式都无法实现批量安装。
自动安装插件的方法 那么，有什么方法能指定插件的版本，又能自动下载它的依赖，还能批量下载呢？
幸运的是，Jenkins 的 Docker 镜像的代码仓库里的 install-plugins.sh 脚本已经实现。只不过需要我们拿过来小小修改才能使用。笔者修改后创建了相应的代码仓库：jenkins-install-plugins-shell 。链接在文章末尾。
以下是 jenkins-install-plugins-shell 的使用方法： 1. 将代码 clone 到 JENKINS_HOME 目录中。
cd $JENKINS_HOME git clone https://github.com/zacker330/jenkins-install-plugins-shell.git cd jenkins-install-plugins-shell   在 plugins.txt 中加入希望安装的插件 在 jenkins-install-plugins-shell 目录中，有一个 plugins.txt 文件，在文件中写入希望安装的插件及版本号。例如：  ansible:1.0 powershell:1.3  执行安装
# Jenkins War 的路径，用于分析 export JENKINS_WAR_PATH=&amp;lt;Jenkins war文件的路径&amp;gt; chmod +x install-plugins.</description>
    </item>
    
    <item>
      <title>Jenkins 插件开发之旅：两天内从 idea 到发布(上篇)</title>
      <link>https://jenkins-zh.github.io/wechat/articles/2019/05/2019-05-06-jenkins-plugin-develop-within-two-days-part01/</link>
      <pubDate>Mon, 06 May 2019 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.github.io/wechat/articles/2019/05/2019-05-06-jenkins-plugin-develop-within-two-days-part01/</guid>
      <description>本文介绍了笔者首个 Jenkins 插件开发的旅程， 包括从产生 idea 开始，然后经过插件定制开发， 接着申请将代码托管到 jenkinsci GitHub 组织， 最后将插件发布到 Jenkins 插件更新中心的过程。
鉴于文章篇幅过长，将分为上下两篇进行介绍。
从一个 idea 说起 前几天和朋友聊天时，聊到了 Maven 版本管理领域的 SNAPSHOT 版本依赖问题， 这给他带来了一些困扰，消灭掉历史遗留应用的 SNAPSHOT 版本依赖并非易事。
类似问题也曾经给笔者带来过困扰，在最初没能去规避问题， 等到再想去解决问题时却发现困难重重，牵一发而动全身， 导致这个问题一直被搁置，而这也给笔者留下深刻的印象。
等到再次制定 Maven 规范时，从一开始就考虑 强制禁止 SNAPSHOT 版本依赖发到生产环境。
这里是通过在 Jenkins 构建时做校验实现的。 因为没有找到提供类似功能的 Jenkins 插件， 目前这个校验通过 shell 脚本来实现的， 具体的做法是在 Jenkins 任务中 Maven 构建之前增加一个 Execute shell 的步骤， 来判断 pom.xml 中是否包含 SNAPSHOT 关键字，如果包含，该次构建状态将被标记为失败。 脚本内容如下：
#!/bin/bash if [[ ` grep -R --include=&amp;quot;pom.xml&amp;quot; SNAPSHOT .` =~ &amp;quot;SNAPSHOT&amp;quot; ]]; then echo &amp;quot;SNAPSHOT check failed&amp;quot; &amp;amp;&amp;amp; grep -R --include=&amp;quot;pom.</description>
    </item>
    
    <item>
      <title>应该使用什么 CI/CD 工具？</title>
      <link>https://jenkins-zh.github.io/wechat/articles/2019/04/2019-04-30-what-cicd-tool-should-i-use/</link>
      <pubDate>Tue, 30 Apr 2019 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.github.io/wechat/articles/2019/04/2019-04-30-what-cicd-tool-should-i-use/</guid>
      <description>在我们正在进行的 Kubernetes FAQ 系列中，我们回答了社区中一些常见的问题，本周我们将讨论在选择 CI/CD 工具时需要考虑什么。
目前已经有大量的 CI/CD 工具可供选择-开源解决方案和商业解决方案。在这里，我们重点介绍在设置持续交付流水线时要考虑的一些最重要的注意事项。
在这篇文章中你将学到： - 为什么需要自动化流水线 - 部署典型流水线的组件 - CD 流水线功能需要考虑 - 如何合并 GitOps
为什么要创建自动化 CI/CD 流水线？ 自动化 CI/CD 流水线有许多好处： - 将您的上线时间从数周或数月减少到数天或数小时。通过自动化流水线，开发团队可以提高发布的速度以及代码的质量。以小增量连续添加的新功能和修复可以使产品具有更少的缺陷。 - 一个强大的开发团队。由于交付流水线的所有阶段都可供团队中的任何人检查、改进和验证，因此可以创建对构建的所有权，从而鼓励整个组织的强大团队合作和协作能力。 - 降低软件开发的风险和成本。自动化鼓励开发人员在继续前进之前分阶段验证代码更改，从而减少了缺陷最终出现在生产中的机会。 - 减少进展中的工作量。CD 流水线提供从开发到客户的快速反馈循环。这个迭代周期不仅可以帮助您构建正确的产品，而且还允许开发人员更快地进行产品改进，从而减少正在进行的工作。 典型的部署流水线 CD 流水线由几个不同的阶段组成; 一个工具不能满足所有这些步骤。
以下是构成大多数自动化流水线的步骤： 1. 在笔记本电脑上编写代码，将其推入源代码仓库(如 Git)。 2. 代码通过单元、集成和其他自动化测试。如果测试通过，将构建成新的 Docker 镜像。 3. 将镜像推送到镜像仓库。 4. 将新镜像推送到集群中。 思考 CD 流水线的特性 创建流水线的困难之一是成功地将您想要使用的工具粘合在一起。这些是为流水线选择工具时要考虑的主要功能： - 端到端的安全性 - 能够使用完全可重现的审计跟踪进行回滚 - 内置可观察性和警报功能 - 平均快速部署时间以及平均快速恢复时间 - 简单的开发人员经验和工作流程
流水线端到端的安全性 在市场上的 CI/CD 工具中，有些工具将 CI 和 CD 部分合并为一个工具。或者更糟糕的是，那些负责创建 CI/CD 流水线的人将组装一系列手工锻造的脚本，这些脚本可以在一个方向上通过流水线推送代码，或执行被称为CIOP 流水线。</description>
    </item>
    
    <item>
      <title>使用 Jenkins X 渐进式交付：自动化金丝雀部署</title>
      <link>https://jenkins-zh.github.io/wechat/articles/2019/04/2019-04-29-progressive-delivery-with-jenkins-x-automatic-cana/</link>
      <pubDate>Mon, 29 Apr 2019 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.github.io/wechat/articles/2019/04/2019-04-29-progressive-delivery-with-jenkins-x-automatic-cana/</guid>
      <description>这是渐进式交付系列的第三篇文章，前两篇请参见： - Kubernetes 中的渐进式交付：蓝绿部署和金丝雀部署 - 使用 Jenkins X 渐进式交付
渐进式交付被 Netflix， Facebook 以及其它公司使用用来减轻部署的风险。 但是现在你可以在使用Jenkins X时采用它。
渐进式交付是持续交付的下一步，它将新版本部署到用户的一个子集，并在将其滚动到全部用户之前对其正确性和性能进行评估，如果不匹配某些关键指标，则进行回滚。
尤其是，我们聚焦金丝雀发布，并让它在你的 Jenkins X 应用中变得易于采用。 金丝雀发布包括向应用程序的新版本发送一小部分流量，并在向其他用户发布之前验证这里没有错误。 Facebook 就是这样做的，首先向内部员工提供新版本，然后是一小部分用户，然后是其他所有用户，但是你要采用它并不需要成为 Facebook ！
你可以在 Martin Fowler 的网站阅读更多与金丝雀发布相关信息。
Jenkins X 如果在 Jenkins X 中你已经有一个应用，那么你知道的你可以 通过 jx promote myapp --version 1.0 --env production 命令 promote 它到&amp;rdquo;生产&amp;rdquo;环境。 但是，在检查新版本是否失败的同时，它也可以自动并逐步地向一定比例的用户推出。 如果发生失败，应用程序将自动回滚。 整个过程中完全没有人为干预。
注意：这个新功能是非常新的，在将来这些步骤将不再需要，因为它们也将由 Jenkins X 自动化了。
作为第一步，三个 Jenkins X 插件需要被安装： - Istio : 一种服务网格容许我们管理我们服务的流量。 - Prometheus ：Kubernetes 中最流行的监控系统。 - Flagger ：一个使用 Istio 的项目，该项目使用 Prometheus 的指标自动化进行金丝雀发布和回滚。</description>
    </item>
    
    <item>
      <title>我们为什么需要 DevSecOps 和制品仓库？</title>
      <link>https://jenkins-zh.github.io/wechat/articles/2019/04/2019-04-28-devsecops/</link>
      <pubDate>Sun, 28 Apr 2019 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.github.io/wechat/articles/2019/04/2019-04-28-devsecops/</guid>
      <description>Helen Beal 曾经在一次讨论什么是 DevSecOps 工程师的会议上发言。令她惊讶的是，在与会人员中，许多人都没有将安全机制引入 DevOps。在与人们讨论之后，她将大家的问题总结为三类：安全机制会制造额外的隔阂；组织中的人很难理解 DevOps，因此安全机制可能会造成更多困惑；可能没有为安全机制预留空间。
当然，Helen 不同意这些观点。她在技术领域从业近20年，专注于软件开发生命周期，对于 DevOps 和DevSecOps 有一些自己的理解。她自称为 Ranger4 的 「DevOpsologist」，因为她帮助那里的组织实现 DevOps。她在世界各地分享知识，并且她将参加我们在 2018 年的 Nexus User Conference ，讨论工具仓库及其在 DevSecOps 工具链中的角色。
从高层次来看，Helen 为 DevSecOps 提出了一些重要建议：
 确保安全是每一个人的职责 认识到安全人员的匹配限制。平均而言，人员比例为 100 名开发人员 : 10 名运维人员 : 1名安全人员 尽早移交产品进行测试和验证。缺乏足够的安全人员会造成一定的约束，移交并自动执行任务可以减少瓶颈并提前解决问题。 积极主动地降低风险 培养安全文化  Helen 花了一些时间阐述如何培养安全文化，组织在维护系统和人员行为安全时可以采用的一些关键原则和行动。
行为安全使个人和团队能够以安全的方式行事。为了培养行为安全，她建议：
 让人们意识到，失败是一个学习机会 确保团队之间有共同的责任和目标 不要吝啬花时间做实验 使用可协作的平台来分享学习经验和最佳实践 对实验的过程进行回顾，并确保有后续  她提到了几个真实的例子，例如 Esty，LEGO 还有 P&amp;amp;G 的「失败奖励」以及 Spotify 用来展示和追踪失败的「失败墙」。
系统安全能够保障你的基础设施安全，她关于培养系统安全的建议包括：
 用持续集成进行构建 使用部署自动化来驱动一致性和可审计性，并允许即时重新部署上一个已知的可用版本 用 ChatOps 来归类问题和事件 使用应用程序性能管理以提早发现问题并警告 降低出现问题波及范围，例如使用功能开关，金丝雀测试，蓝／绿环境和微服务 将产品需求与服务台相结合 养成使用混沌工程来找到失败原因的习惯  在讲述 DevSecOps 案例并说明如何灌输安全文化后，她将话题转向如何使用制品仓库。 毕竟，这是一个 Nexus 会议，制品仓库是 Nexus 的特色。</description>
    </item>
    
    <item>
      <title>使用 Jenkins X 渐进式交付</title>
      <link>https://jenkins-zh.github.io/wechat/articles/2019/04/2019-04-26-progressive-delivery-with-jenkins-x/</link>
      <pubDate>Fri, 26 Apr 2019 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.github.io/wechat/articles/2019/04/2019-04-26-progressive-delivery-with-jenkins-x/</guid>
      <description>这是渐进式交付系列的第二篇文章，第一篇请看：Kubernetes 中的渐进式交付：蓝绿部署和金丝雀部署。
我使用的我的 Croc Hunter 示例项目评估了 Jenkins X 中金丝雀部署和蓝绿色部署的三种渐进式交付方案。 - Shipper 为 Jenkins X 构建的 Helm 图表启用了蓝绿部署和多集群部署，但是对图表的内容有限制。 你可以在 staging 和生产环境之间做蓝绿部署。 - Istio 允许通过创建一个虚拟服务将一定比例的流量发送到 staging 或预览环境。 - Flagger 构建在 Istio 之上，并添加了金丝雀部署，可以根据指标自动进行滚动部署和回滚。 Jenkins X 可以通过创建一个 Canary 对象自动启用金丝雀功能，从而实现优雅的滚动部署，以升级到生产环境。
这里可以查看 Shipper、Isito 和 Flager 的示例代码。
Shipper 由于 Shipper 对创建的 Helm 图表有多个限制，因此我必须对应用做一些更改。 而且 Jenkins X 只从 master 分支构建 Helm 包，所以我们不能做 PRs 的滚动部署，只能对 master 分支做滚动部署。
应用标签不能包含发布名称，例如： app: {{ template “fullname” . }} 不起作用， 需要一些类似这样的标签： app: {{ .</description>
    </item>
    
    <item>
      <title>使用 Jenkins &#43; Ansible 实现自动化部署 Nginx</title>
      <link>https://jenkins-zh.github.io/wechat/articles/2019/04/2019-04-25-jenkins-ansible-nginx/</link>
      <pubDate>Thu, 25 Apr 2019 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.github.io/wechat/articles/2019/04/2019-04-25-jenkins-ansible-nginx/</guid>
      <description>本文介绍如何使用 Jenkins + Ansible 实现对 Nginx 的自动化部署。最终达到的效果有如下几点： 1. 只要你将 Nginx 的配置推送到 GitHub 中，Jenkins 就会自动执行部署，然后目标服务器的 Nginx 配置自动生效。这个过程是幂等（idempotent）的，只要代码不变，执行多少遍，最终效果不变。 2. 如果目标机器没有安装 Nginx，则会自动安装 Nginx。 3. 自动设置服务器防火墙规则。
1. 实验环境介绍 本次实验使用 Docker Compose 搭建 Jenkins 及 Jenkins agent。使用 Vagrant 启动一台虚拟机，用于部署 Nginx。使用 Vagrant 是可选的，读者可以使用 VirtualBox 启动一个虚拟机。使用 Vagrant 完全是为了自动化搭建实验环境。
以下是整个实验环境的架构图： 注意，图中的 5123 &amp;lt;-&amp;gt; 80 代表将宿主机的 5123 端口请求转发到虚拟机中的 80 端口。
 Vagrant：虚拟机管理工具，通过它，我们可以使用文本来定义、管理虚拟机。 Ansible：自动化运维工具 Docker Compose：它是一个用于定义和运行多容器 Docker 应用程序的工具。可以使用 YAML 文件来配置应用程序的服务。  2. 启动实验环境  克隆代码并进入文件夹 bash git clone https://github.com/zacker330/jenkins-ansible-nginx.git cd jenkins-ansible-nginx  构建 Jenkins agent 的镜像 需要自定义 Jenkins agent 镜像有两个原因：  本次实验，使用 Swarm 插件实现 Jenkins master 与 agent 之间的通信，所以 Jenkins agent 需要启动 swarm 客户端。 Jenkins agent 必须支持 Ansible。 bash docker build -f JenkinsSlaveAnsibleDockerfile -t jenkins-swarm-ansible .</description>
    </item>
    
    <item>
      <title>Kubernetes 中的渐进式交付：蓝绿部署和金丝雀部署</title>
      <link>https://jenkins-zh.github.io/wechat/articles/2019/04/2019-04-24-progressive-delivery-in-kubernetes-blue-green-and-canary-deployments/</link>
      <pubDate>Wed, 24 Apr 2019 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.github.io/wechat/articles/2019/04/2019-04-24-progressive-delivery-in-kubernetes-blue-green-and-canary-deployments/</guid>
      <description>渐进式交付是持续交付的下一步， 它将新版本部署到用户的一个子集，并在将其滚动到全部用户之前对其正确性和性能进行评估， 如果不匹配某些关键指标，则进行回滚。
这里有一些有趣的项目，使得渐进式交付在 Kubernetes 中变得更简单。 我将使用一个 Jenkins X 示例项目 对它们之中的三个进行讨论：Shipper、Istio 以及 Flagger。
Shipper shipper 是来自 booking.com 的一个项目， 它对 Kubernetes 进行了扩展，添加了复杂的部署策略和多集群编排（文档）。 它支持从一个集群到多个集群的部署，允许多区域部署。
Shipper 通过一个 shipperctl 命令行进行安装。 它增加不同集群的配置文件来进行管理。 请注意这个与 GKE 上下文相关的问题。
Shipper 使用 Helm 包来部署，但是它们没有随着 Helm 一起安装，它们不会在 helm list 的输出显示。 同样地，deployments 的版本必须是 apps/v1 ， 否则 shipper 将不能编辑 deployment 来添加正确的标签和副本数量。
使用 shipper 部署都是与从旧版本(现有版本)过渡到新版本(竞争版本)相关。 这是通过创建一个新的应用对象实现的， 它定义了部署需要通过的多个阶段。例如下面 3 个步骤过程： 1. Staging：部署新版本到一个 pod ，没有流量 2. 50 / 50：部署新版本到 50% 的 pods，50% 的流量 3. Full on：部署新版本到全部的 pods，全部的流量</description>
    </item>
    
    <item>
      <title>关于 Jenkins master 共享 JENKINS_HOME 目录的实验</title>
      <link>https://jenkins-zh.github.io/wechat/articles/2019/04/2019-04-23-jenkins-master-shared-home/</link>
      <pubDate>Tue, 23 Apr 2019 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.github.io/wechat/articles/2019/04/2019-04-23-jenkins-master-shared-home/</guid>
      <description>审校：王冬辉，linuxsuren
 Jenkins master 的高可用是个老大难的问题。和很多人一样，笔者也想过两个 Jenkins master 共享同一个 JENKINS_HOME 的方案。了解 Jenkins 原理的人，都会觉得这个方案不可行。但是真的不可行吗？
由于工作原因，笔者需要亲自验证以上猜想。
JENKINS_HOME 介绍 Jenkins 所有状态数据都存放文件系统的目录中，这个目录被称为 JENKINS_HOME 目录。
实验环境介绍 笔者通过 Docker compose 启动两个独立的 Jenkins master，分别为 jenkins-a 和 jenkins-b。它们共用同一个 JENKINS_HOME 目录。相应的代码仓库的链接放在文章底部。
将代码克隆到本地后，进入仓库，执行 docker-compose up -d 即可启动实验环境。启动完成，在浏览器中输入 http://localhost:7088 可访问 jenkins-a，jenkins-b 的地址是 http://localhost:7089 。但是你会发现它们启动后的界面显示是不一样的。
jenkins-b 的界面如下图所示：
而 jenkins-a 的界面如下图所示：
这时，将 jenkins-a 日志中的解锁密码（Unlock password）输入到 jenkins-b 的页面中，会得到报错信息：
ERROR: The password entered is incorrect, please check the file for the correct password  这时，再次 jenkins-b 日志中的解锁密码（Unlock password）输入到表单中即可进入下一步。接下来就是按照提示一步步完成了。在 jenkins-b 安装步骤的最后一步，我们设置了管理员的用户名密码：admin/admin。然后就算完成任务了。</description>
    </item>
    
    <item>
      <title>Jenkins 2.173 发布通知</title>
      <link>https://jenkins-zh.github.io/wechat/articles/2019/04/2019-04-22-jenkins-weekly-2.173/</link>
      <pubDate>Mon, 22 Apr 2019 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.github.io/wechat/articles/2019/04/2019-04-22-jenkins-weekly-2.173/</guid>
      <description>本次更新移除了一些不太推荐的功能，请管理员及时关注，如果希望能恢复的旧的形态，可以按照下面的提示操作。
另外，有一项重要的更新，使得我们可以把所有的中文本地化资源文件从 Jenkins 核心中移除。因此， 请关注 Jenkins 简体中文插件后续的动态，我们会及时完成所有的迁移。
 移除对 CCtray 文件的内置支持。
如果要继续使用该功能的话，请安装CCtray XML Plugin (issue 40750) 调整代码在远程计算节点上运行时的流刷新行为，使得具有更好的性能。
这可能导致插件在节点集群上输出日志，但是没有刷新时，丢失消息。
使用 -Dhudson.util.StreamTaskListener.AUTO_FLUSH=true 恢复自由风格构建之前的行为。注意，流水线的构建总是需要远程刷新。 (pull 3961) 增加用于将新创建的 API token 拷贝到粘贴板的按钮。 (issue 56733) 使得 Jenkins 经典界面上的表单提交按钮，对 Firefox 的 bug 修复是兼容的。 (issue 53462, Firefox bug 1370630) 如果一个工作空间已经被跨节点重连的流水线正在使用，那么，不会提供给新的构建。 (issue 50504) 从核心中移除 Mailer 相关的本地化字符串。确保你使用 Mailer Plugin 1.23。 (issue 55292) 从 Maven 控制台装饰器中适当地刷新输出。 (issue 56995) 开发者：更新 Stapler 1.256 到 1.257，增加对从任意插件中加载本地化 webapp 资源的支持。
增加接口 jenkins.PluginLocaleDrivenResourceProvider 使得插件可以参与本地化资源的查找。 (JEP-216, 完整的变更日志) 开发者：SystemProperties 可以在计算节点中使用。 参考 SystemProperties#allowOnAgent。 (pull 3961) 开发者：增加 LineTransformationOutputStream#Delegating 使得更加方便。 (pull 3959) 开发者：hudson.</description>
    </item>
    
    <item>
      <title>持续交付的商业价值</title>
      <link>https://jenkins-zh.github.io/wechat/articles/2019/04/2019-04-19-the-business-value-of-cd/</link>
      <pubDate>Fri, 19 Apr 2019 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.github.io/wechat/articles/2019/04/2019-04-19-the-business-value-of-cd/</guid>
      <description>持续交付使你能够以更低地风险、更快低交付新软件或是更新已有软件。
降低风险很重要，但是，支持持续交付的流程将转化为对业务更重要的价值： - 加速价值时间。 一个小企业不需要一个 MBA 就可以认识到持续交付可以帮助他们完成工作。 一家大型企业已经规划了其价值流， 并且在整个大型组织中拥有复杂的投资和合约， 将发现持续交付有助于加速实现价值的时间。 - 数据驱动决策。 部署、度量和调整。 你仍然可以推动更大规模的发布，但你的流程将更适合于持续的数据收集。 这将缩短与客户的反馈循环。 它提高了你的反应能力，计划你的下一步行动，并保持领先的竞争力。 - 质量。 你持续发布的行为使你必须提高你的质量标准以及完全的自动化测试实践。 更好的质量意味着更快乐的客户、更低的成本、更少的消防演习和更少的计划外工作。 - 试验 = 创新。 开发人员和业务线可以自由地以较低的成本尝试新的想法， 从而释放出长期高投资发布周期背后的创新想法。 - 降低成本。 大的发布会有巨大的成本，如果出现错误会有严重的后果。 保持可交付成果处于可发布状态会降低交付成本。
对企业来说，这些价值一起使持续交付成为真正的游戏变革者。 尽管可以在团队或项目级别开始采用和验证，但持续交付的本质是它以需要真正投资和自上而下承诺的方式跨越了组织边界。 选择与现有投资互补并共存的持续交付工具链是走向成功的关键一步， 特别是因为 CD 可以引导你的组织采用 DevOps 文化。
持续交付为创建更好的软件开辟了全新的道路。 CD 是商业层面的热门话题，这有很多的原因： - 早期的采用者已经证明了它的价值。 主流采用者都观察到了它的优势，并感觉到竞争的刺痛，因为他们更灵活的竞争对手超过了他们。 - DevOps 作为一种运动获得了关注。 业务人员理解，在开发和运营之间有一个共同的理解，打破孤立的行为，并在整个组织内发展一种责任文化，是提高效率和上市时间的关键步骤。 在许多方面，持续交付等同于 DevOps 。 - 随着软件“吞噬世界”，商业领袖们越来越清楚 IT 必须被用作战略资产。 在正确处理安全性、可用性和合规性的同时，能够缩短交付时间、提高质量并快速适应变化是一项挑战。 持续交付，强调自动化和尽早的、直接的反馈，是实现这些目标的方法。 - 当你通过持续交付实现廉价的、低风险的试验时，你可以用更多的信息指导业务投资，并发现你可能完全错过的机会。
持续交付正在改变企业使用其 IT 资产与客户和合作伙伴联系的方式。 CD 建立在多年来之不易的敏捷过程和持续集成经验的基础上， 将这些好处提升到业务级别，而不是简单地成为开发团队使用的技术， 并最终导致 DevOps 。 随着开发和运营人员学习如何协作和分担责任时，许多成功的关键都植根于组织和文化的变革。 无论是在组织范围内还是在本地，实现这种变革的技术工具链可能包括 Jenkins 。 CloudBees Jenkins 企业版，通过扩展开源 Jenkins 的使用范围， 提供了一个支持 Jenkins 混合模型（本地部署、云上部署或混合部署）的平台， 是组织在今天转向持续交付和在不久的将来实施 DevOps 的必要工具。</description>
    </item>
    
    <item>
      <title>AIOps：DevOps 的未来</title>
      <link>https://jenkins-zh.github.io/wechat/articles/2019/04/2019-04-17-aiops/</link>
      <pubDate>Wed, 17 Apr 2019 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.github.io/wechat/articles/2019/04/2019-04-17-aiops/</guid>
      <description>DevOps 和云技术正在逼近极限 范式转变往往会产生意想不到的后果，这些后果可能需要数年才能被完全消化。 云计算就是一个很好的例子。 云计算迎来了灵活的基础设施和低资本要求的时代，由于资源只是一个API调用，工程师们无需等待部署。 然而，这一切只是开始。
敏捷的公司利用云来打破开发和运维之间的隔阂，并采用敏捷方法以缩短开发周期，从而创造战略优势。 他们将应用程序生命周期中的工程师团队分工从之前的开发和测试变为部署和运维， 并创建了需要一系列新技能的职位。这些公司使用 CI/CD 和 DevOps 进一步推动自动化流水线， 以实现更快的交付。
这样有隐患吗？去问你的 DevOps 团队 DevOps 团队的任务是维护一个工具链，以便自动交付新代码，按需扩展，以及五个 9 的正常运行时间。 在空闲时间，他们致力于提高性能和控制成本。 对于大的应用程序，可以有数千个虚拟机或容器，每个虚拟机或容器都有一堆软件， 还有负载平衡器和自动扩容等云服务，所有这些都必须进行配置和维护。 这一切都在不断发展中。
我之前了解过的一个大型独角兽公司拥有数百名开发人员，每天更新代码超过 100 次， 云上有超过 4000 台虚拟机，每月收集数 PB 的数据。 而他们的 DevOps 团队只有十几个人手，直到去年才有 VP。 对他们来说，这是一个艰巨且繁重的任务。
应付这无数的挑战已经超出了人类的能力范围。
幸好，AIOps 正在成为一种解决方案。
AIOps 一词是由 Gartner 创造的， 他将其解释为：
AIOps 结合了大数据，机器学习和可视化技术，通过更强的洞察力来优化 IT 运维。 IT 的领导者应该开始部署 AIOps，以优化当前的性能分析，
并在未来两到五年内将使用范围扩展到 IT 服务管理和自动化。 虽然 Gartner 创造了这个术语，但以我拙见，这还没达到标准。 他的定义以循环中的人为中心，以他的描述 AIOps 基本上是一种高级的大数据分析。 要解决 DevOps 困境，我们要定一个更高的目标。
那么，AIOps 应该是什么？ 我们先从它不应该是什么开始：一个对现有的运维系统的修饰，软件供应商将&amp;rdquo;以 AI 驱动&amp;rdquo;作为卖点。 这种情况已经发生了，当新的技术威胁到现有利益时，往往会发生这种情况。 仅仅向已有工具添加一个 API 是不够的，如果决策需要人为干预，那就不能算是 AIOps。</description>
    </item>
    
    <item>
      <title>使用 Zabbix 监控 Jenkins</title>
      <link>https://jenkins-zh.github.io/wechat/articles/2019/04/2019-04-15-zabbix-monitor-jenkins/</link>
      <pubDate>Mon, 15 Apr 2019 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.github.io/wechat/articles/2019/04/2019-04-15-zabbix-monitor-jenkins/</guid>
      <description>本文假设读者已经了解 Jenkins 基本概念及插件安装，Zabbix 基础概念。基于 Zabbix 3.4，Jenkins 2.8 做实验
 笔者最近的工作涉及到使用 Zabbix 监控 Jenkins。在谷歌上搜索到的文章非常少，能操作的就更少了。所以决定写一篇文章介绍如何使用 Zabbix 监控 Jenkins。
下图为整体架构图：
整体并不复杂，大体步骤如下：
 在 Jenkins 上安装 Metrics 插件，使 Jenkins 暴露 metrics api。 配置 Zabbix server 及 agent 以实现监控及告警  为方便读者实验，笔者将自己做实验的代码上传到了 GitHub，链接在文章末尾。使用的是 Docker Compose 技术（方便一次性启动所有的系统）。
接下来，我们详细介绍 Metrics插件及如何实现 Zabbix 监控 Jenkins。
1. 使 Jenkins 暴露 metrics api 安装 Metrics 插件，在系统配置中，会多出“Metrics”的配置，如下图： 配置项不复杂。我们需要点击“Generate&amp;hellip;”生成一个 Access Key（生成后，记得要保存）。这个 Key 用于身份校验，后面我们会用到。
保存后，我们在浏览器中输入URL：http://localhost:8080/metrics/&amp;lt;刚生成的 Access Key&amp;gt; 验证 Jenkins 是否已经暴露 metrics。如果看到如下图，就说明可以进行下一步了。
1.1 Metrics 插件介绍 Metrics 插件是基于 dropwizard/metrics 实现。它通过4个接口暴露指标数据：/metrics，/ping，/threads，/healthcheck。</description>
    </item>
    
    <item>
      <title>简析 Jenkins 专有用户数据库加密算法</title>
      <link>https://jenkins-zh.github.io/wechat/articles/2019/04/2019-04-12-brief-analysis-the-encryption-algorithm-of-the-built-in-jenkins-user-database/</link>
      <pubDate>Fri, 12 Apr 2019 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.github.io/wechat/articles/2019/04/2019-04-12-brief-analysis-the-encryption-algorithm-of-the-built-in-jenkins-user-database/</guid>
      <description>认识Jenkins专有用户数据库 Jenkins 访问控制分为：安全域（即认证）与授权策略。
其中，安全域可以采用三种形式，分别为：Jenkins 专有用户数据库、LDAP、Servlet 容器代理。 在哪里看到加密后的用户密码信息？ Jenkins 专有用户的数据信息存放位置：$JENKINS_HOME/users/
每个用户的相关信息存放在各自的 config.xml 文件中： $JENKINS_HOME/users/$user/config.xml
在 config.xml 文件中的 passwordHash 节点可以看到用户密码加密后的密文哈希值： 用户密码是用什么算法加密的呢？ 那么问题来了，用户密码是用何种加密方式加密的呢？可否通过解密密文得到明文呢？
在 GitHub 上查看其源码，通过关键字 #jbcrypt 搜索定位到 HudsonPrivateSecurityRealm.java 这个文件。 HudsonPrivateSecurityRealm.java 具体路径是：jenkins/core/src/main/java/hudson/security/HudsonPrivateSecurityRealm.java
源码片段如下：
/** * {@link PasswordEncoder} that uses jBCrypt. */ private static final PasswordEncoder JBCRYPT_ENCODER = new PasswordEncoder() { public String encodePassword(String rawPass, Object _) throws DataAccessException { return BCrypt.hashpw(rawPass,BCrypt.gensalt()); } public boolean isPasswordValid(String encPass, String rawPass, Object _) throws DataAccessException { return BCrypt.</description>
    </item>
    
    <item>
      <title>Java 应用使用 Docker 的入门指南：建立一个 CI/CD 流水线</title>
      <link>https://jenkins-zh.github.io/wechat/articles/2019/04/2019-04-10-getting-started-with-docker-for-java-applications/</link>
      <pubDate>Wed, 10 Apr 2019 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.github.io/wechat/articles/2019/04/2019-04-10-getting-started-with-docker-for-java-applications/</guid>
      <description>Docker 已经非常出名并且更多的组织正在转向基于 Docker 的应用开发和部署。这里有一个关于如何容器化现有 Java Web 应用以及使用 Jenkins 为它建立一个端到端部署流水线的快速指南。
为此我使用了非常著名的基于 Spring 的宠物商店应用，它代表了一个很好的示例，因为大多数应用都遵循类似的体系结构。
步骤  构建宠物商店应用。 运行一次 Sonar 质量检查。 使用该 Web 应用准备 Docker 镜像。 运行容器以及执行集成测试。 如果所有测试成功，推送该镜像到一个 dockerhub 账户。  所有的代码都在这里。
这里是可用于以上步骤的 Jenkins 流水线代码：
node { stage &#39;checkout&#39; git &#39;https://gitlab.com/RavisankarCts/hello-world.git&#39; stage &#39;build&#39; sh &#39;mvn clean install&#39; stage(&#39;Results - 1&#39;) { junit &#39;**/target/surefire-reports/TEST-*.xml&#39; archive &#39;target/*.jar&#39; } stage &#39;bake image&#39; docker.withRegistry(&#39;https://registry.hub.docker.com&#39;,&#39;docker-hub-credentials&#39;) { def image = docker.build(&amp;quot;ravisankar/ravisankardevops:${env.BUILD_TAG}&amp;quot;,&#39;.&#39;) stage &#39;test image&#39; image.withRun(&#39;-p 8888:8888&#39;) {springboot -&amp;gt; sh &#39;while !</description>
    </item>
    
    <item>
      <title>介绍：成为一名 Jenkins 贡献者的旅程</title>
      <link>https://jenkins-zh.github.io/wechat/articles/2019/04/2019-04-08-becoming-contributor-intro/</link>
      <pubDate>Mon, 08 Apr 2019 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.github.io/wechat/articles/2019/04/2019-04-08-becoming-contributor-intro/</guid>
      <description>作为一名软件工程师，这些年来在我工作过的不同公司里用到过许多开源软件（包括框架、库、工具等）。 然而，在此之前我从没有以一名贡献者的身份参与过开源项目。
自从我向 Jenkins 提交第一个简单又滑稽的 commit 已经过去六个月（2018 年 9 月）了， 我也尝试过作出更多贡献。然而总的来说，向开源项目贡献代码是具有挑战的， 特别是像 Jenkins 这样有着很长生命周期的项目，项目中不乏遗留代码和系统知识。 它通常难以入手，也很难想到一个计划来持续贡献使你的付出从长远看来是有意义的。
对于 Jenkins 社区来说，我在尝试加入社区时所遇到的困难是其它人也有可能会面临的， 因此我决定分享我成为 Jenkins 活跃贡献者的心路历程。
我计划大概每月发布一篇博文来描述我的这段旅程，我将从简单容易入手的项目开始， 随着时间推移再介绍更加复杂的项目。
从哪开始 jenkins.io 要成为 Jenkins 的贡献者，首先会看到的就是 jenkins.io, 在顶部导航中&amp;rdquo;社区&amp;rdquo;下拉列表里第一个&amp;rdquo;参与&amp;rdquo;的链接就能将我们带到&amp;rdquo;参与和贡献&amp;rdquo;这个页面。
在这个页面中列举了我们能够参与 Jenkins 项目和社区的许多方式。尽管它展示了所有可能的选项供读者选择，但一下子看上去令人有些无所适从。
这个页面被分成了左右两个部分，左边提供了参与社区的方法，右边是向社区贡献的方法。
参与社区的建议 在“参与和贡献”页面的左侧是有关参与社区的建议，其中包括结交他人、审阅修改或者提供反馈信息。
这里面最让我困惑的是沟通渠道，里面列出的沟通渠道有 几个邮件列表 还有 IRC 和 Gitter 频道。
当我第一次尝试参与时，我订阅了许多邮件列表和几个 IRC 和 Gitter 频道，但我很快发现里面有重要的讨论正在进行， 并且活跃的讨论中多数是关于特定的用户或开发者的问题。因此，我不建议你一开始在这上面花太多时间， 除非你是要为其他用户提供帮助（当你是经验丰富的 Jenkins 用户时可能会有这种情况）或者你已经有一个明确的问题需要提问。
看一看社区成员如何互相帮助是好事，但是对新人来说它的信息量过于庞大。如果你的兴趣在于向 Jenkins 项目作贡献（不管是翻译、文档还是代码）， 这些对话不会对你有太大的帮助。
向社区贡献的建议 在“参与和贡献”页面的右侧有一些关于如何贡献的建议，主要分为：编写代码，翻译，文档和测试。
在之后的博客中，我将介绍所有的这些贡献类型，以及如何参与的建议包括如何审阅 Pull Requests（PRs）或提供反馈 （反馈问题或者复现其它用户反映过的问题，提供额外信息来帮助维护者复现和修复它们。）
开源之旅的第一次贡献 当看到「参与和贡献」页面时，我发现我可以帮助改进这个页面的一些内容。本来我打算选择其中一个作为这篇文章的第一个例子，但当我阅读贡献指南时， 我发现了一个更简单的贡献。我认为它可以更好的说明开始贡献社区是多么的简单，于是我决定就用它来当例子。
网站代码仓库 在「文档」菜单中有一个链接 jenkins.io 的贡献指南， 这个 CONTRIBUTING 文件是大多数开源项目代码仓库的根目录中都会有的常见文件。</description>
    </item>
    
    <item>
      <title>持续集成的收益与挑战</title>
      <link>https://jenkins-zh.github.io/wechat/articles/2019/04/2019-04-03-the-benefits-and-challenges-of-continuous-integration/</link>
      <pubDate>Wed, 03 Apr 2019 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.github.io/wechat/articles/2019/04/2019-04-03-the-benefits-and-challenges-of-continuous-integration/</guid>
      <description>毫无疑问，持续集成（ CI ）已成为一个软件开发的主流原则。CI 的收益在业界众所周知的，并且很难找到反对实施它的人。
在这里，我想把那些收益收集起来放到一个中心化的地方。但是我认为扮演反面角色并试图找出持续集成的弊端或挑战也是很有趣的。
什么是持续集成？ 从根本上说， 持续集成（ CI ）是一种开发实践，开发人员每天都要将代码集成到共享的仓库中。在该仓库中，代码被自动构建进行验证用来在这个流程中检验尽早的发现任何问题。这允许团队花更少的时间回溯，而花更多的时间构建新特性。
持续集成的收益 1、缓解风险 据 Martin Fowler 说，持续集成的最大收益是减轻风险。由于延迟了代码集成，团队将不断增加合并冲突的数量和严重性。当团队频繁集成（使用自动构建），他们减轻了潜在风险的数量，因为他们总是知道系统的当前状态。
2、质量保证 实施持续集成的团队对他们的操作更有信心。他们知道自动构建会立即捕获缺陷，这使他们能够保证质量。 他们也不会猜测系统中 bug 的数量，这允许他们能够向队友提供准确的数量，并为客户提供更好的服务。
3、提高可见性和加强团队合作 自动构建为团队提供了对其系统的完全可见性。他们知道问题的数量，并能快速的解决问题。提高可见性可以让团队有机会在小问题变成大之前通过协作解决。
持续集成的挑战 1、组织文化变革 一些企业更喜欢传统的方法，并且可能很难实施持续集成。 他们必须对员工进行再培训，这就意味着要对现有的业务进行大修。管理者可能会抵制因为持续集成并不能帮助他们实现公司的直接目标（例如：金钱在质量之上）。
2、难以维护 构建一个自动化的代码仓库不是一个简单的任务。 团队必须构建适当的测试套件，并花时间编写测试用例，而不是开发代码。 起初，这可能会让他们放慢速度，让他们对按时完成自己的项目失去信心。如果测试套件不稳定，它可能在某些天内完美地工作，但其他天可能不起作用。 然后团队将不得不花费更多的时间来弄清楚发生了什么。
3、大量的错误信息 对于较大的开发团队，他们可能每天都会看到 CI 错误消息，并开始忽略它们，因为它们还有其他任务和关注点。 他们可能会开始将一个破坏的构建视为一个正常的事情，并且缺陷可能开始堆积在一起。</description>
    </item>
    
    <item>
      <title>Jenkins 更新通知</title>
      <link>https://jenkins-zh.github.io/wechat/articles/2019/03/2019-03-18-weekly-version/</link>
      <pubDate>Wed, 20 Mar 2019 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.github.io/wechat/articles/2019/03/2019-03-18-weekly-version/</guid>
      <description>Jenkins LTS 2.164.1 更新内容如下：  Java 11 现已全面支持。 自 2.150.x 开始在 Java 11 上运行 Jenkins 的多项改进，包括：支持插件在它们的元数据中申明最小 Java 版本，并拒绝加载不兼容的插件，以及当运行在 Java11 上时安装新的 JAXB 插件后允许使用 JAXB 的 API. (博客发布的申明, 运行在 Java 11, 升级到 Java 11, issue 52012, issue 52282, issue 55076, issue 55048, issue 55980, issue 55681, issue 52285) 当列出一个指定目录时 list-jobs 不再进行递归。 (issue 48220) 增加一个新的 CLI 命令 disable-plugin 来禁用一个或多个已安装的插件，并可以选择同时重启 Jenkins. (issue 27177) 更新 Trilead SSH 库以支持 OpenSSH 使用 AES256-CTR 加密。 (issue 47603, issue 47458, issue 55133, issue 53653) 在 Jenkins CLI 中增加对 ed25519 关键算法的支持。 (issue 45318) 减少以 ZIP 格式下载归档或者工作空间文件时 SECURITY-904 对性能的影响。 (issue 55050) 在插件向导中增加语言分类，并会根据浏览器的语言设置自动安装本地化插件。 (pull 3626) Windows Service Wrapper 从 2.</description>
    </item>
    
    <item>
      <title>Jenkins 正在加入持续交付基金会</title>
      <link>https://jenkins-zh.github.io/wechat/articles/2019/03/2019-03-20-cdf-launch/</link>
      <pubDate>Wed, 20 Mar 2019 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.github.io/wechat/articles/2019/03/2019-03-20-cdf-launch/</guid>
      <description>今天Linux 基金会与 CloudBees、Google 和一些其他公司启动了一个新的开源软件基金会，也就是持续交付基金会(CDF). CDF 相信持续交付的力量，它旨在培养与支持开源生态，以及厂商中立的项目。
Jenkins 的贡献者们已经决定，我们的项目应该加入这个新的基金会。 实际上，这样的讨论持续了多年，大致的动机简洁摘要在这里。
此时，作为一名用户，又意味着什么呢？
 首先，不会有大的中断。还是同样的人，URL 地址不会变，也会有正常的发布。决策方式也会延续，pull request 也不会发生变化。改变会逐步的进行。
 这是 Jenkins 项目在这个领域的成熟和重要性的又一证明。在全球有25万个 Jenkins 在运行着，这着实从 IoT 到游戏、从云原生应用到机器学习项目撼动着整个软件研发的世界。对于任何寻求开放异构 DevOps 策略的人来说， Jenkins 是一个显然、安全的选择。
 CDF 创建了一个公平竞争的环境，这被组织中的贡献者所熟知，同时也会带来更多的贡献者，让 Jenkins 发展的更好、更快。在过去的几年里， Jenkins 项目正在稳步地增长，更多的结构使之变得清晰起来，CDF 是这一轨迹中的最新一步。
 任何认真的研发团队都会把多种工具和服务结合起来，以覆盖整个软件研发领域。这些团队为了把这些工具集成起来投入了大量的工作。 Jenkins 将会在 CDF 旗下与其他项目紧密合作，使得这些软件之间减少重复。
 我们的用户作为从业者尝试在他们的组织中改善软件研发流程。他们认为 CI/CD 和自动化可以释放组织所需要的生产力，但对他们的组织而言，并不总是那么显著。因此，我们的用户往往无法得到必要的支持。CDF 将会倡导持续交付的实践，因为这并不是来自某个厂商或项目，它将会联系可以提供帮助的人。
  因此，我希望你能明白为什么我们会对此感到如此兴奋！
实际上，对我们来说，已经为这个想法努力了将近两年。毫不夸张地说，整个 CDF 的想法 源自 Jenkins 项目。
为此，已经有很多人在幕后做了大量的工作。但有些人扮演了举足轻重的角色，我须亲自感谢他们。为 Chris Aniszczyk 的耐心、坚持，R. Tyler Croy 酝酿并推动着这个想法，Tracy Miranda 将这些想法变成事实。</description>
    </item>
    
    <item>
      <title>Electron 应用的流水线设计</title>
      <link>https://jenkins-zh.github.io/wechat/articles/2019/03/2019-03-13-electron-pipeline-demo/</link>
      <pubDate>Wed, 13 Mar 2019 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.github.io/wechat/articles/2019/03/2019-03-13-electron-pipeline-demo/</guid>
      <description>审校：LinuxSuRen（https://github.com/LinuxSuRen）
 面向读者：需要了解 Jenkins 流水线的基本语法。
Electron 是由 Github 开发，用 HTML，CSS 和 JavaScript 来构建跨平台桌面应用程序的一个开源库。
本文将介绍 Electron 桌面应用的流水线的设计。
但是如何介绍呢？倒是个大问题。笔者尝试直接贴代码，在代码注释中讲解。这是一次尝试，希望得到你的反馈。
完整代码 pipeline { // 我们决定每一个阶段指定 agent，所以， // 流水线的 agent 设置为 none，这样不会占用 agent agent none // 指定整条流水线的环境变量 environment { APP_VERSION = &amp;quot;&amp;quot; APP_NAME = &amp;quot;electron-webpack-quick-start&amp;quot; } stages { stage(&amp;quot;生成版本号&amp;quot;){ agent {label &amp;quot;linux&amp;quot; } steps{ script{ APP_VERSION = generateVersion(&amp;quot;1.0.0&amp;quot;) echo &amp;quot;version is ${APP_VERSION}&amp;quot; }} } stage(&#39;并行构建&#39;) { // 快速失败，只要其中一个平台构建失败， // 整次构建算失败 failFast true // parallel 闭包内的阶段将并行执行 parallel { stage(&#39;Windows平台下构建&#39;) { agent {label &amp;quot;windows &amp;amp;&amp;amp; nodejs&amp;quot; } steps { echo &amp;quot;${APP_VERSION}&amp;quot; } } stage(&#39;Linux平台下构建&#39;) { agent {label &amp;quot;linux &amp;amp;&amp;amp; nodejs&amp;quot; } // 不同平台可能存在不同的环境变量 // environment 支持阶段级的环境变量 environment{ SUFFIX = &amp;quot;tar.</description>
    </item>
    
    <item>
      <title>Jenkins 已经被 Google Summer Of Code 2019 接受！</title>
      <link>https://jenkins-zh.github.io/wechat/articles/2019/03/2019-03-13-gsoc2019-announcement/</link>
      <pubDate>Wed, 13 Mar 2019 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.github.io/wechat/articles/2019/03/2019-03-13-gsoc2019-announcement/</guid>
      <description>作为 Jenkins GSoC 管理员团队的代表，我很高兴地宣布 Jenkins 在2019年的 Google Summer of Code上 已经被接受。 今年，我们邀请了学生和导师加入 Jenkins 社区，并一起努力增强 Jenkins 生态圈。
这里提供一些数字，这是有史以来最大的一次 GSoC，今年共有206个组织参与。并且，希望对 Jenkins 而言也是最大的一年。 我们有25个项目想法，而且有超过30个准导师（不断增多！）。 这已经超过了2016年以及2018年的总和。 有很多的插件，特别兴趣小组以及子项目已经加入了今年的 GSoC.而且，我们已经收到了十几个学生的消息以及第一次贡献，耶！
下一步？ GSoC 已经正式启动，请期待更多的学生在我们的Gitter 频道和邮件列表中联系项目。 在特别兴趣小组和子项目频道中已经有了很多沟通。 我们会努力帮助学生找到他们感兴趣的项目，在这个领域探索，并帮助他们在4月9日的截止日前准备好他们的项目提议。 然后，我们将会继续这个申请，选择项目并分配导师团队。
所有关于 Jenkins GSoC 的信息都可以在子项目页面上找到。
我是一个学生。如何申请？ 在/projects/gsoc/students[学生的信息]页面中有完整的申请指导。
我们鼓励感兴趣的学生尽早联系 Jenkins 社区并开始探索项目。所有的项目在对应的页面上都有聊天室与邮件列表。 我们也会为学生组织工作日的会议，在这些会议上你可以见到管理员和导师，并向他们提问。 另外，加入我们的Gitter 频道和邮件列表，以便收到项目中即将到来的事情。
3月25日开放申请，但你现在就可以准备了！利用这段申请前的时间来讨论并改进你的项目提议。 我们也建议你着手熟悉 Jenkins 并开始探索你的提议的领域。项目的想法包括快速开始的指导，以及有助于初期研究时对新手友好的问题。 如果没有看到任何感兴趣的，你可以提出你自己的项目想法或者 查看由其他参与 GSoC 的组织提出的想法。
我想要成为一名导师。会不会太晚了？ 不晚！我们正在寻找更多的项目想法，以及 Jenkins 的贡献者或用户中对 Jenkins 富有热情并想要指导学生的人。 无须底层经验，导师可以和学生一起研究项目并给出技术指导。 我们尤其对 Java 技术栈方向感兴趣，以及一些新的技术和领域（例如：Kubernetes, IoT, Python, Go 或者其他的）。
你可以提议一个新项目或者加入已有的。查看博客寻找导师以及导师的信息中的细节。 如果你想要提议一个新项目，那么请在3月11日之前完成，以便学生有时间探索并准备他们的提议。
今年，导师并不必须要有 Jenkins 开发上的很强的专业知识。目标是指导学生参与到 Jenkins 社区。 如果需要特殊的专业知识，GSoC 组织管理员会帮助寻找顾问。</description>
    </item>
    
    <item>
      <title>为 Continuous Delivery Foundation 的成立感到兴奋</title>
      <link>https://jenkins-zh.github.io/wechat/articles/2019/03/2019-03-13-ready-for-cdf/</link>
      <pubDate>Wed, 13 Mar 2019 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.github.io/wechat/articles/2019/03/2019-03-13-ready-for-cdf/</guid>
      <description>大概十一年前，我就开始为现在被称为 Jenkins 的项目做贡献，自己当时其实也并不知道在做什么。但是接下来发生的事情令人感觉难以置信，数以百计的贡献者加入，成千上万的新用户开始使用 Jenkins，每天都会运行数以百万条的流水线。这样的增长是充满挑战性的，用户的增长意味着问题的增长，问题的增长就意味着需要新的解决方式。 在大约两年半之前，我在2017年的 Jenkins World Contributor Summit 大会上面对一大群 Jenkins 的贡献者们，为我的所谓的 &amp;lsquo;Jenkins软件基金会&amp;rsquo; 做了宣传，那就是，不要羞于从 Python 社区汲取思想，在我的朋友 Chris Aniszczyk 和 Linux 基金会的帮助下，这个基金会变成了一个更加全面的 *持续交付基金会*（CDF），我的同事 Tracy Miranda 一直在领导这项工作，帮助推动 CDF 的成立。
Kohsuke 为 jenkinsci-dev@ mailing list 撰写了一篇很好的概述文章，其中列举了如果 Jenkins 项目一旦建立后就应该加入 Continuous Delivery Foundation 的原因。如果你对 Jenkins 项目感兴趣，但是还没有阅读过这边文章的话，那我认为你应该花些时间来阅读 Kohsuke 的这份邮件。但是在 这篇文章 中，我 想分享我愿意帮助建立持续交付基金会（CDF）的原因。
持续交付（CD）已经成为我职业生涯中不可或缺的一部分，甚至在 Jez Humble 将此概念清晰地表述之前，我就开始学习 CD 并且对它一直充满热情。我认为它对软件的开发实践至关重要，当有人说他们没有练习使用 CI 或 CD 时，我感觉这就像回到了原始社会。想象一下，如果有人说 &amp;ldquo;呃，我们在这里有一个采用 Source Control 的项目，但领导们觉得这个东西不太靠谱&amp;rdquo;，我想你肯定会惊掉下巴。&amp;rdquo;在这个时代竟然还有开发团队都不使用源代码管理？&amp;rdquo;。总体来说，我认为CD已经是现代软件开发的基础了。
持续交付也 不是 说只依赖于 Jenkins 这样的单一工具，它也是依赖于其他的用于协同工作的许多工具。虽然我可能觉得 Jenkins 是所有工具中占最中心位置的工具，但也不是说 Jenkins 是这些工具中唯一优秀的一款工具。但是不幸的是，像 Jenkins 这样的许多开源社区往往对他们的世界有着一定的狭隘观点。他们只专注于他们的事情，虽然这是有道理的，但这及可能导致错失交叉合作产生新价值的机会。</description>
    </item>
    
    <item>
      <title>MPL - 模块化的流水线库</title>
      <link>https://jenkins-zh.github.io/wechat/articles/2019/03/2019-01-08-mpl-modular-pipeline-library/</link>
      <pubDate>Wed, 06 Mar 2019 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.github.io/wechat/articles/2019/03/2019-01-08-mpl-modular-pipeline-library/</guid>
      <description>MPL - 模块化的流水线库 尽管通过自动化部署加快了开发速度，但由于在 DevOps 方面缺少协作，我们一个客户正因此而放慢产品的上市时间。虽然他们也投入了资源来做 DevOps ，但每条生产流水线都是独立设置的，迫使团队为每个项目重新造轮子。更糟糕的是，由于没有跨团队协作，平台中的任何错误又会出现在每条新的流水线中。许多客户都有类似的问题存在，因此我们决定开发一个既能帮助现有客户，又能适应未来使用需求的通用工具。使用通用框架且标准化的 CI/CD 平台是最显而易见的选择，但这将导致缺少灵活性的单体结构（monolithic structure），最终会变得举步维艰。每个团队都需要在自己的流水线上工作，基于此，我们开发了一个方便 DevOps 流水线的每个可重用部分可供以后使用的解决方案 — Jenkins 驱动的模块化流水线库。
解决方案：模块化流水线库 模块化流水线库（译注：modular pipeline library，简称 MPL）是一个高度灵活的 Jenkins 流水线共享库，它可以轻松将最佳实践共享到整个公司。它具有清晰的模块化结构，先进的测试框架，多级嵌套的能力，流水线配置系统，被改进了的错误处理机制以及许多其他有用的组件。
我们将通过以下几部分内容深入了解并解释 MPL 是如何工作的：
 探索用于构建 MPL 的技术和工具 回顾MPL，并说明它为何有效 一步一步在流水线样例中使用 MPL 深入研究 MPL 的一些重要的组件，例如测试框架和嵌套库  首先，让我们介绍构建 MPL 时使用到的关键技术。
使用共享库和 Jenkins 流水线构建 MPL 我们的 Jenkins 自动化平台最近收到了一些 Jenkins 流水线的更新。这些更新允许我们创建一个 Jenkinsfile 文件来描述整条流水线，并用于执行一系列不言自明的脚本。这提高了最终用户对 CI/CD 自动化流程的可视化程度，并提高了 DevOps 团队对流水线的可支持性。
然而，流水线存在一个很大的问题：很难用唯一的流水线支持多个 Jenkinsfile 文件（因此存在多少个项目就存在多少个 Jenkinsfile 文件）。我们需要一个地方存放公共逻辑，这正是 Jenkins 共享库能够实现的。共享库用于存放流水线公共的部分，它定义在 Jenkinsfile 文件中，并允许在其中使用接口简化自动化脚本。
虽然共享库允许你存储公共逻辑并操作 Jenkins，但它们并没有提供一种好的方式去使用这些公共逻辑。所以，MPL 通过允许用户创建易于理解的流程描述来优化流水线和共享库，然后方便其他团队使用。
MPL 致力于创建跨团队协作 DevOps 流程 通过 MPL，我们现在能够跨团队协作和共享 DevOps 实践，轻松地为特定的项目指定特定的流水线，并能在将它们集成到 MPL 库中之前进行调试和测试。每个团队都可以创建一个嵌套库，在其中增加流水线和模块，并在流水线中使用，这样还可以提高流水线的可视化程度。MPL 能够适用于任何包含 Jenkinsfile 文件的项目，还可以根据项目团队的需要灵活地管理它。</description>
    </item>
    
    <item>
      <title>批量修改 Jenkins 任务的技巧</title>
      <link>https://jenkins-zh.github.io/wechat/articles/2019/02/2019-02-27-jenkins-script-console-in-practice/</link>
      <pubDate>Wed, 27 Feb 2019 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.github.io/wechat/articles/2019/02/2019-02-27-jenkins-script-console-in-practice/</guid>
      <description>通过脚本命令行批量修改 Jenkins 任务 最近，笔者所在团队的 Jenkins 所在的服务器经常报硬盘空间不足。经查发现很多任务没有设置“丢弃旧的构建”。通知所有的团队检查自己的 Jenkins 任务有没有设置丢弃旧的构建，有些不现实。
一开始想到的是使用 Jenkins 的 API 来实现批量修改所有的 Jenkins 任务。笔者对这个解决方案不满意，经 Google 发现有同学和我遇到了同样的问题。他使用的更“技巧”的方式：在 Jenkins 脚本命令行中，通过执行 Groovy 代码操作 Jenkins 任务。
总的来说，就两步：
 进入菜单：系统管理 &amp;ndash;&amp;gt; 脚本命令行 在输入框中，粘贴如下代码：
import jenkins.model.Jenkins import hudson.model.Job import jenkins.model.BuildDiscarderProperty import hudson.tasks.LogRotator // 遍历所有的任务 Jenkins.instance.allItems(Job).each { job -&amp;gt; if ( job.isBuildable() &amp;amp;&amp;amp; job.supportsLogRotator() &amp;amp;&amp;amp; job.getProperty(BuildDiscarderProperty) == null) { println &amp;quot; \&amp;quot;${job.fullDisplayName}\&amp;quot; 处理中&amp;quot; job.addProperty(new BuildDiscarderProperty(new LogRotator (2, 10, 2, 10))) println &amp;quot;$job.name 已更新&amp;quot; } } return; /** LogRotator构造参数分别为： daysToKeep: If not -1, history is only kept up to this days.</description>
    </item>
    
    <item>
      <title>社区贡献激励活动</title>
      <link>https://jenkins-zh.github.io/wechat/articles/2019/02/2019-02-27-contribution-inspire/</link>
      <pubDate>Wed, 27 Feb 2019 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.github.io/wechat/articles/2019/02/2019-02-27-contribution-inspire/</guid>
      <description>自 Jenkins 官方微信公众号开通以来，收到了很多热心、愿意参与开源社区的同学的贡献。这里，包括有 Jenkins 官方博客中的博文翻译，也有 Jenkins 中文站点维护的 Pull Request。我能够看到的是，有些同学从英文技术文章的翻译过程中，对 Jenkins 相关技术的理解更加深入了；而有的则从对 GitHub 不甚了解到逐渐熟悉社区贡献的大致流程；对于深度参与社区贡献的同学，更是能够在“中文本地化”以及 Jenkins 其他的特别兴趣小组（SIG）会议讨论上获得最新的动态。
本着给社区贡献者谋福利的想法，Jenkins 中文社区携手“人民邮电出版社”给大家提供三本技术相关的书籍。从19年3月开始，截止到5月，我们会给予三名贡献者每人一本书。我们会在下次公众号文章中介绍评选规则，欢迎任何一位认可开源、希望参与开源的朋友提出你的建议，不要吝惜你的 PR。获选的同学，按照贡献量可以从下面的列表中依次任选一本：
最后，再次让我们对“人民邮电出版社”给予开源社区的大力支持表示感谢。</description>
    </item>
    
    <item>
      <title>Java 11 预览支持已在 Jenkins 2.155&#43; 中可用</title>
      <link>https://jenkins-zh.github.io/wechat/articles/2019/02/2019-02-20-java11-preview-availability/</link>
      <pubDate>Wed, 20 Feb 2019 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.github.io/wechat/articles/2019/02/2019-02-20-java11-preview-availability/</guid>
      <description>NOTE: 这是由 Java 11 支持团队 联合撰写的博客。 在 12 月 18 号（UTC时间下午4点）我们也会在 Jenkins 在线 Meetup 展示对 Java 11 的预览支持。（链接）
 Jenkins 作为领先的开源自动化服务器之一，目前仍然只支持到 Java 8。在 9 月 25 日 OpenJDK 11 发布了。这是一个长期支持版本，并将持续多年，我们想要在 Jenkins 项目中对这个版本进行全面的支持。在过去的一年中，许多贡献者一直致力于在项目中支持 Java 11（Jenkins JEP-211）。这是一条艰辛的道路，但是现在，代表 Jenkins Platform SIG，我们很高兴的宣布在 Jenkins 每周发布提供 Java 11 预览！
为什么我们需要 Java 11 的预览？
这是因为它可以提供给 Jenkins 贡献者和早期使用者一个在明年年初（译者注：此文发布于 2018 年）GA 发布之前尝试这些变化的途径。它也可以帮助我们进行更多的探索性测试，并且有希望在 Jenkins 正式地提供 Java 11 支持之前，解决大部分的问题。
在这篇文章中，我们将会介绍如何在 Java 11 环境下运行 Jenkins，还有如何调查兼容性问题并报告它们。
背景 你可能还记得，在 2018 年 6 月我们举办了一个针对 Java 10+ 支持的在线黑客马拉松。作为黑客马拉松的一部分，我们提供了 Java 11 的实验性支持。这次活动对我们来说非常成功。我们可以在 Java 10 和 Java 11-ea 环境下运行 Jenkins 以及一些主要的功能 —— 包括流水线、JobDSL、Docker/Kubernetes plugin、Configuration as Code、BlueOcean 等。它让我们相信我们可以在 Jenkins 中提供Java 11支持而不会发生破坏性变化。在这场马拉松之后 Oleg Nenashev 创建了 &amp;ldquo;Java 10+ support in Jenkins&amp;rdquo;（之后修改为只针对支持 Java 11）。Jenkins Platform SIG 也已成立，以协调 Java 11 的支持工作和其他平台的支持工作（打包，操作系统支持等）。</description>
    </item>
    
    <item>
      <title>Jenkins 对审计日志的支持</title>
      <link>https://jenkins-zh.github.io/wechat/articles/2019/02/2019-02-13-outreachy-audit-log-plugin/</link>
      <pubDate>Wed, 13 Feb 2019 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.github.io/wechat/articles/2019/02/2019-02-13-outreachy-audit-log-plugin/</guid>
      <description>今年是 Jenkins 项目首次参与 Outreachy. Outreachy 是一个类似于 Google Summer of Code (GSoC) 的项目， 实习生有偿地为开源项目工作。 关键的不同之处在于，Outreachy 面向那些在他们国家的技术行业中受到歧视或偏见的小众群体。 当我了解到这个项目后，由于它的包容性与社区建设与我的理念相符就立即自愿作为导师来参与。 我很高兴地说，Jenkins 项目和我的雇主 CloudBees 对此非常支持。
基于我们之前在 GSoC 上指导学生的付出，今年我们已经加入 Outreachy 并指导了两个实习生。 在 Outreachy 的这次活动中，我们的实习生 David Olorundare 和 LathaGunasekar 将与我一起研发 Jenkins 对审计日志的支持。 我很高兴欢迎 David 和 Latha, 并期待他们能在软件工程专业和对开源社区的贡献上都有所收获。 请继续关注后续博客对他们的介绍。
该审计日志支持项目在 Jenkins 和 Apache Log4j 之间形成了一个新的链接，这给予我们的实习生学习 更多有关开源治理和认识新朋友的机会。 作为奖金，该项目旨在为支持高级的业务检测提供便利，例如：在认证事件中检测潜在的入侵尝试。 我们也会编写一个 JEP 来描述由插件提供的审计日志 API,以及其他插件如何定义并记录除 Jenkins 核心以外插件的审计事件。
我期待我们将会一起完成了不起的作品，而且我希望在将来能够帮助更多的 Outreachy 实习生！</description>
    </item>
    
    <item>
      <title></title>
      <link>https://jenkins-zh.github.io/wechat/articles/readme/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.github.io/wechat/articles/readme/</guid>
      <description>这里存放的是 Jenkins 官方微信公众号文章，文件采用 Markdown 格式，但包含一些必要的描述性字段。文章的校对、审核、排期等都通过 Pull Request 来完成。PR 合并后会发布到 Jenkins 中文社区网站。
目录 文章以发布的排期来存放，层级为：年份/月份。如果月份为个位数的话，要以0开头，例如：01。
以文章的文件名前缀作为图片的目录，例如：文章的文件名为 2019-01-01-sample.md，我们需要在同级目录下创建文件夹 2019-05-01-sample ， 并在里面保存当前文章中的图片（封面、插图等）。
排期 为了尽可能满足你期望的发布日期，可以自行选择，但同时需要满足如下的条件：
 为保障大家有足够的时间进行 Review，建议排到一周以后 工作日 避免同一天有相同类型的文章  文件名 文件名前缀为“年月日”，中间部分需要以英文来描述，英文字母需要全部小写。例如：2019-01-01-sample.md。
字段 文件中的字段，是为了描述文章相关的必要信息。具体的说明请参考：sample.md。</description>
    </item>
    
    <item>
      <title>Jenkins 中文社区邀您来上海共同参与2019年的国际开源盛宴</title>
      <link>https://jenkins-zh.github.io/wechat/articles/2019/04/2019-04-15-kubecon-cn/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.github.io/wechat/articles/2019/04/2019-04-15-kubecon-cn/</guid>
      <description>KubeCon + CloudNativeCon | Open Source Summit | 持续交付峰会 中国2019 2019年4月10日，旧金山 - Linux基金会是一家以开源促进大众创新的非营利组织，今天公布将于2019年6月24至26日在中国上海举行的 KubeCon + CloudNativeCon + Open Source Summit 中国2019日程。
Open Source Summit 中国2019前身为 LinuxCon + ContainerCon + CloudOpen 中国（LC3），是开源社区寻求合作、共享信息、了解当今最有影响力的开源技术和议题的重要平台，包括：云原生、无服务器、微服务、物联网、人工智能、网络、Linux 等。
2019年，首次将Open Source Summit中国和KubeCon + CloudNativeCon中国整合成一项活动，只需购票一次即可参加KubeCon + CloudNativeCon + Open Source Summit中国。
本届持续交付峰会将由 CNCF 承办在大会的第 0 天举行，汇聚了各个开源 CI/CD 社区。
Jenkins 中文社区成员在大会上将进行分享 Jenkins 中文社区成员夏润泽（北京优帆科技有限公司）将在大会上作为演讲嘉宾为大家带来主题为 Jenkins X 在 kubernetes 之上运行的无服务器 Jenkins 的分享。
Jenkins 中文社区邀您参与社区共同成长 在开源盛会开展的同时，我们希望能够与更多的小伙伴们一同在线上完善开源社区氛围、线下深度互动，努力构建一个有内容、有态度的优质技术社区。</description>
    </item>
    
    <item>
      <title>Jenkins 中文语言包</title>
      <link>https://jenkins-zh.github.io/wechat/articles/2019/01/2019-01-16-localization-zh-cn-plugin/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.github.io/wechat/articles/2019/01/2019-01-16-localization-zh-cn-plugin/</guid>
      <description>部分 Jenkins 中文用户可能已经发现，在最近升级 Jenkins 版本，或下载较新的 Jenkins 后，界面上很多部分显示的是英文。对此，我简单介绍一下原因以及如何安装中文插件。
各种语言的本地化资源文件都是集中存放在 Jenkins Core 及其插件中，这对于要做本地化贡献的人来说，需要向很多代码仓库中提交 PR。最明显的一个现象就是，这些仓库不一定都会有熟悉中文的维护者，因此导致 PR 无法真实、及时地进行 Review 以及合并发布。基于以上的考虑，我开发了简体中文插件，并从 Jenkins 2.145 版本中把大部分的中文本地化资源文件迁移到了该插件中。而且，最终会对 Jenkins Core 以及流行的插件中所有的中文本地化资源文件进行迁移。
安装简体中文插件也很简单，只要在 Jenkins 的插件管理界面上，搜索*中文*就能找到该插件。安装并重启后就能看到中文界面。
更多细节请查看 变更记录 。欢迎对中文本地化工作感兴趣的同学加入我们！</description>
    </item>
    
    <item>
      <title>Jenkins 和 Kubernetes -云上的神秘代理</title>
      <link>https://jenkins-zh.github.io/wechat/articles/2019/01/2019-01-30-k8s-jenkins-secet-agent/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.github.io/wechat/articles/2019/01/2019-01-30-k8s-jenkins-secet-agent/</guid>
      <description>最近我们构建和部署服务的方式与原来相比简直就是突飞猛进，像那种笨拙的、单一的、用于构建单体式应用程序的方式已经是过去式了。我们努力了这么久，终于达到了现在的效果。现在的应用为了提供更好的拓展性和可维护性，都会去拆解成各种相互依赖小、解耦性强的微服务，这些服务有各自的依赖和进度。如果你想去构建你所负责的服务，那么从一开始，就应该使用 CI/CD 的方式；当然，如果你走上了这条路， Jenkins 就是你的良师益友。
如果你是做微服务的话，那让我们在开始之前先花些时间想一想。如果你只在 Jenkins 上构建单体式应用程序，那你肯定每天都会运行很多 Jenkins job, 而且还要不厌其烦地运行很多次。所以，我们应该好好想清楚怎么样来做出一些改变来适应这种事情。其实只需要付出一些努力，Jenkins 就可以帮我们很好地解决这种事情。
我的 Jenkins 的进阶之路 作为一个 Devops 从业者，我遇到的最大问题是如何管理并优化自己的 Jenkins agent 结构。如果只是用 Jenkins 玩玩，实验性地跑一些流水线，那根本不用考虑 agent 的事情。如果你每天要跑成百上千条流水线的话，那考虑怎么去做优化就是一件非常非常重要的事情了。在 Jenkins 进阶之路中，我也尝试了各种不同的方式来寻找最好的 Jenkins agent 的使用方式。相信如果你也和我一样经历过，那下面这些事情你一定会很熟悉喽。
下面是我在这些年中使用 Jenkins 的各个阶段.
 所有的构建都在 master 节点上跑，在这个节点上运行所有的组件. (我给这个阶段起了个可爱的名字， Hello Jenkins) 创建一个 Jenkins EC2 代理，并且在这个代理上运行所有的构建，怎么说呢， 就是大而全，这个节点什么都能做。如果需要同时做多条任务，那就把这个大而全的节点克隆一份。 (这个阶段我起的名字是 Monster Agent.) 为每种服务创建不同的 Jenkins EC2 的节点 (这个阶段我起的名字叫做 Snowflake Agent.) 在容器中运行流水线的所有步骤。 打个比方，在 Jenkins 中使用 Docker Plugin 这个插件将代理挂载到容器中，或者使用 multi-stage Dockerfiles 把所有构建，测试打包的流程都封装起来。这两种方法都是很好的容器抽象化的开端，并且允许您轻松地将制品从一个容器复制到另一个容器。当然了，每一种方法都是需要访问 Docker engine 的。为了让我的 Jenkins 代理能够正常工作，现在我用以下几种方式来管理 docker host 在我的 Jenkins 主容器中运行一个Docker engine - Docker in Docker (DinD) 把主机上的 Docker socket 挂载到我的容器中来，让我的容器能够以 sidecar 的方式运行。 为 Jenkins 主服务器配置单个外部 EC2 Docker 主机，以用于在容器中启动构建 使用 EC2 插件和包含 Docker Engine 的 AMI 动态启动代理，然后运行多阶段 Dockerfile 中的所有步骤  以上这些阶段各有利弊，但都是为了让我们从管理 Jenkins 节点中解放出来。不过，最近我又进阶到了另外一个阶段：Jenkins on Kubernetes.</description>
    </item>
    
    <item>
      <title>Windows 安装程序更新</title>
      <link>https://jenkins-zh.github.io/wechat/articles/2019/02/2019-02-27-windows-installers/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.github.io/wechat/articles/2019/02/2019-02-27-windows-installers/</guid>
      <description>Jenkins 的 Windows 安装程序已经存在很多年了，它是用户在 Windows 上安装 Jenkins Master 作为服务的一种方式。 从被开发出来至今，它还没有什么新特性，但现在是时候做出改变了。
首先，让我们瞧瞧现版本安装程序的使用经验。
第1步 启动安装程序 这是使用 WiX Toolset Windows 安装程序的默认界面外观，算不上太好看，而且没有太多对安装程序进行说明的品牌信息。
第2步 安装目录 同样，没有太多的品牌信息。
第3步 安装 除了选择安装位置外，安装程序大体上没有提供一些安装 Jenkins 的选项。
问题 现在的安装程序存在一些问题，平台特别兴趣小组会修复这些问题，并为用户提供新的安装体验。
 安装程序只支持32位安装。 用户不能选择 Jenkins 作为 Windows 服务启动时的端口以及账户。 安装程序捆绑了32位的 Java Runtime，而没有使用已存在的 JRE。 安装程序不支持 Jenkins for Java 11中的实验性支持。 JENKINS_HOME 目录并不适合现代 Windows。 安装程序中没有品牌。  前进 使用实验性的 Jenkins Windows 安装程序，大部分问题都已解决！
 安装程序将只支持64位系统，这也是如今大多数 Windows 系统的现状，所以能让更多的用户能够使用安装包来安装 Jenkins。 用户能够为服务输入用户信息，同时选择端口以便于 Jenkins 验证端口是否可用。 安装程序不再捆绑 JRE 而是在操作系统中寻找合适的 JRE。如果用户想要使用一个不同的 JRE，可以在安装时指定。 安装程序已经支持 Java 11，包括在 Java 11 预览上面列出的组件。 JENKINS_HOME 目录被放置在启动服务用户的 LocalAppData 目录下，这与现代 Windows 文件系统布局一致。 安装程序已经升级带有品牌了，这让它看起来更酷并能提供一个更好的用户体验。  截图 以下是新安装程序的系列屏幕截图：</description>
    </item>
    
    <item>
      <title>什么是 CI/CD?</title>
      <link>https://jenkins-zh.github.io/wechat/articles/2019/04/2019-04-12-what-is-cicd/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.github.io/wechat/articles/2019/04/2019-04-12-what-is-cicd/</guid>
      <description>CI/CD 的出现改变了开发人员和测试人员发布软件的方式。本文是描述这一变化的系列文章第一篇， 这些文章将提供各种工具和流程的讲解，以帮助开发人员更好的使用 CI/CD。
从最初的 瀑布模型， 到后来的 敏捷开发， 再到今天的 DevOps， 这是现代开发人员构建出色产品的技术路线。 随着 DevOps 的兴起，出现了持续集成，持续交付（CI/CD）和持续部署的新方法， 而传统的软件开发和交付方式在迅速变得过时。过去的敏捷时代里， 大多数公司的软件发布周期是每月、每季度甚至每年（还记得那些日子吗？）， 而在现在 DevOps 时代，每周、每天甚至每天多次都是常态。 当 SaaS 成为业界主流后尤其如此，您可以轻松地动态更新应用程序， 而无需强迫用户下载更新组件。很多时候，用户甚至都不会注意到正在发生变化。
开发团队通过软件交付流水线（Pipeline）实现自动化，以缩短交付周期， 大多数团队都有自动化流程来检查代码并部署到新环境。 我们一直在关注自动化测试流程，但这将在之后的文章中介绍。 今天，我们将介绍什么是 CI/CD/CD ，以及现代软件公司如何使用工具将部署代码的流程自动化。
持续集成注重将各个开发者的工作集合到一个代码仓库中，通常每天会进行几次， 主要目的是尽早发现集成错误，使团队更加紧密结合，更好地协作。 持续交付的目的是最小化部署或发布过程中团队固有的摩擦， 它的实现通常能够将构建部署的每个步骤自动化，以便任何时刻能够安全地完成代码发布（理想情况下）。 持续部署是一种更高程度的自动化，无论何时代码有较大改动， 都会自动进行构建／部署。
以上的每一个阶段都是交付流水线的一部分。 Humble 和 Ferley 在他们的书作《持续交付：通过自动化构建、测试和部署实现可靠软件版本发布》中解释说： 「对软件的每次更改都要经过一个复杂的过程才能发布，该过程包括多个测试和部署阶段进行软件的构建。 反过来看，这个过程需要许多人之间的合作，甚至可能需要几个团队间合作。 部署流水线对这一过程进行建模，并且它的持续集成和发布管理工具能让您在代码从版本控制转移到各种测试和部署时， 查看和控制每次更改的过程。」
持续集成（CI） 通过持续集成，开发人员能够频繁地将其代码集成到公共代码仓库的主分支中。 开发人员能够在任何时候多次向仓库提交作品，而不是独立地开发每个功能模块并在开发周期结束时一一提交。
这里的一个重要思想就是让开发人员更快更、频繁地做到这一点，从而降低集成的开销。 实际情况中，开发人员在集成时经常会发现新代码和已有代码存在冲突。 如果集成较早并更加频繁，那么冲突将更容易解决且执行成本更低。
当然，这里也有一些权衡，这个流程不提供额外的质量保障。 事实上，许多组织发现这样的集成方式开销更大，因为它们依赖人工确保新代码不会引起新的 bug 或者破坏现有代码。 为了减少集成期间的摩擦，持续集成依赖于测试套件和自动化测试。 然而，要认识到自动化测试和持续测试是完全不同的这一点很重要，我们会在文章结尾处详细说明。
CI 的目标是将集成简化成一个简单、易于重复的日常开发任务， 这样有助于降低总体的构建成本并在开发周期的早期发现缺陷。 要想有效地使用 CI 必须转变开发团队的习惯，要鼓励频繁迭代构建， 并且在发现 bug 的早期积极解决。
持续交付（CD）实际上是 CI 的扩展，其中软件交付流程进一步自动化，以便随时轻松地部署到生成环境中。 成熟的持续交付方案也展示了一个始终可部署的代码库。使用 CD 后，软件发布将成为一个没有任何紧张感的例行事件。 开发团队可以在日常开发的任何时间进行产品级的发布，而不需要详细的发布方案或者特殊的后期测试。</description>
    </item>
    
    <item>
      <title>使用 YAML 文件配置 Jenkins 流水线</title>
      <link>https://jenkins-zh.github.io/wechat/articles/2019/01/2019-01-23-configuring-jenkins-pipeline-with-yaml-file/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.github.io/wechat/articles/2019/01/2019-01-23-configuring-jenkins-pipeline-with-yaml-file/</guid>
      <description>几年前，我们的 CTO 写了一篇关于 使用 Jenkins 和 Docker 为 Ruby On Rails 应用提供持续集成服务 的文章。这些年，我们一直使用这个 CI 流水线解决方案，直到我们最近决定做一次升级。为什么呢？
 Jenkins 的版本过低，已经很难升级 Wolox 过去几年增长显著，一直面临着如何伸缩的问题 只有极少数人如何修复 Jenkins 服务的问题 配置 Jenkins 任务不是一件简单的任务，使我们的项目启动过程变慢 更改每个作业运行的命令也不是一件简单的任务，并且有权限更改的人并不多。 Wolox 拥有广泛的项目，语言种类繁多，使得这个问题尤为突显。  考虑到这些问题，我们开始深入研究最新版的 Jenkins，看看如何提升我们的 CI 服务。我们需要构建一个新的CI服务，至少要解决以下问题：
 支持 Docker 构建。我们的项目依赖的一个或多个 Docker 镜像的执行（应用，数据库，Redis 等） 如有必要，易于配置和复制 易于增加新项目 易于修改构建步骤。工作在项目上的所有人都应该能修改它，如果他们希望执行 npm install 或 yarn install  安装Jenkins和Docker 安装 Jenkins 非常简单，直接从 官方教程 选择一种方式安装。
以下是我们在 AWS 上的安装步骤：
sudo rpm — import https://pkg.jenkins.io/debian/jenkins.io.key sudo wget -O /etc/yum.repos.d/jenkins.repo http://pkg.jenkins.io/redhat/jenkins.repo sudo yum install java-1.</description>
    </item>
    
    <item>
      <title>在安全防火墙内通过 WebHook 触发构建</title>
      <link>https://jenkins-zh.github.io/wechat/articles/2019/01/2019-01-16-webhook-firewalls/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.github.io/wechat/articles/2019/01/2019-01-16-webhook-firewalls/</guid>
      <description>在这篇文章中，我将向大家展示，如何让运行在防火墙内的 Jenkins 依然可以实时地收到 GitHub 的 WebHook。当然，你也可以把这个方法应用到如 BitBucket、 DockerHub 或任何可以推送 WebHook 的其他服务中。但是，下面的步骤仅适用于托管在 GitHub 上的项目。
什么是 WebHook 简单地描述下什么是 WebHook：事件消息（通常是 JSON，也可以是其他的）由服务端以 HTTP(S) 协议发送到监听的客户端。
事件流自左到右，Jenkins 会监听类似 /github-webhook/ 或 /dockerhub-webhook/ 等路径上的 HTTP 请求，唤醒并执行一些任务。
GitHub 或 BitBucket 可能会报告一个新的提交或 PR，DockerHub 报告一个上游的镜像发生了变更。这些事情的共同之处在于，它们会推送给 Jenkins，并期待可以推送成功（例如：可以访问到 Jenkins）。在网络是开放的情况下时，例如 GitHub 企业版 或 Jenkins 在监听公网时，这是可以正常工作的。
内网环境 当有东西挡在中间时，也就是防火墙：
（_按照行业标准，所有防火墙都必须能起到屏障的作用。因此，无论如何，请不要在你的组织内搞破坏_）
当你在笔记本电脑上运行 Jenkins 并希望从 GitHub 接收 WebHook 时，这也是一样的。可能是为了测试你的设置，也可能是为了在 Mac 上运行 iOS 版本构建，又或者是部分网络没有暴露在互联网中，这都是合理的。 除非你的笔记本电脑可以让整个互联网访问到（这当然不太可能），或者你的网络配置得恰到好处，否则网络连接将无法流动，此时 WebHook是不可用的。
没关系，我们可以退而求其次，使用轮询变更的方式。只是这样很糟糕。你会用尽 API 配额，还无法实时地获取变更，这真的不是一个好方法。
问题可能也是机会 我们可以解决这个问题，但也可以把这个视为一个机会。有的东西在互联网中不可访问，或者以某些默认的方法锁定是一个特色，不是一个 Bug。你可以很大程度上减少你的攻击面，同时可以进行深度防护：
一个 WebHook 转发服务 输入 link:https://smee.io/[Smee] 这个很容易记住的名字。这是一个由 GitHub 提供的 link:https://github.</description>
    </item>
    
    <item>
      <title>成为一名 Jenkins 贡献者：对新手友好的工单</title>
      <link>https://jenkins-zh.github.io/wechat/articles/2019/06/2019-06-24-becoming-contributor-newbie-tickets/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.github.io/wechat/articles/2019/06/2019-06-24-becoming-contributor-newbie-tickets/</guid>
      <description>两个月前，我发表了一篇介绍性文章， 成为一名 Jenkins 贡献者的旅程。在那篇第一次发表的文章 review 过后，学习到了我们可以参与和贡献的多种途径。 因此，在这个站点仓库中有对首次、基础的贡献的描述。
现在，我们将会在这篇文章中探索更多高级的贡献，向 Jenkins 核心中提交代码。
从工单和过程开始 新手贡献指导以及 Jenkins Jira 查看位于 jenins.io 上的开发者章节可能是最好的起点， 参考链接也很方便。同时，向 Jenkins 贡献的新手指导也很有用，因为它指出了不同的仓库、工具（例如问题跟踪系统）以及治理文档。 此外，它还描述了提交消息、代码风格约定、PR 指导等的最佳实践。
一旦我们对之前描述的有了一般性的了解，并想要真正地开始编码，我们可能会对该做些什么感到困惑。
似乎浏览Jenkins 问题跟踪系统是顺其自然 的下一步，因为那里充满了已经由社区报告了的潜在的缺陷和待改进的部分。然而，你很容易被无数的可能性列表所淹没。 请记住一点，对于一个像这样有十年历史之久的项目，很多是为新手准备的。因此，通过newbie-friendly tickets来过滤可能是最好的主意。
选择一个工单 在我案例中，我花了一些时间来浏览带 newbie-friendly 标签的工单，直到发现了一个我似乎感兴趣并看起来有能力修复的：
过程 在这个阶段，当我们准备接手这个工单时，最好让社区中的其他人知道我们正在开始解决它。我们可以很容易做到这一点， 只要把工单分配给我们自己即可（查看工单概览下的 “_Assign_” 按钮）。
在 Jenkins 的 Jira 中把工单分配给我们自己的话，可以让其他的贡献者知道我们正在处理；另外，为了保证其他人有兴趣对此一起做贡献时，可以知道 该去联系谁或者如何询问状态。也就是说，把工单分配给你自己，并不意味着其他贡献者就无法继续推进。Jenkins 是一个开源项目，欢迎任何人创建他们自己 的 PR，因此，任何人都可以在工单中提出自己的方案。但是，你也能想到，如果工单分配给某个人的话，大多数人在开始工作前也可能会去联系承接人。
与之相关的是，请牢记当我们把工单分配给自己时，不应该在这个工作上拖延太久。其他的贡献者，可能会由于工单已被分配而忽略。
当我们马上就要开始工作时，推荐的做法是先点击&amp;rdquo;Start Progress&amp;ldquo;按钮。这个动作，会把状态修改为“_In progress_”，对社区而言， 意味着我们正在处理这个工单。
在我们的电脑设置必要的工具 配置，安装和测试 正如在该旅程的第一篇文章中描述的，开始为某个仓库做贡献的第一步 是首先派生到我们自己的 GitHub 账号下，然后，克隆到你的电脑上。
正如，在 Jenkins Core 仓库中的CONTRIBUTING 文件里 所描述的，让仓库在本地运行的必要步骤。它包括，安装必要的开发工具：Java Development Kit (https://adoptopenjdk.net/[OpenJDK] 为推荐的选择)，Maven 以及任意支持 Maven 项目的 IDE。注意，安装 JDK 和 Maven 的步骤在贡献指南中有链接。</description>
    </item>
    
    <item>
      <title>春季安全清查</title>
      <link>https://jenkins-zh.github.io/wechat/articles/2019/04/2019-04-15-security-spring-cleaning/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.github.io/wechat/articles/2019/04/2019-04-15-security-spring-cleaning/</guid>
      <description>今天我们公布了一个 安全报告， 主要是关于 Jenkins 的插件中 还没有被修复 的问题。 发生了什么？
Jenkins 安全团队将 漏洞反馈分类发布在 Jira 和我们的非公开邮件列表中。 一旦我们确定它不是由 Jenkins 安全团队成员维护的插件，我们会尝试将该问题通知插件维护者，以帮助我们开发，审查和发布修复。
这种情况下，我们会发布 安全报告，将这些问题告知用户，即使没有发布修复版本。 这样可以让管理员作出决定，是否继续使用具有未解决的安全漏洞的插件。 今天发布的报告里大多数都是这样的安全问题。
在这个列表中看到您感兴趣的插件并且想要帮忙？了解如何 认领一个插件。</description>
    </item>
    
    <item>
      <title>自动更新、易于使用的 Jenkins</title>
      <link>https://jenkins-zh.github.io/wechat/articles/2019/01/2019-01-09-jenkins-evergreen/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.github.io/wechat/articles/2019/01/2019-01-09-jenkins-evergreen/</guid>
      <description>当我第一次 写 Jenkins Evergreen 相关的文章 ， 后来被称为 &amp;ldquo;Jenkins Essentials&amp;rdquo;，我提到的一系列的未来的发展在接下来的几个月里已经变成了 现实 。 今年在旧金山举办的 DevOps World - Jenkins World 会议上，我会介绍 Jenkins Evergreen 背后哲学的更多细节，展示我们已经做了什么，并且讨论这个激进的 Jenkins 发行版的走向。
正如我在第一篇博客以及 JEP-300 中所讨论的 Jenkins Evergreen 的前两大支柱是我们关注的要点.
自动更新的发行版 不出所料, 实现安全、自动地更新Jenkins发行版（包括核心和插件）所需的机制需要很多的工作。在 Baptiste 的演讲中 他将讨论如何使 Evergreen &amp;ldquo;走起来&amp;rdquo;，而我会讨论 为何 自动更新的发行版很重要。
持续集成和持续交付变得越来越普遍，并且是现代软件工程的基础 ，在不同的组织当中有两种不同的方式使用 Jenkins 。在一些组织当中，Jenkins 通过 Chef ，Puppet 等自动化工具有条不紊的被管理和部署着。然而在许多其他组织当中， Jenkins 更像是一个 设备 ，与办公室的无线路由器不同。当安装完毕，只要它能继续完成工作，人们就不会太多的关注这个设备。
Jenkins Evergreen 发行版通过确保最新的功能更新，bug 修复以及安全性修复始终能安装到 Jenkins 当中,&amp;ldquo;让 Jenkins 更像是一个设备&amp;rdquo;。
除此之外, 我相信 Evergreen 能够向一些我们现在没有完全服务的团队提供良好的服务:这些团体希望能够以 服务 的形式使用 Jenkins 。我们暂时没有考虑提供公有云版本的 Jenkins 。我们意识到了自动接收增量更新，使用户可以在无需考虑更新 Jenkins 的情况下进行持续开发的好处。</description>
    </item>
    
  </channel>
</rss>