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.cn/wechat/</link>
    <description>Recent content in Wechats on Jenkins 中文社区</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>zh-CN</language>
    <lastBuildDate>Wed, 17 Jun 2020 00:00:00 +0000</lastBuildDate>
    
	<atom:link href="https://jenkins-zh.cn/wechat/index.xml" rel="self" type="application/rss+xml" />
    
    
    <item>
      <title>GitHub App 身份验证支持已发布</title>
      <link>https://jenkins-zh.cn/wechat/articles/2020/06/2020-06-17-github-app-authentication-support-released/</link>
      <pubDate>Wed, 17 Jun 2020 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.cn/wechat/articles/2020/06/2020-06-17-github-app-authentication-support-released/</guid>
      <description>我很高兴的宣布在 Jenkins 中作为 GitHub 应用进行身份验证现已支持。这是许多用户期待已久的功能。它已在 GitHub Branch Source 2.7.1 中发布，现在可以在 Jenkins 更新中心使用。
身份验证为 GitHub 应用带来了很多好处：
 更高的请求频率限制 - GitHub 应用程序的速率限制随您的组织规模而定，而基于用户的令牌的限制为 5000，无论您拥有多少存储库。 与用户无关的身份验证 - 每个 GitHub 应用都有自己的用户独立身份验证。不再需要“机器人”用户或确定谁应该是 2FA 或 OAuth 令牌的所有者。 改进的安全性和更严格的权限 - 与服务用户及其个人访问令牌相比，GitHub Apps 提供了更精细的权限。这使 Jenkins GitHub 应用程序需要更少的权限集即可正常运行。 访问 GitHub Checks API - GitHub Apps 可以访问 GitHub Checks API 以从 Jenkins 作业创建检查运行和检查套件，并提供有关提交和代码注释的详细反馈。  开始使用 安装 GitHub Branch Source 插件，确保版本为 2.7.1 或更高。
配置 GitHub Organization 文件夹 遵循 GitHub App Authentication setup guide。这些说明也可在 GitHub 上的插件 README 文件中看到。</description>
    </item>
    
    <item>
      <title>使用 Prometheus 和 Grafana 监控 Linux 进程</title>
      <link>https://jenkins-zh.cn/wechat/articles/2020/06/2020-06-03-monitoring-linux-processes-using-prometheus-and-grafana/</link>
      <pubDate>Wed, 03 Jun 2020 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.cn/wechat/articles/2020/06/2020-06-03-monitoring-linux-processes-using-prometheus-and-grafana/</guid>
      <description>无论你是否是一名 Linux 系统管理员或是一名 DevOps 工程师，你都会在监控服务器性能指标的时候花费很长时间。
有时候实例运行非常慢但是哪里出的问题却没有任何线索。
有一些不响应的实例会阻止你在这些实例上执行类似 top 或者 htop 的远程命令。
服务器有一个瓶颈存在，但是你并不能简单快速的找到问题所在。
 如果我们有一个完整的仪表盘可以帮助我们跟踪整体性能以及独立的进程该怎么操作？
可以在该链接中实时查看: http://grafana.devconnected.com/d/nZMDMoiZk/grafana-top?orgId=1&amp;amp;refresh=5s
 这篇入门文章旨在如何为 Linux 系统管理员创建一个完整的监控仪表盘
该仪表盘会展示完全可定制并且可扩展到分布式架构的多个实例的不同面板。
你将会学到什么 在即将踏入技术旅途之前，让我们快速看下通过阅读这篇文章你将学到哪些东西:
 了解在 Unix 系统性能监控方面的最新技术；
 怎样安装最新版本的 Prometheus v2.9.2、Pushgateway v0.8.0 以及 Grafana v6.2；
 构建一个简单的 bash 脚本用来导出指标项到 Pushgateway；
 构建一个完整的 Grafana 仪表盘包括最新的面板例如 ‘Gauge’ 和 ‘Bar Gauge’。
 额外内容: 集成 ad-hoc 过滤器跟踪单个进程或实例。
  现在我们大体浏览了一下我们将要学习哪些东西，并且没有进一步的要求，让我们介绍一些当前 Unix 系统中目前已有的内容。
Unix 进程监控基础 当提到 Unix 系统进程监控的时候，在你脑海中出现的有好几个选项。
最流行的或许就是 ‘top’ 了。
这个命令在系统管理员中间被广泛使用当系统出现性能瓶颈或许是第一条执行的命令（如果你可以访问它当然就是第一条！）
top 命令可读性已经是非常好了，但是仍有一条命令比 top 命令可读性更好：htop。</description>
    </item>
    
    <item>
      <title>你的 DevOps 大脑：思考方式和工作方式</title>
      <link>https://jenkins-zh.cn/wechat/articles/2020/06/2020-06-01-Your-DevOps-Brain-Ways-of-Thinking-Ways-of-Working/</link>
      <pubDate>Mon, 01 Jun 2020 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.cn/wechat/articles/2020/06/2020-06-01-Your-DevOps-Brain-Ways-of-Thinking-Ways-of-Working/</guid>
      <description>我经常不得不说的 DevOps 神话之一就是 DevOps 完全是关于自动化和工具的。尽管二者是达到 DevOps 目标的基本要素（ DevOps 的目标是为了更快更安全地交付更有价值成果而优化从创意到价值实现的过程），但在 DevOps 的发展初期，Damon Edwards 和 John Willis 提出了 CALMS 这一缩写词来帮助解释有关 DevOps 的问题，其中字母 C 表示的文化也是一个重要元素。该想法得到了 Gartner 一篇文章的支持。该文章提到研究表明有 50％的受访者表示人的问题（与流程、技术和信息的问题相对）是目前采用 DevOps 原理和实践的最大障碍。我对自己客户的观察也支持这一想法，我的客户说文化是他们当下面临的最困难的挑战。
客户从一开始就这么说。大约七年前，当我们启动 Ranger4 的 DevOps 业务时，我们以为正在构建的是一个围绕软件和工具的业务。我们之前做么做过，并且这样做也是作为技术人员的合理选择。我们惊讶于客户一遍又一遍地问我们该如何改变文化。我们习惯于谈论技术；情感和感觉这些“软性”的东西是在饮水机旁闲谈的内容，或者用英式术语，说是酒吧里的话题。但是，当我们立即开始帮助客户后就迅速弄清了，文化可以被量化并文化生成的东西可以被确定。显而易见，文化本质上是行为，这很关键，因为我们意识到，可以使用一种在想到改变文化时常常令人感到莫名其妙的方式来影响行为，而文化这种模糊、多面的东西是很难理解的。
帮助组织采用 DevOps 原则意味着我们必须支持组织变革的推动者和领导者，帮助训练大量人力的大脑来理解和实践新的工作方式，从以项目为中心过渡到以产品、自治、价值流或链式思考以及跨职能、渐进式方法的重要转变。
工作做的越多，就越能意识到改变行为是核心，而其关键在于了解驱动行为的因素：我们的大脑。在过去的几年中，我发现神经科学在帮助组织变革上提供了大量指导。由于这是一门科学，是由数据驱动的，所以我们可以信任它。
关于我们都拥有的大脑的一些事实包括：
 重 3 磅（体重的 2％） 使用人体内 20％的血液和氧气 干重的 60％是脂肪（那是相当多的） 100,000 英里的血管 2％的脱水时会影响认知能力 每分钟有一公升的血液流过大脑 人类的大脑与体重的比例是最大的 包含 860 亿个神经元  重要提示：如果您想了解更多有关大脑不同部位的信息，可以使用 Wellcome Trust 的交互式 3D 模型 AMAZE 。
关于神经元的一些事实：
 它们使用电信号和化学信号相互沟通 神经元通过轴突链接产生神经回路 不同的回路执行不同的任务 一个神经元每秒可以传输 1,000 次神经冲动 大脑中有 10,000 种特定类型的神经元 脑信息以每小时 268 英里的速度传播  学习和不学习( unlearning ) 无一例外，我们客户都将努力从瀑布式过渡到敏捷作为业务和技术挑战核心。他们认识到自己正受到数字化的干扰。如果想要生存，能够蓬勃发展那更好，那么他们就需要在吞吐量和稳定性方面都能做得更好。但是，如果组织中的所有人（无论是 200 人还是 20,000 人）都接受过以项目为导向的工作方式的培训，资金也是以项目为导向，系统随着自身的发展而变成紧密耦合的整体，组织结构被孤立，组织中有负责变革咨询和发布管理团队，组织的工作被外包，技术发展滞后，那么组织中的人将很难改变自己的行为。实际上他们必须忘记（ unlearn ）多年甚至几十年已经学习到并坚信的东西。</description>
    </item>
    
    <item>
      <title>Windows Docker Agent 镜像可以常规使用了</title>
      <link>https://jenkins-zh.cn/wechat/articles/2020/05/2020-05-28-docker-windows-agents/</link>
      <pubDate>Thu, 28 May 2020 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.cn/wechat/articles/2020/05/2020-05-28-docker-windows-agents/</guid>
      <description>我们想宣布可以使用官方 Windows agent Docker 镜像，这些镜像允许在 Docker 和 Kubernetes 上使用 Windows 操作系统配置 Jenkins agent。
新镜像 现在，所有 agent 的正式 Docker 镜像都提供 nanoserver-1809 和 windowsservercore-1809 标签，其中包括 Windows 镜像以及当前的 Java 8（类似于 latest 标签）。 我们还提供了明确的 Java 选择，例如 jdk8-windowsservercore-1809 或 jdk11-nanoserver-1809。 版本标记也可用，例如 jenkins/agent:4.3-4-jdk8-nanoserver-1809。
 jenkins/agent 是一个基础的 agent，它捆绑 agent.jar 来进行 agent&amp;lt;= =&amp;gt; master之间的通讯，最有用的是可以作为其他镜像的基础镜像。Windows 镜像从版本 4.3-4 开始可用。
 jenkins/inbound-agent 是一个基于上面 jenkins/agent 镜像的 agent，它提供了用 PowerShell 编写的包装类脚本，以帮助指定 agent.jar 的参数。Windows 镜像从版本 4.3-4 开始可用。
 jenkins/ssh-agent 是一个安装了 OpenSSH 的镜像， 应该与 SSH Build Agents Plugin 一起使用。Windows 镜像从版本 2.</description>
    </item>
    
    <item>
      <title>Jenkins 每周版更新</title>
      <link>https://jenkins-zh.cn/wechat/articles/2020/05/2020-05-25-weekly-release/</link>
      <pubDate>Mon, 25 May 2020 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.cn/wechat/articles/2020/05/2020-05-25-weekly-release/</guid>
      <description>2.237 (2020-05-18)  防止以 Java 11 运行时缺少 javax.annotation 类的导致的遥测告警(由 2.231 引入的缺陷回归)。 (issue 61920) 在类字段解组问题的情况下，防止 Old Data Monitor 插件加载失败。 (issue 62231) 确保在 UserLanguages 遥测初始化程序总是在扩展后运行。 (issue 60118) 确保 job/folder 创建事务正确检查请求的名称中是否包含无效字符。 (issue 61956) 开发者: 将 Apache Ant 从 1.10.7 更新到 1.10.8。 (pull 4725) 开发者: 将 JSTL API 库从 1.2.1 更新到 1.2.7。 (pull 4656, 变更日志更新到 1.2.5, 1.2.3 到 1.2.7 的差异, 1.2.1 到 1.2.3 的差异) 开发者: 在 Java API 中弃用 jenkins.model.Configuration。 (pull 4715)  2.</description>
    </item>
    
    <item>
      <title>使用 Docker、Kubernetes 和 Azure DevOps 实现 DevOps</title>
      <link>https://jenkins-zh.cn/wechat/articles/2020/05/2020-05-20-devops-with-docker-kubernetes-and-azure-devops/</link>
      <pubDate>Wed, 20 May 2020 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.cn/wechat/articles/2020/05/2020-05-20-devops-with-docker-kubernetes-and-azure-devops/</guid>
      <description>这篇文章，我们将会分解关于你想了解的 DevOps 的所有知识，因而你可以着手构建自己的 CI/CD 流水线。
这篇文章，我们将注意力集中于 DevOps 上。
什么是 DevOps？它跟 Agile 有什么不同？有哪些受欢迎的 DevOps 工具？在 DevOps 中，Docker、Kubernetes 和 Azure DevOps 又是充当了什么样的角色。让我们从一个简单的使用场景开始这次的内容。
你将会学习  什么是 DevOps？
 为什么我们需要 DevOps？
 DevOps 和 Agile 有什么区别？
 有哪些重要的 DevOps 工具？
 Docker 怎样能够帮助到 DevOps？
 Kubernetes 怎样能够帮助到 DevOps？
 Azure DevOps 怎样能够帮助到 DevOps？
 什么是持续集成，持续交付？
 什么是基础设施即代码？
 Terraform 和 Ansible 怎样能够帮助 DevOps？
  免费课程 - 10 步速成  10 步学习 Docker</description>
    </item>
    
    <item>
      <title>Jenkins 中文社区携手 KubeSphere，共建 DevOps 技术生态</title>
      <link>https://jenkins-zh.cn/wechat/articles/2020/05/2020-05-19-jenkins-kubesphere-partner/</link>
      <pubDate>Tue, 19 May 2020 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.cn/wechat/articles/2020/05/2020-05-19-jenkins-kubesphere-partner/</guid>
      <description>今天，Jenkins 中文社区 与 KubeSphere 开源社区 联合官宣，两大开源社区从今天开始正式合作，携手共建 DevOps 技术生态！
4 月 14 日，Jenkins 中文社区负责人 Rick 与 KubeSphere 社区多名成员，在技术层面、内容层面、开源社区建设等三个方向进行深入地探讨，最终对两个社区的合作不约而同地达成了一致。
在此次交流会上，KubeSphere 社区 Maintainer @runze xia 先向 Jenkins 中文社区介绍了 KubeSphere DevOps 的技术实现方案，以及为什么采用 Jenkins 作为 KubeSphere DevOps 的引擎。同时，Rick 也向 KubeSphere 社区介绍了 Jenkins-formulas 项目，该项目将来可用来替换 KubeSphere 当前的 Nginx 作为下载插件的 Update Center 方案。
并且，两个社区还将在开源协作与技术内容输出方向共同努力，为社区的开发者和用户带来 DevOps 相关的优质技术文章与实践案例。当然，有一些开发者和社区用户表示，两个社区都开始紧密合作了，两个社区的小伙伴们是不是要约时间面基了？这些要求我们都可以统统安排上！两大社区后续计划联合举办线上的技术直播分享活动、在线研讨会，以及线下 Meetup，欢迎社区小伙伴持续关注我们的动态。
交流会后，Rick 表示自己非常希望加入 KubeSphere 社区，参与 KubeSphere 社区贡献。KubeSphere 社区非常欢迎 Jenkins 中文社区的所有对 KubeSphere 与云原生技术兴趣的同学参与社区开发和文档贡献，KubeSphere 所有的代码、文档、沟通均在 GitHub、Slack 和论坛可见，对于 Jenkins 爱好者我们还在社区设立了 SIG-DevOps 供开发者交流，欢迎大家加入 Slack Channel。</description>
    </item>
    
    <item>
      <title>Jenkins agent Docker 镜像重新命名了，你知道吗？</title>
      <link>https://jenkins-zh.cn/wechat/articles/2020/05/2020-05-18-docker-agent-image-renaming/</link>
      <pubDate>Mon, 18 May 2020 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.cn/wechat/articles/2020/05/2020-05-18-docker-agent-image-renaming/</guid>
      <description>我们正式宣布对 Jenkins agent 官方 Docker 镜像重新命名。 它不会对 Jenkins 用户产生任何直接影响，但是希望他们逐渐升级其实例。 本文提供了新的镜像名称、升级过程以及旧镜像支持策略等相关信息。 我们还将讨论在 Jenkins 中 Docker 包的下一步计划。
新镜像名称  jenkins/agent 是旧的 jenkins/slave 镜像从 4.3-2 开始的新名称 jenkins/inbound-agent 是旧的 jenkins/jnlp-slave 镜像从 4.3-2 开始的新名称 jenkins/ssh-agent 是旧的 jenkins/ssh-slave 镜像从 2.0.0 开始的新名称  请参阅下面的升级指南。
为什么要重新命名？ &amp;ldquo;slave&amp;rdquo; 一词在开源社区中被广泛认为是不合适的。它已于2016年在 Jenkins 2.0中正式弃用，但在某些 Jenkins 组件中仍有遗留用法。 这个 Epic —— JENKINS-42816：Slave 到 Agent 的重命名遗留问题 用于跟踪此类问题的清理。 官方 Docker agent 镜像是一个显而易见的案例，要修改在 DockerHub 上的旧版本镜像并非易事。很高兴这次更新终于解决了镜像命名问题。
另一个值得注意的变化是使用 inbound agent 代替 JNLP agent 术语。 历史上，&amp;rdquo;JNLP&amp;rdquo; 已被用作远程协议的名称。 JNLP 代表 Java Network Launch Protocol，它是 Java Web Start 的一部分。 在 Java 1.</description>
    </item>
    
    <item>
      <title>致广大Jenkins 中文社区关注者的感谢信</title>
      <link>https://jenkins-zh.cn/wechat/articles/2020/05/2020-05-16-a-thank-you-letter-for-jenkins-fans/</link>
      <pubDate>Sat, 16 May 2020 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.cn/wechat/articles/2020/05/2020-05-16-a-thank-you-letter-for-jenkins-fans/</guid>
      <description>故事要从 2020/5/12 社区公众号发布的文章 手把手教会你 Jenkins 备份与恢复 说起。
1-先从故事本身说起 5月12日，公众号发布了一篇有关 Jenkins 备份与恢复的文章，其中分享了以下一段备份 Shell 脚本：
#!/bin/bash # Jenkins Configuraitons Directory cd $JENKINS_HOME # Add general configurations, job configurations, and user content git add -- *.xml jobs/*/*.xml userContent/* ansible/* # only add user configurations if they exist if [ -d users ]; then user_configs=`ls users/*/config.xml` if [ -n &amp;quot;$user_configs&amp;quot; ]; then git add $user_configs fi fi # mark as deleted anything that&#39;s been, well, deleted to_remove=`git status | grep &amp;quot;deleted&amp;quot; | awk &#39;{print $3}&#39;` if [ -n &amp;quot;$toremove&amp;quot; ]; then git rm --ignore-unmatch $toremove fi git commit -m &amp;quot;Automated Jenkins commit&amp;quot; git push -q -u origin master  文章格式核对完成后，便在公众号上发布了。</description>
    </item>
    
    <item>
      <title>征集用户故事- Jenkins is the Way</title>
      <link>https://jenkins-zh.cn/wechat/articles/2020/05/2020-05-15-call-for-user-stories-jenkins-is-the-way/</link>
      <pubDate>Fri, 15 May 2020 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.cn/wechat/articles/2020/05/2020-05-15-call-for-user-stories-jenkins-is-the-way/</guid>
      <description>Jenkins Is The Way 参加开发者大会最让我们喜欢的一件事就是与 Jenkins 用户（无论是新手还是老用户）见面。用户们高兴地谈论自己的项目，分享如何使用 Jenkins 推进项目的技巧。自从冠状病毒大流行以来，我们正更多地依靠新的方式聚集起来，比如通过 Jenkins 在线聚会，GitHub 合作以及 Twitter threads。
这是一个重大的改变。但不变的是，分享用户构建的故事、解决方案，以及在实施 Jenkins 中获得的出色成果的这一需求。我们好奇，为什么没有人收集这些用户故事并与 Jenkins 社区分享。
引入 Jenkins Is The Way 因此，我们迈出了第一步，把社区中每个人用 Jenkins 创造的所有很棒的东西进行记录和存档。这样，Jenkins 的新老用户都可以使用这个存档搜索 Jenkins 解决方案以获取灵感。我们预见将会建成一个庞大的来自世界各地的解决方案的库，解决可以想象到的各个行业中的各种困难与挑战。我们决定将该档案称为“Jenkins Is The Way”，并将托管在 https://JenkinsIsTheWay.io 上。
为了汇总这些故事，我们创建了一个简单的在线问卷，以便 Jenkins 用户可以使用这个领先的开源自动化服务器提交自己的经验故事。拥有如此多的插件来支持构建、部署和自动化大家的项目，我们期待收集大量的故事。
我们已经收到了一些，包括一些说明了为什么 Jenkins Is The Way 的故事：
 可以编写自己的发布流水线
 可以创造持续交付
 可以理解并简化软件生命周期
 可以简化云端自动化
 可以促进日常工作
  添加您的故事，展示使用 Jenkins 的骄傲成果，获得 T 恤衫 通过分享您的 Jenkins 故事，成为可以激发 Jenkins 社区的灵感。只需访问此链接并填写表格即可。我们将会询问您的项目目标，使用 Jenkins 克服的技术挑战以及所创建的解决方案。只需20-30分钟就可以完成填表。
我们将故事整理并将其发布在 https://JenkinsIsTheWay.</description>
    </item>
    
    <item>
      <title>使用 Nexus OSS 为 Docker 镜像提供代理/缓存功能</title>
      <link>https://jenkins-zh.cn/wechat/articles/2020/05/2020-05-13-using-nexus-oss-as-a-proxy-cache-for-docker-images/</link>
      <pubDate>Wed, 13 May 2020 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.cn/wechat/articles/2020/05/2020-05-13-using-nexus-oss-as-a-proxy-cache-for-docker-images/</guid>
      <description>在企业环境中工作，无论是商业组织还是非商业组织，你会发现在互联网上获取信息存在着种种限制。
通常，服务器会运行在一个控制非常严格的环境中并且不能从互联网中获取资源以确保获取的所有资源都是安全的。
当你要使用一些公开的可获取的 Docker 容器时这会变得更麻烦，你会用到“古法”偷偷摸摸的把 Docker 镜像放到你的主机上。
对我而言，事情甚至更加困难。我需要一个通过第三方访问的（受限的）私有仓库。所以现在我该怎么办呢？
幸运的是，目前市面上有好几个可以作为代理或者‘拉入式缓存’的 Docker Registries，这正是我们所需要的。用来作为代理或者缓存的主机需要互联网的权限，而且只有这一台机器需要。其他所有需要获取 Docker 镜像的主机通过这台机器访问互联网，该机器同样很方便的缓存了数据这样只需要检索一次就可以更快的分发到内部局域网的主机上。
诸如 Sonatype Nexus、JFrog Artifactory、甚至 Docker Registry 都提供这些确切的功能，以及一些功能。这里我将会使用 Sonatype Nexus 完成所有的设置，主要的功能在 OSS 版本中可以使用（Artifactory 功能则是 Pro 版本的一部分功能）。
这篇文章将会向你展示怎样配置 Nexus OSS 来实现类似 Docker Hub ，私有仓库或者两者的结合那样的拉入式缓存功能。同样会向你展示怎样配置 Docker 客户端从而在检索镜像的时候能够使用到你的缓存。
需要的软件  Sonatype Nexus OSS 3.15.0（或更高版本）
 Docker 17.09（或更高版本）
  我设置了两个基于 Ubuntu LTS 版本的虚拟机，一个运行了 Sonatype Nexus 3.14.0 的 Docker 容器（这个机器称作 docker-host），另一个只运行 Docker（称作 docker-client）。
请注意一些网络配置或许跟你的配置不一样（例如 IP）但是方法是相同的。同样，请注意那台运行 Nexus OSS 的机器（docker-host）需要有访问互联网的权限。
[更新，2018年10月] 请使用 Nexus 3.</description>
    </item>
    
    <item>
      <title>手把手教会你 Jenkins 备份与恢复</title>
      <link>https://jenkins-zh.cn/wechat/articles/2020/05/2020-05-12-how-to-backup-and-restore-jenkins/</link>
      <pubDate>Tue, 12 May 2020 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.cn/wechat/articles/2020/05/2020-05-12-how-to-backup-and-restore-jenkins/</guid>
      <description>前言 Jenkins 是一个 Java 语言编写的开源工具，结合持续集成与持续交付相关技术的运用可提升软件开发过程的自动化水平。
Jenkins 从最开始安装到权限设置，插件安装，任务维护等是一个费力的工程，因此定期备份数据的重要性不言而喻。
在本文中，我们将手把手演示如何备份并恢复 Jenkins。
备份操作指引 Step1：创建一个新的任务 这里推荐自由风格任务类型，即 Freestyle project
Step2：源码管理选择 None Step3：设置任务执行时间 选择 “Build Periodically”，然后可以根据需要设置备份时间和频率
例如，25 12 * * * 会在每天白天 12:25 运行任务
Step4：Build 模块添加 “Execute Shell” 在 Build 模块选择 Execute Shell，添加以下脚本内容
为方便读者直接使用，脚本内容如下：
 #!/bin/bash # Jenkins Configuraitons Directory cd $JENKINS_HOME # Add general configurations, job configurations, and user content git add -- *.xml jobs/*/*.xml userContent/* ansible/* # only add user configurations if they exist if [ -d users ]; then user_configs=`ls users/*/config.</description>
    </item>
    
    <item>
      <title>如何使用 Jenkins 声明式流水线</title>
      <link>https://jenkins-zh.cn/wechat/articles/2020/05/2020-05-08-how-to-use-the-jenkins-declarative-pipeline/</link>
      <pubDate>Fri, 08 May 2020 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.cn/wechat/articles/2020/05/2020-05-08-how-to-use-the-jenkins-declarative-pipeline/</guid>
      <description>Jenkins 为您提供了两种开发流水线代码的方式：脚本式和声明式。
脚本式流水线（也称为“传统”流水线）基于 Groovy 作为其特定于域的语言。 而声明式流水线提供了简化且更友好的语法，并带有用于定义它们的特定语句，而无需学习 Groovy。
Jenkins 的流水线插件版本2.5引入了对声明式流水线的支持。
在本文中，我们将介绍开发声明式流水线脚本的所有可用指令，这将清楚地说明其功能。
声明式流水线语法 必须使用 pipeline 语句定义有效的声明式流水线，并包括以下必需的部分：
 agent stages stage steps  另外，还有这些可用的指令：
 environment (在流水线或阶段级别定义) input (阶段级别定义) options (在流水线或阶段级别定义) parallel parameters post script tools triggers when  现在，我们将从所需的指令/部分开始，对列出的每个指令/部分进行描述。
agent Jenkins 通过将分布式构建委托给“代理/agent”节点来提供执行分布式构建的能力。 这样做可以使您仅使用 Jenkins 服务器的一个实例来执行多个项目，而工作负载却被分配给了它的代理。 有关如何配置主/代理模式的详细信息超出了本博客的范围。请参阅 Jenkins 分布式构建以获取更多信息。
代理应标记上标签，以便彼此轻松识别。 例如，节点可以通过其平台（Linux，Windows 等），其版本或位置等来标记。 “agent”部分配置流水线可以在哪些节点上运行。 指定 agent any 意味着 Jenkins 将在任何可用节点上运行任务。
其用法的一个示例可以是：
pipeline { agent any ... }  stages 本部分允许在流水线上生成不同的阶段，这些阶段将在运行任务时显示为不同的段。
一个包含阶段语句的示例流水线：
pipeline { agent any stages { .</description>
    </item>
    
    <item>
      <title>Jenkins CLI 命令行 v0.0.28</title>
      <link>https://jenkins-zh.cn/wechat/articles/2020/05/2020-05-07-jcli-v0.0.28/</link>
      <pubDate>Thu, 07 May 2020 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.cn/wechat/articles/2020/05/2020-05-07-jcli-v0.0.28/</guid>
      <description>截止到编辑本文时，GitHub 上统计到的下载量为：5,498次。GitHub 上的 Star 数为157，码云上的 Star 数为89。
Jenkins CLI 增加对了对插件机制的支持，用户可以通过编写插件的方式增强 jcli 的功能。第一个插件可以以 git 仓库的形式，在团队内部分享你的配置文件。
为了保证交付质量，我们增加了 e2e 测试。后续，也会逐渐增加 e2e 的测试用例。
🚀 功能  支持清理无效的配置项 (#383) @LinuxSuRen 在版本打印的命令中增加了日期 (#388) @LinuxSuRen 增加插件机制 (#385) @LinuxSuRen 支持打开外部链接 (#384) @LinuxSuRen 给命令 jcli center start 增加命令行补全 (#380) @LinuxSuRen 增加 man 文档的支持 (#382) @LinuxSuRen 给命令 jcli plugin upload 增加命令行补全 (#378) @LinuxSuRen 支持用指定的浏览器打开 (#377) @LinuxSuRen  🐛 缺陷修复  修复命令 job log 的错误帮助信息 (#375) @LinuxSuRen 命令 jcli doc 不需要读取配置文件 (#376) @yJunS  📝 文档完善  命令文档的完善 (#392) @LinuxSuRen  👻 维护  修复 readme 文件中失效的链接 (#393) @LinuxSuRen 升级 github.</description>
    </item>
    
    <item>
      <title>为你的 GitLab 项目使用 k3s Kubernetes 集群</title>
      <link>https://jenkins-zh.cn/wechat/articles/2020/05/2020-05-06-using-a-k3s-kubernetes-cluster-for-your-gitlab-project/</link>
      <pubDate>Wed, 06 May 2020 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.cn/wechat/articles/2020/05/2020-05-06-using-a-k3s-kubernetes-cluster-for-your-gitlab-project/</guid>
      <description>TL;DR k3s 是一个轻量级的 Kubernetes 发行版（小于 40 MB），它非常容易安装，仅需要 512 MB 的 RAM。对 IoT 设备、边缘计算以及运行 CI 任务来说均是一个完美的选择。这篇文章中，我将创建一个 k3s 集群然后向你们展示怎样将它集成到一个 GitLab 项目中。
关于 k3s k3s 是一款由 Rancher Labs 开发的轻量级的 Kubernetes 发行版。
它作为 Kubernetes 认证的发行版使用最低的系统要求:
 Linux 3.10+ 每个服务器 521 MB ram 每个节点 75 MB ram 200 MB 磁盘空间 x86_64，ARMv7，ARM64  这使得 k3s 非常适合 IoT 相关的事物。
在 GitLab 创建一个项目 在安装 k3s 之前，我们先在 GitLab 上创建一个名为 api 的新项目。
创建完成后，我们进入到 Operation &amp;gt; Kubernetes 菜单。
这里我们有两种选择:
 我们可以在 GKE（Google Kubernetes Engine）上创建一个 Kubernetes 集群。 我们可以导入一个已存在的 Kubernetes 集群的配置（不管在哪里创建的）。  注意: 最新版本的 GitLab，新集群只能在 GKE 中创建。GitLab，有没有允许在其他 Kubernetes 提供商（AKS、EKS、DOKS&amp;hellip;）创建集群的计划呢？:)</description>
    </item>
    
    <item>
      <title>使用 kind 和 Docker 启动本地的 Kubernetes</title>
      <link>https://jenkins-zh.cn/wechat/articles/2020/04/2020-04-29-starting-local-kubernetes-using-kind-and-docker/</link>
      <pubDate>Wed, 29 Apr 2020 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.cn/wechat/articles/2020/04/2020-04-29-starting-local-kubernetes-using-kind-and-docker/</guid>
      <description>介绍 你曾经花过一整天时间尝试入门 Kubernetes 吗？多亏最近新出现的一些工具，你可以不用再为此大费周章了。
这篇文章中，我将向你展示使用 kind 在单个 Docker 容器中启动一个集群的步骤。
什么是 kind？  kind 是一款使用 Docker 容器 “nodes” 运行 Kubernetes 集群的工具。 https://kind.sigs.k8s.io/
 介绍看起来没有描述信息，但是很明显能知道是源于 “Kubernetes IN Docker”。该工具具备了跨平台友好的优势即便你使用的是 Windows 版本的 Docker。当然了，缺点就是它的可追溯性比较差。
安装 kind 因为 kind 是 go 语言实现的，请确保安装了最新版本的 golang。根据开发者文档，推荐使用 go1.11.5 及以上版本。为了安装 kind，请运行这些命令（可能需要运行一段时间）
go get -u sigs.k8s.io/kind kind create cluster  然后确认 “kind” 集群是可用的。
kind get clusters  设置 kubectl 同样的，使用 Homebrew 或者 Chocolatey 安装最新版本的 kubernetes-cli。最新版本的 Docker 包含了 Kubernetes 的功能，但使用的是老版本的 kubectl。
运行该命令检查它的版本号。</description>
    </item>
    
    <item>
      <title>Jenkins 长期支持版更新</title>
      <link>https://jenkins-zh.cn/wechat/articles/2020/04/2020-04-24-jenkins-release/</link>
      <pubDate>Wed, 22 Apr 2020 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.cn/wechat/articles/2020/04/2020-04-24-jenkins-release/</guid>
      <description>2.222.1 (2020-03-25)  Jenkins 启动时将不从磁盘加载全局构建丢弃程序的配置(JENKINS-61688)。 配置已保存，但在重新启动时将不加载。 Jenkins 2.222.1 将始终以 Job Build Discarder 的默认配置启动。 重新启动时将忽略自定义全局构建丢弃配置。 每次 Jenkins 重新启动时，都会配置默认的全局构建丢弃。
 自 2.222 以来的变更：  重要安全修复。 (安全公告) 修复了任务配置表单中之前保存步骤中存在的拖放操作问题 (由 2.217 引入的缺陷回归)。 (issue 61429) Winstone 5.9: 修复最大表单内容大小和表单内容密钥的传递(由 Jetty 9.4.20 和 Jenkins 2.205 引入的缺陷回归)。 (pull 4542, issue 60409, Winstone 5.9 变更日志, Jetty 9.4.27 变更日志) Winstone 5.9: 修复由于 X-Forwarded-Host 和 X-Forwarded-Port 订阅问题而导致的将不正确的反向代理重定向到 Host 的问题(由 Jetty 9.4.20 和 Jenkins 2.205 引入的缺陷回归)。 (pull 4542, issue 60199, Winstone 5.</description>
    </item>
    
    <item>
      <title>Kubernetes 构造可自由扩展的 Jenkins</title>
      <link>https://jenkins-zh.cn/wechat/articles/2020/04/2020-04-22-scale-your-jenkins-agents-using-kubernetes/</link>
      <pubDate>Wed, 22 Apr 2020 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.cn/wechat/articles/2020/04/2020-04-22-scale-your-jenkins-agents-using-kubernetes/</guid>
      <description>如果你是一名在职软件工程师，那你大概率已经使用过 Jenkins，至少听说过。
Jenkins 是目前最受欢迎的开源持续集成与持续交付（CI/CD）工具。为何它会受到如此多用户的追捧？诸如 CloudBees 这样的组织及相关优秀社区提供了坚实的帮助与支持，此外，一大批开发人员贡献了数以千计的插件，加上 Jenkins 良好的易用性，都让 Jenkins 从开源工具中脱颖而出。
基于以上特点，Jenkins 可以轻松实现以下事情：
 结合主流版本管理工具，如 Git，Subversion 和 Mercurial； 集成代码质量管理工具，如 Sonarqube，Fortify； 使用 Maven 或 Gradle 构建 ； 使用 Junit 进行单元测试；  虽然 Jenkins 如此强大，但其入门使用却非常简单，你只需要准备一个 Web 应用服务器如 Tomcat 和一份可执行的安装文件 jenkins.war 即可。Jenkins 的运行方式有很多种，这里将介绍几种非常典型的方式。
独立的 Jenkins 服务器 在这种模式下，只有一个 Jenkins 服务器负责所有的构建任务并使用 TCP 连接部署到远程服务器上。这也是最简单的一种方式，你完全不需要担心其他可变因素。
主从策略 采用单机模式运行 Jenkins 有一些弊端。
尽管单机模式你无需考虑多服务器和节点，但当大量的构建任务在同一时间运行时，服务器可能会负荷过重。你可能会考虑增加节点可并发执行的构建任务数量，但是很快就会遇到性能瓶颈。
为了解决这个问题，你可以将部分任务分发到其他的机器上去，即 Jenkins 从节点。Jenkins 从节点会运行一段程序与主节点进行通信，判断是够有可执行的构建任务。一旦 Jenkins 主节点调度安排好构建任务，就将其分发至相应的从节点。那我们的问题解决了吗？接着往下看。
可扩展的 Jenkins 我们进一步来探索 Jenkins 的运行方式。当你的团队中还未建立 CI 时，你可能无需多台静态服务器来执行 Jenkins 任务。
当你无需 7*24 运行时，你的服务器可能会空闲，这时就产生资源浪费了。</description>
    </item>
    
    <item>
      <title>Jenkins 每周版更新</title>
      <link>https://jenkins-zh.cn/wechat/articles/2020/04/2020-04-20-weekly-release/</link>
      <pubDate>Mon, 20 Apr 2020 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.cn/wechat/articles/2020/04/2020-04-20-weekly-release/</guid>
      <description>2.230 (2020-04-06)  改进告警横幅的样式，使其更具视觉吸引力并更好地匹配现有的用户界面组件。 现在，警报在显示时完全覆盖了导航栏，而不是仅覆盖导航栏的一部分。 (issue 61478) 检查任何一个权限时，权限错误中将不再显示已禁用的权限。 (issue 61467) 显示与标签相关而非单个节点的阻塞原因时，允许使用超链接。 (pull 4616) 添加选项以支持配置归档制品时的符号链接。 (issue 5597) 除了通常的全局/Administer权限之外，具有全局/管理权限的用户现在也可以访问准备关机管理链接。 (issue 61453) 更新页脚样式。 (issue 61496) 允许 configuration-as-code plugin 禁用管理员监控。 (issue 56937) 更新 Groovy Init hooks，使其在任务配置修改后运行。 (issue 61694) 修复指纹清除线程中的类强制转换异常。 (issue 61479)  2.229 (2020-03-29)  重新启动时使用保存的全局构建丢弃配置。 Jenkins 2.221 到 2.228 在重新启动时会忽略保存的全局构建丢弃配置。 (issue 61688) 修复设置密码后代理表单验证的问题(由 2.205 引入的缺陷回归)。 (issue 61692) 更新 .NET 版本检查，使其更适合自带的 .NET 版本。 (pull 4554) 具有全局/管理或全局/系统读取（以及通常的全局/Administer）权限的用户可以访问关于 Jenkins 的管理链接。 (issue 61455) 稳定性: 将 null 转换为 Secret 时不再抛出 NullPointerException。 (pull 4608) 升级到 Remoting 4.</description>
    </item>
    
    <item>
      <title>使用 Vault 与 Kubernetes 为密码提供强有力的保障</title>
      <link>https://jenkins-zh.cn/wechat/articles/2020/04/2019-04-15-effective-secret-with-vault-and-kubernetes/</link>
      <pubDate>Wed, 15 Apr 2020 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.cn/wechat/articles/2020/04/2019-04-15-effective-secret-with-vault-and-kubernetes/</guid>
      <description>介绍 Kubernetes 已经成为了容器编排方案的工业标准，而来自 HashiCorp 的 Vault 则是密码管理的工业标准。那问题来了: 怎样将这两项技术结合使用从而可以让你在 Kubernetes 的应用程序中使用来自于 Vault 中心实例的密码呢？
一种解决方法是使用 AppRole 认证。Boostport 为 AppRoles 在 Kubernetes 上的使用提供了完美的集成。另一个可行的方法是使用 Kubernetes 认证。这种认证机制为 Vault 和 Kubernetes 集群创建一个可信的联系因而你可以使用一个服务账号到 Vault 进行认证。后期你可以使用 Kubernetes 的 Vault 节点获取和更新认证令牌。
这篇实践的文章中，我会向你展示如何使用一些 Go 助手工具实现诸如认证更新令牌这些相同的工作，并且还会进一步实现-从 Vault 到 Kubernetes 同步预定义的密码子集。
等级: 高级
准备工作 简单起见我有一些选项:
 用多种不同的方法启动一个 Kubernetes 集群。通常来说，minikube 用来测试或者开发。我会使用 kubeadm 因为它非常简单的就可以启动一个*真正的*集群。
 在 Kubernetes 中，会使用 default 命名空间。
 Vault 会在*开发*模式下运行。不要像在生产环境下那样使用它！ 确保在环境变量中设置了 VAULT_ADDR。
 代码示例中会使用 Ubuntu。这些已经在 GCE 上配置为 2 vCPU 和 7.</description>
    </item>
    
    <item>
      <title>Jenkins CLI 命令行 v0.0.27</title>
      <link>https://jenkins-zh.cn/wechat/articles/2020/04/2020-04-10-jcli-v0.0.27/</link>
      <pubDate>Fri, 10 Apr 2020 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.cn/wechat/articles/2020/04/2020-04-10-jcli-v0.0.27/</guid>
      <description>在本次更新中，利用 GitHub Actions 和 GoReleaser 实现了自动化版本发布。为了满足更多用户的使用场景，给出了包括：.deb、.rpm 以及 arm 架构等20种不同的包格式。
截止到编辑本文时，GitHub 上统计到的下载量为：4,985次。GitHub 上的 Star 数为146，码云上的 Star 数为87。
另外，为了让更多的 Jenkins 用户尽快地熟悉 Jenkins CLI 的功能，并上手改进日常的工作。大家可以访问下面的交互式教程：
https://www.katacoda.com/jenkins-zh
🚀 功能  支持构建插件工程 (#355) @LinuxSuRen 增加用于清空 Jenkinsfile 中的空白字符的参数 (#363) @LinuxSuRen 支持传递给自定义 Jenkins 配方的参数 (#364) @LinuxSuRen 增加对构建自定义 Jenkins 的支持 (#340) @LinuxSuRen 支持启用、禁用 Jenkins 任务 (#352) @LinuxSuRen 增加可以直接重启 Jenkins 的参数 (#345) @LinuxSuRen 支持编辑空的流水线时，提供一份样本 (#361) @LinuxSuRen 增加 goreleaser 配置文件 (#347) @LinuxSuRen  📝 文档完善  为 jcli 增加一个交互式教程 (#362) @LinuxSuRen 增加如何通过 yum 安装 jcli 的说明 (#348) @LinuxSuRen  👻 维护  不再推送开发中的 Docker 镜像 (#371) @LinuxSuRen 利用 GitHub Actions 来发布版本 (#370) @LinuxSuRen 增加对 arm 架构的支持 (#351) @LinuxSuRen github.</description>
    </item>
    
    <item>
      <title>自定义 Jenkins 发行版就是这么简单</title>
      <link>https://jenkins-zh.cn/wechat/articles/2020/04/2020-04-09-custom-jenkins-war/</link>
      <pubDate>Thu, 09 Apr 2020 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.cn/wechat/articles/2020/04/2020-04-09-custom-jenkins-war/</guid>
      <description>Jenkins 是一个由开源社区驱动的项目，拥有非常丰富的插件生态，任何人都可以根据社区给出的指南为之作出贡献，甚至是将自己开发的插件托管到 Jenkins 社区。从插件市场上能看到，到目前为止有超过1500个插件可供 Jenkins 的用户挑选。当我们走进 Jenkins 这个巨型超市时，有多少人曾经有过这样的感觉——看着琳瑯满目的商品，却完全无从下手？自由风格，流水线即代码，申明式流水线，多分支流水线，配置即代码，又有多少人被应接不暇的社区新概念搞得没了头绪？
让我们暂且不去关心其他语言的用户体验如何，单看 Jenkins 简体中文插件3万左右的下载量，就足以证明 Jenkins 中文本地化工作对很多用户是有意义的。在之前的一篇博文中，我们从改善用户下载、更新插件的角度出发，发布了 Jenkins 插件中心国内源。在此，需再次对清华大学开源镜像站等组织对开源项目的支持，让更多的人得以站在巨人的肩膀上前行。在过去的四个月的时间里，插件国内源的用户在逐步上升；用户检查更新插件的峰值为931次/天。
从上面的两个数据中，不难看出，还是有相当一部分用户还没有享受到插件国内源的益处。这可能有多个原因导致：文档不清晰、配置步骤繁杂、服务器不稳定等等。对于文档、配置等问题而言，一个杀手级的一个解决方案就是——不需要文档和配置。本文要介绍给大家的就是这么一种开箱即用的方案，就像乐高积木一样，而用户只需要提交一个订单（YAML 文件）就能拿到他所需要的 Jenkins 发行版。是的，作为用户，不仅不再需要配置国内源，甚至都不需要下载和配置插件。
Jenkins 自定义发行版项目，默认提供了几个常用的配方，并支持用户以 YAML 的格式提交配方。这里的配方，包括了发行版中 Jenkins Core 的版本、插件列表、插件配置、初始化脚本等等。一旦提交的配方 Pull Request 合并到 master 分支后，就可以自动地构建出来对应的 docker 镜像以及 jenkins.war 文件。如果 Jenkins 有了新版本的话，是否还需要重新提交配方请求呢？我们已经考虑到了这一点，一旦有新版本发布的话，会自动构建出来对应的发行版（也许会有一天的延迟）。大家如果喜欢这个方案的话，可以关注托管在码云或者 GitHub 上的项目。目前，Docker 镜像的下载量已经有3000+，心动不如行动，赶快试试吧！
现有的配方包括：
   配方 镜像     配置即代码 + 简体中文 jenkinszh/jenkins-zh:2.204.5   配置即代码 + 流水线 jenkinszh/jenkins-pipeline:2.204.5   配置即代码 + 流水线 + K8s jenkinszh/jenkins-k8s:2.204.5   多分支流水线 + BlueOcean jenkinszh/blueocean-zh:2.</description>
    </item>
    
    <item>
      <title>以代码的形式构建 Jenkins</title>
      <link>https://jenkins-zh.cn/wechat/articles/2020/04/2020-04-08-build-jenkins-as-a-code/</link>
      <pubDate>Wed, 08 Apr 2020 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.cn/wechat/articles/2020/04/2020-04-08-build-jenkins-as-a-code/</guid>
      <description>在我们公司，我们尝试使用‘一切事物即代码’的模式，该模式涉及到可复制的基础架构，监控，任务等方面。但是，在这篇文章当中，我将向你展示怎样将这种模式运用到 Jenkins 上。是的，我的意思是对于 Jenkins 完全可复制的配置，以及基础架构、插件、凭据、任务以及代码中的其他东西。另外，这篇文章你将解惑下面的疑问:
 我们的 Jenkins 已经变得更加稳定了吗？
 我们可以频繁地改变 Jenkins 和任务配置吗？
 升级 Jenkins 及其插件对我们来说是否不再是一种痛苦了呢？
 我们是否已经管理了 Jenkins 上所有的变更？
 故障发生后，是否我们可以快速的恢复 Jenkins？
  我的名字叫 Amet Umerov 是一名 Preply.com 的DevOps 工程师。让我们开始吧！
前期介绍 当我们谈论 DevOps 工具，脑海中首先出现的是一个 CI/CD 系统。我们在 Preply 使用 Jenkins 因为我们每天有数以百计的任务，我们使用的许多特性在其他系统里面是没法提供的，即使提供了这些功能，也会是一些简化的功能。
我们想要让 Jenkins 以及基础架构、配置、任务和插件完全代码化。并且，我们之前有过在 Kubernetes 运行的经验，但是因为 Jenkins 架构以及我们自身的目的发现它并不适合我们。
这是我们想要实现的目标
为 Jenkins 构建底层架构 我们用的是 AWS 使用 Terraform 管理我们所有的基础架构还有其他一些来自于 HashiStack 的工具比如 Packer 或者 Vault。
就像我之前提到的，我们尝试使用 Kubernetes 来托管 Jenkins，但我们在扩展 PVC，资源还有一些没有经过深思熟虑的架构时遇到了问题。</description>
    </item>
    
    <item>
      <title>动手实践：美化 Jenkins 报告插件的用户界面</title>
      <link>https://jenkins-zh.cn/wechat/articles/2020/04/2020-04-01-hands-on-beautify-the-user-interface-of-jenkins-reporter-plugins/</link>
      <pubDate>Wed, 01 Apr 2020 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.cn/wechat/articles/2020/04/2020-04-01-hands-on-beautify-the-user-interface-of-jenkins-reporter-plugins/</guid>
      <description>对于 Jenkins 而言，可以使用大量插件来可视化各种构建步骤的结果。有一些插件可用于呈现测试结果、代码覆盖率、静态分析等。所有这些插件通常都会获取给定构建步骤的构建结果，并在用户界面中显示它们。为了呈现这些细节，大多数插件使用静态 HTML 页面，因为这种类型的用户界面是 Jenkins 自 2007 年成立以来的标准可视化。
为了改善这些插件的外观和用户体验，有必要向前发展并合并一些现代 Java Script 库和组件。由于 Blue Ocean 的开发已经停止（请参阅 Jenkins mailing list post），因此插件作者需要自己决定，哪些 UI 技术可帮助完成该任务。但是，现代 UI 组件的种类繁多，以至于只挑选一小部分被证明是有用的并且与 Jenkins 基础 Web 技术兼容的组件是有意义的。而且，合并这样一个新组件的初始设置相当大，因此如果该工作仅需要执行一次，将会有很大的帮助。
本指南介绍了一些 UI 组件，以后所有插件作者都可以使用这些 UI 组件，从而为 Jenkins 中的报告提供丰富的用户界面。为了简化这些库在 Jenkins 作为基于 Java 的 Web 应用程序的上下文中的使用，这些 Java Script 库和组件已打包为普通的 Jenkins 插件。
在以下各小节中，将逐步介绍这些新组件。为了了解如何使用这些组件的插件，我将演示新功能，同时使用新的用户界面增强现有的 Forensics Plugin。由于 Warnings Next Generation 插件也使用这些新组件，因此您可以在 warnings 插件的文档中或在我们的公共 ci.jenkins.io 实例中看到其他示例，这些示例已经在 warnings 插件的详细信息视图中使用了这些组件。
新的用户界面插件 新的 Jenkins 插件提供了以下 UI 组件:
 jquery3-api-plugin:为 Jenkins 插件提供 jQuery 3。如其首页所述，jQuery 是一个快速、小型且功能丰富的 JavaScript 库。借助易于使用的 API（可在多种浏览器中使用），使 HTML 文档的遍历和操作、事件处理、动画和 Ajax 等事情变得更加简单。兼具多功能性和可扩展性，jQuery 改变了数百万人编写 JavaScript 的方式。 bootstrap4-api-plugin:为 Jenkins 插件提供 Bootstrap 4。Bootstrap 自称是世界上最流行的前端组件库，用于在 Web 上构建响应式，移动优先的项目。它是一个用于使用 HTML、CSS 和 JS 开发的开源工具包。开发人员可以使用他们的 Sass 变量和 mixins、响应式栅格系统、大量的预构建组件以及基于 jQuery 构建的强大插件，快速构建其思想原型或整个应用程序。 data-tables-api-plugin:提供 Jenkins 插件的数据表格。DataTables 是 jQuery Javascript 库的插件。这是一个高度灵活的工具，建立在逐步增强的基础上，可将所有这些高级功能添加到任何 HTML 表中:  上一页，下一页和页面导航 通过文本搜索过滤结果 一次按多列对数据排序 DOM、Javascript、Ajax、服务器端处理 简单主题化 手机端兼容友好  echarts-api-plugin:为 Jenkins 插件提供 ECharts。ECharts 是一种开放源代码的 JavaScript 可视化工具，用于创建直观、交互式和高度可定制的图表。它可以在 PC 和移动设备上流畅运行，并且与大多数现代 Web 浏览器兼容。 font-awesome-api-plugin:为 Jenkins 插件提供 Font Awesome。Font Awesome 具有矢量图标和社交徽标，号称是网络上最受欢迎的图标集和工具包。目前，它包含 1,500 多个免费图标。 popper-api-plugin:为 Jenkins 插件提供 Popper.</description>
    </item>
    
    <item>
      <title>Jenkins 教程：使用 Ngrok 配置（SCM）Github 触发器和 Git 轮询</title>
      <link>https://jenkins-zh.cn/wechat/articles/2020/03/2020-03-27-jenkins-tutorial-configure-scm-github-triggers-and-git-polling-using-ngrok/</link>
      <pubDate>Fri, 27 Mar 2020 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.cn/wechat/articles/2020/03/2020-03-27-jenkins-tutorial-configure-scm-github-triggers-and-git-polling-using-ngrok/</guid>
      <description>总览 Jenkins 是领先的开源自动化服务。它提供了 1500+ 个插件来支持构建，部署和自动化任何项目。在本文中，我们将研究如何在作业上配置 Github 触发器，以及如何使用 Webhook 与 Github 相通，该 Webhook 指示何时轮询作业以构建对项目进行的更改。
前提条件 您需要在 Github 中有一个项目。
您将需要启动并运行 Jenkins 服务。
入门 安装和运行 Ngrok Ngrok 是一个反向代理，它接受公共地址上的流量，并将该流量中继到计算机上运行的 ngrok 进程，然后再中继到您指定的本地地址。
因此，通过您选择的任何一种方法，前往 Ngrok 并注册一个帐户。然后，您应该会看到下面的截图，其中显示了如何解压缩和运行它。
运行./ngrok http 8080，它将指向我们的 Jenkins 服务。
运行该命令后，您将收到代理主机名，如下所示：
转发 http://xxxxx.ngrok.io -&amp;gt; http://localhost:8080
转发 https://xxxxx.ngrok.io -&amp;gt; http://localhost:8080
设置 Github Webhook 因此，跳转到 Github 项目并单击设置，在左侧面板上应该会看到 webhooks，现在单击该按钮。
添加我们的 webhook：
设置 Jenkins 项目或流水线作业 选择 Github 挂钩触发器进行 GitScm 轮询：
然后，使用您的 GitHub 帐户设置 Jenkins Pipeline：
开始准备测试我们的工作！使用您指定的 develop，master 等分支将提交提交到您的项目。</description>
    </item>
    
    <item>
      <title>致 UCloud 的一封感谢信</title>
      <link>https://jenkins-zh.cn/wechat/articles/2020/03/2020-03-26-thanks-ucloud/</link>
      <pubDate>Thu, 26 Mar 2020 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.cn/wechat/articles/2020/03/2020-03-26-thanks-ucloud/</guid>
      <description>故事要从社区服务器的几起故障说起。某天，在微信群、公众号后台等几个渠道中，有用户反馈说 Jenkins 中文社区提供的插件更新中心国内镜像源无法访问。为了避免影响到更多的人，我们赶紧在社区的管理群中同步了该消息。在没有专业运维人员帮助的情况下，我们也必须量快地排除服务器故障。从服务器资源使用的图表上，我们看到 CPU、网络都已经跑满了，此时，已经是无法远程登录到服务器上做任何操作。对于社区的现状而言，确实有一些窘迫，只有1M带宽、1核CPU、1G内存。先不去考虑并发量的问题，单个用户的请求都无法得到较好的体验。这对于完全是由小伙伴自发、志愿组成的开源、公益社区，唯一的出路就是寻找外部的资源和支持，尤其是对开源愿意扶持、有社会责任感的企业。
此时，我想要分享给社区小伙伴的好消息是：在去年11月份收到了来自霍格沃兹测试学院给予的无私赞助外，今年3月份再次收到了长期专注于移动互联网领域的基础云计算服务提供商 UCloud 的大力支持。UCloud 将会为 Jenkins 中文社区提供1年免费的服务器的使用权，社区的基础设施也会因此得到增强。我们相信，Jenkins 中文社区将会在 UCloud 的帮助下，可以继续带来更多的社会价值，服务更多的个人以及团体用户。
关于 UCloud，如果大家稍微留意下的话，就会发现很多社区网站和个人博客的底部有 UCloud 的 Logo。这都是对 UCloud 提供的云服务的稳定性的极大肯定，社区希望能以这种方式向大家传递一个这样的消息——我们的网站运行在 UCloud 上很放心。首先，是从客服方面，总是可以及时地得到响应；然后，在创建云主机时，在国内外的很多主要城市都有节点可供选择，引导界面清晰、简洁；对于社区而言非常重要的一个部分，权限管理也完全可以满足我们多个不同角色运维人员的权限分配。其他的云产品，我们虽然目前还没有需求，但随着社区的发展壮大，相信未来也一定可以祝我们一臂之力！加油 UCloud！
自打发布了Jenkins 插件中心国内镜像源后，我们收到了很多的来自社区论坛以及 GitHub Issues 上的反馈。根据反馈社区也做了很多的改进措施，包括：Jenkins CLI 对切换镜像源的支持、无需任何配置即可使用 Jenkins 中国镜像源的开箱即用的方案。当然，除了软件方案上的改进措施外，我们今天想要特别提到的就是社区基础设施的增强——我们会把 Jenkins 国内镜像源相关的服务全部迁移到 UCloud 的云服务器上。如果您对国内源的访问情况感兴趣，可以查看这里的统计图表。
公开透明，对于开源社区是非常重要的，我们会把所有收到的赞助以及资源的使用情况，全部记录到 Jenkins 中文社区官网。我们欢迎每一位关注社区的人来监督，同时也希望有更多的个人、企业给予社区赞助，我们将尽自己最大的努力为开源社区带来更大的价值。</description>
    </item>
    
    <item>
      <title>7 款你或许不知道的 DevOps 工具链编排解决方案</title>
      <link>https://jenkins-zh.cn/wechat/articles/2020/03/2020-03-24-7-devops-toolchains-orchestration-solutions-you-may-not-know/</link>
      <pubDate>Tue, 24 Mar 2020 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.cn/wechat/articles/2020/03/2020-03-24-7-devops-toolchains-orchestration-solutions-you-may-not-know/</guid>
      <description>这七款 DevOps 工具将会帮助你用来考虑将哪个工具包含到你的工具链中。
团队之间的透明化沟通在应用程序开发过程中成为了一项巨大的挑战。一个组织中的大部分团队的独立性已经有相当长时间了。这也就意味着开发团队、业务分析团队、QA 以及业务运营团队之间的工作距离越来越疏远。
在交付结果的时候，公司也因此遭受了不少损失。太长的软件交付流程导致了大多数操作的延迟。业务领域的任何人都能理解这意味着什么。仅仅是没有足够的产品创新。似乎这还不够，对市场需求的反应还不是那么令人满意。
根据一位来自于提供安全编排解决方案的著名公司 Siemplify 的 CEO，Amos Stern 的说法，“使用带有安全编排解决方案的 DevOps 方法可以让你的公司在提高生产力这件事上变得一切皆有可能。”
这些实践尝试将团队凝聚在一起从而避免各自为战。它们以在应用交付时确保高效为目标。这种方法提升了公司软件交付的功能性并且确保产生更少的风险。它们同样负责消除在 IT 响应中出现的各种障碍。
但是这些实践没有工具是不能正常运转的。在不同 DevOps 环境下使用不同的控制工具的解决方案称为“DevOps 工具链编排解决方案”。主要有以下工具组成。
或许你同样感兴趣: 2019 年你应该知道的 5 款 DveOps 工具
1. 源码管理（SCM） 你为公司构建的所有公司想要表达的东西都是通过代码实现的。但是代码同样有窍门的，你必须确保它能尽可能容易地被理解。你必须对它们进行控制和操作分支。如果做不到这些，就有可能面临乱糟糟的情况。
为此，它们拥有的 SCM 包括 GitHub 和 Gitlab。
2. 持续集成（CI） 现在软件开发已经完全需要依赖 CI。这项可操作的技术可以让开发任何东西变得容易。安装一个可设置的 CI 是很重要的，这可以:
 减少与集成相关的任何问题
 提升代码质量
 提升沟通交流
 提高发布速度
 减少 bug
  3. 构建工具 在继续构建组织时，你需要确定哪些工具是重要的哪些又不是你需要的。这不仅仅是重要的，如果你想削减开销这也是必须的。记住，一个公司不注意开支花销的话是很容易出现财务问题的。为此，你需要最好的构建工具来发展你的公司。
4. 测试 任何业务都存在风险。除了危险的风险之外，还有质量保证的整个方面。如果你想实现你的业务目标的话，拥有准确实时这两方面的考量就变得至关重要。
例如 JUnit 和 Mocha 以及其他的一些测试工具可以在追踪它们怎样运行这方面成为可能。
5. 制品管理 一旦你的项目能顺利推进，你需要存储你在流水线中生成的产物。它们需要跟源码存放在 SCM 一样的方式进行保存。存储制品是在需要获取过去产品版本并进行优化时最可靠的方法。</description>
    </item>
    
    <item>
      <title>Jenkins 长期支持版更新</title>
      <link>https://jenkins-zh.cn/wechat/articles/2020/03/2020-03-17-jenkins-release/</link>
      <pubDate>Tue, 17 Mar 2020 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.cn/wechat/articles/2020/03/2020-03-17-jenkins-release/</guid>
      <description>2.176.2 (2019-07-17)  用于等待外部进程完成的线程池可能会使类加载器泄露。 当分离的插件（其插件功能曾经是 Jenkins 本身的一部分）作为已经存在的其他插件的隐含依赖时，确保 Jenkins 在启动时对其进行安装。这简化了不使用更新中心的专用安装方案的兼容性，例如当从带有某些插件的预包装 Docker 镜像运行 Jenkins 时。 更新 WinP 从 1.27 到 1.28 ，以修复 Windows 正常进程关闭逻辑中缺少 DLL 和控制台窗口闪退的问题 用更简单的消息替换一些与代理通道有关的异常堆栈跟踪。  2.176.3 (2019-08-28)  当其他插件对其仅具有可选依赖时，插件管理器 UI 不再阻止禁用插件。 解决使用 &amp;ldquo;记住我&amp;rdquo; 时的性能问题。 (由 2.160 引入的缺陷回归) 测试代理配置时不要抛出异常。 (由 2.168 引入的缺陷回归) 防止 Jenkins 重启和用户会话无效时的偶发 IllegalStateException 异常。  2.176.4 (2019-09-25)  2.176.4 和 2.190.1 包含相同的安全修复程序。我们将提供 2.176.x LTS 系列的附加版本，以允许管理员应用安全更新，而无需进行重大升级。  2.190.1  修复 RSS / Atom 提要中缺少的绝对 URL 。 (由 2.</description>
    </item>
    
    <item>
      <title>流水线编撰 SIG 公告</title>
      <link>https://jenkins-zh.cn/wechat/articles/2020/03/2020-03-16-pipeline-authoring-sig-update/</link>
      <pubDate>Mon, 16 Mar 2020 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.cn/wechat/articles/2020/03/2020-03-16-pipeline-authoring-sig-update/</guid>
      <description>什么是流水线撰写特别兴趣小组 这个特别的兴趣小组旨在改善和策划 Jenkins Pipelines 的创作经验。这包括 Jenkinsfile、共享库的语法、代码共享、重用、流水线、共享库的测试、IDE 集成、其他开发工具、文档、最佳实践、示例。
流水线撰写特殊兴趣小组的重点领域是什么  语法-如何编写 Jenkinsfiles 和共享库。 代码共享和重用-共享库和未来的改进。 测试-Jenkinsfile 和共享库的单元和功能测试。 IDE 集成，编辑器和其他开发工具-IDE 插件，可视化编辑器等。 文档-参考文档，教程等。 最佳做法-在 Jenkins Pipeline 中定义，维护和宣传最佳做法。 示例-现实世界中的 Jenkinsfile 和共享库演示了如何利用流水线的各种功能，以及基本或入门版的 Jenkinsfile 用于常见模式，新用户可以将其用作起点。  我们已经做了哪些 新年伊始，成员们聚在一起讨论 2020 年的路线图。在最初的讨论中，我们认为最好检查一下先前会议的目标并确定最佳的前进道路。
双方共同决定要更好地制定路线图。我们需要更好地了解我们打算帮助谁。我们认为创建角色非常有益。角色是虚构的角色，我们根据研究结果创建了这些角色，以代表可能使用 Jenkins 流水线的不同用户类型。创建角色可以帮助我们走出自我。它可以帮助我们认识到不同的人有不同的需求和期望，也可以帮助我们确定要为其制定路线图的用户。角色使当前的任务变得不那么复杂，可以指导我们的构思过程，并且可以帮助我们实现为目标用户组创造良好用户体验的目标。许多工作可以在这里找到：https://docs.google.com/document/d/1CdyzJwt50Wk3uUNsLMl2d4w2MGYss-phqet0s-KjbEs/edit。这个想法是将角色映射到成熟度模型，然后再将成熟度模型映射到实际文档。该成熟度模型可以在这里找到：https://drive.google.com/file/d/1ByzWlPU0j1qM_gqspJppkNKkR5ZVLWlB/view。
我如何参与其中 我们一直定期开会以定义角色，以帮助我们更好地创建 SIG 路线图。我们每周开会两次，一次在星期四（EMEA）时区，另一次在星期五（美国）时区。会议记录可以在这里找到：https://docs.google.com/document/d/1EhWoBplGl4M8bHz0uuP-iOynPGuONjcz4enQm8sDyUE/edit#,如果您想参与的话，可以查看日历在这里：https://jenkins.io/event-calendar/。会议的先前记录位于：https://www.youtube.com/watch?v=pz_kPpb9C1w&amp;amp;list=PLN7ajX_VdyaOKKLBXek6iG8wTS24Ac7Y3。
下一步 我们有很多工作要做，期待您的帮助。如果您想加入我们，请查看会议链接。如果您想查看角色并提供反馈，请查看链接。完成角色配置工作后，我们将开始确定可用的文档，并在 Doc SIG 的帮助下确保我们有足够的文档。然后，我们最终将开始着手构建工具，以帮助社区更好地利用 Jenkins 中的流水线。
联系我们 如果您想与 Pipeline-Authoring SIG 取得联系，可以通过加入 Pipeline-Authoring SIG gitter channel 或通过 Pipeline-Authoring SIG mailing list 来进行联系。</description>
    </item>
    
    <item>
      <title>使用 Kubernetes 和 Jenkins 创建一个 CI/CD 流水线</title>
      <link>https://jenkins-zh.cn/wechat/articles/2020/03/2020-03-10-create-a-ci-cd-pipeline-with-kubernetes-and-jenkins/</link>
      <pubDate>Tue, 10 Mar 2020 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.cn/wechat/articles/2020/03/2020-03-10-create-a-ci-cd-pipeline-with-kubernetes-and-jenkins/</guid>
      <description>CI/CD 尝试解决什么问题？ CI/CD 同 DevOps、Agile、Scrum、Kanban、自动化以及其他术语一样，是一个一起被经常提及的专用术语。有时候，它被当做工作流的一部分，但是并没有搞清楚这是什么或者为什么它会被采用。对于年轻的 DevOps 工程师来说，使用 CI/CD 理所当然已经成为了常态，可能他们并没有看到“传统”的软件发布流程而因此不欣赏 CI/CD。
CI/CD 表示持续集成/持续交付和/或部署。如果一个团队不接入 CI/CD 流程就必须要在产生一个新的软件产品时经历如下的阶段：
 产品经理（代表了客户利益）提供了产品需要有的功能以及产品需要遵从的行为。文档必须要越详实越好。
 具有业务分析能力的开发人员开始对应用进行编码，执行单元测试，然后将结果提交到版本控制系统（例如 git）。
 一旦开发阶段完成，项目移交到 QA。对产品进行多轮测试，比如用户验收测试，集成测试，性能测试。在此期间，直到 QA 阶段完成之前都不会有任何代码上的改动。如果有任何 bug 被发现，需要回退给开发人员做修改，然后再将产品移交给 QA。
 一旦 QA 完成，操作团队会将代码部署到生产环境中。
  上述工作流存在一些弊端：
 首先，从产品经理提出需求到产品具备开发条件中间会消耗太多时间。
 对开发人员来说，从写了一个月甚至更长时间的代码中去定位问题真的很困难。请记住，bug 只能是在开发阶段完成 QA 阶段开始后被发现。
 当有一个*紧急的*代码修复比如像一个严重的 bug 需要热修复时，QA 阶段可能会因为需要尽快部署而被缩短。
 不同的团队之间很少会有协作，当 bug 出现的时候，人们就开始互相甩锅互相指责。每个人从一开始只是关心项目中自己的那部分工作而忽视了共同的目标。
  CI/CD 通过引入自动化来解决上述的问题。代码中的每次改动一旦推送至版本控制系统，进行测试，然后在部署到用户使用的生产环境之前部署至预生产/UAT 环境进行进一步的测试。自动化确保了整体流程的快速，可信赖，可重复，以及不容易出错。
所以，什么是 CI/CD 呢？ 关于这个主题已经有著作撰写完毕。如何，为什么，以及什么时候在你的架构中使用。然而，我们总是倾向于轻理论重实践。话虽如此，下文简单介绍了一下一旦修改的代码被提交后会执行哪些自动化步骤：
 持续集成（CI）：第一步不包括 QA。换句话说，它不关注代码是否提供了用户需要的功能。相反，它确保了代码的质量。通过单元测试，集成测试，开发人员能很快的就会发现代码质量中的缺陷。我们可以增加代码覆盖率的检查以及静态分析让代码质量保证做的更加完善。
 用户验收测试：这是 CD 流程的第一部分。这个阶段，会对代码执行自动化测试从而确保代码符合用户的期望。比如说，一个 web 应用没有任何报错产生能正常运行，但是客户想让访问者在导航到主页之前先进入到登录页面。但是当前的代码直接让访问者导航到了主页面，这与客户的需求不相符。这种问题会在 UAT 测试时被指出。而在非 CD 环境，就成了人工的 QA 测试人员的工作。</description>
    </item>
    
    <item>
      <title>特性开关和 GitOps, 5个用例帮您搞定。</title>
      <link>https://jenkins-zh.cn/wechat/articles/2020/03/2020-03-09-feature-flags-and-gitops-5-use-cases-to-help-you-git-r-done-45ga/</link>
      <pubDate>Mon, 09 Mar 2020 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.cn/wechat/articles/2020/03/2020-03-09-feature-flags-and-gitops-5-use-cases-to-help-you-git-r-done-45ga/</guid>
      <description>GitOps 的实践是持续交付的下一个替代。它允许开发人员进入 IT 运维的传统工作范围-许多历史关卡的所在地-自动更新生产环境的应用程序和运行程序的基础设施。在 GitOps 中，所有变更管理和版本控制的唯一可信来源是软件配置管理（SCM）。GitOps 抛弃了传统 ITIL 类型的管理，将基础设施和应用程序视为版本化的制品，包括在软件开发期间捕获的相同粒度的审计轨迹（提交 ID，时间戳等）。
我的看法 GitOps 的思想是通过 Git 提交将整个系统的期望状态存储在版本控制系统中。从本质上，您可以将 GitOps 视为一个文件版本控制系统。GitOps 一个关键的原则是通过使用遵守声明式规范的配置文件描述应用程序和环境的期望状态。
这意味着配置根据实际情况而不是操作指南列表管理。它给你一个规则来检查结果是否正确，而不是给你一个配置清单去创建一个系统。你可以用这种方式描述你整个的 CI/CD 流水线并将其放在代码仓库中。为了变更到期望的状态，开发人员发出一个 Pull rquest ，这基本上告诉所有人您已发布到仓库的变更，并告知仓库将变更拉入。通过使用Git，您可以获得版本历史记录、审核日志、回滚功能以及查看谁更改了什么以及何时更改的功能。
特性开关 + GitOps 当我们考虑 GitOps 时，会立即想到的用例是容器编排和集群管理—特别是使用声明性工具 Kubernetes。没有多少人会立即想到[特性标志][1]。那么为什么我们认为特性标志这么重要？这很重要，因为 GitOps 的愿景是对整个系统的全面控制。特性开关通常被视为“规则之外”的活动。我们相信，特性开关-尤其是达到一定规模-将成为一个非常强大的工具，如果它们的管理方式与代码的其他部分一样严格、管理和受重视。如果要使用 GitOps 来管理特性开关，则必须使用配置文件描述它们所需的状态。但这还不是全部。
有一种正确的方法可以将 GitOps 应用于特性开关 特性开关是一个粘性的小窗口。它们拥有进行生产变更的能力，但它们不会像其他代码一样承担生产准备就绪的检验的责任。如果它要成为软件交付生命周期的一部分，就需要不断发展。
如果我们想用 GitOps 管理特性标志，那么所需的状态（由声明性规范描述）必须保存到配置文件中。我们使用 YAML，以便它是人类可读和可编辑的。当需要更新到期望的状态时，只需简单的合并配置即可。此变更通过建立了审核跟踪的PR提交，并确保正确的人员正在验证更改—这正是当有人更改应用程序中的代码或更新基础设施设置时所发生的更改。我们相信这是用 GitOps 管理特性开关的正确方法。这也是最符合供应商中立的愿望的做法。
据我们所知，只有[ CloudBees Rollout ][2]能够支持这一点。我们的一些竞争对手也有一个配置文件，他们的SDK知道如何读取和更改它。但是，它不是可编辑的。它也不会自动保存在像 GitHub 这样的 SCM 中。它们迫使用户绕过管理代码的既定过程，以便管理特性开关。例如，如果需要功能回滚，客户将被迫使用第三方仪表板，而不是 Git。
使用 CloudBees Rollout 管理特性开关的一些‘Git’用例 [配置即代码][3]，这个术语经常与基础设施作为代码（IaC）互换使用，但它实际上是不同的。IaC 是关于基础设施栈的管理和配置，而 CaC 是关于在环境之间自动迁移配置。这都是为了进行环境配置的有力工具。不允许有雪花。我们对待特性开关的方式与配置对待应用程序的方式相同（我们在这里使用 CaC 术语而不是 IaC，因为特性开关不是基础设施的一部分，而是在软件应用程序上）。当我们讨论 GitOps 时，这意味着我们可以用 PR 跟踪 SCM 中应用程序的变更和版本控制的方式，记录特性开关中发生的更改和版本控制。将更改推送到主分支通过 SDK 触发一个待处理的事件。然后，系统知道如何将特性开关更新到 YAML 文件配置所期望的状态。</description>
    </item>
    
    <item>
      <title>使用 Visual Studio Code 验证 JCasC 配置文件</title>
      <link>https://jenkins-zh.cn/wechat/articles/2020/03/2020-03-06-validating-jcasc-configuration-files-using-visual-studio-code/</link>
      <pubDate>Fri, 06 Mar 2020 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.cn/wechat/articles/2020/03/2020-03-06-validating-jcasc-configuration-files-using-visual-studio-code/</guid>
      <description>配置即代码插件 问题陈述：将现有的模式验证工作流程脚本语言 Jenkins 配置即代码插件转换为基于 Java 的重写，从而增强其可读性和可测试性，并由该测试框架提供支持。通过开发 VSCode 插件来促进自动完成和验证，从而增强开发人员的经验，这将有助于开发人员在应用到 Jenkins 实例之前编写正确的 yaml 文件。
配置即代码插件已被设计为 Jenkins 基于声明式配置文件配置的基本方式，无需成为 Jenkins 专家亦可编写这样的文件，只需将配置过程中转换成用于在 web UI 中执行的代码即可。该插件使用此类模式来验证要应用于 Jenkins 实例的文件。
启用了新的 JSON 模式后，开发人员现在可以针对其测试 yaml 文件。该模式检查 descriptors，即可以应用于插件或 Jenkins 核心的配置，使用正确的类型并在某些情况下提供帮助文本。 VSCode 允许我们通过一些修改立即测试架构。该项目是 Community Bridge 计划的一部分，Community Bridge 计划是 Linux 基金会创建的一个平台，旨在使开发人员以及支持他们的个人和公司提高开源技术的可持续性、安全性和多样性。您可以看一下Jenkins Community Bridge 项目。
启用架构验证的步骤  第一步安装 Visual Studio Code 的 JCasC 插件，并通过扩展列表打开扩展。使用 Ctrl + Shift + X 在 VSCode 编辑器中打开扩展列表的快捷方式。
 为了启用验证，我们需要将其包括在工作空间设置中。依次导航到 File，Preference 和 Settings。内部设置中搜索 json，内部 settings.json 中包含以下配置。
  { &amp;quot;yaml.</description>
    </item>
    
    <item>
      <title>Screwdriver 作为 CD 基金会的第一个孵化项目加入 CD 基金会</title>
      <link>https://jenkins-zh.cn/wechat/articles/2020/03/2020-03-05-screwdriver-joins-cd-foundation/</link>
      <pubDate>Thu, 05 Mar 2020 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.cn/wechat/articles/2020/03/2020-03-05-screwdriver-joins-cd-foundation/</guid>
      <description>持续交付基金会（CDF），在持续交付领域对许多增长最快的项目来说是一个供应商中立的家，宣布 Screwdriver 成为其最新的孵化项目。 Screwdriver 是一个独立的、可插拔的服务，用于帮助开发人员使用最新的容器化技术构建、测试以及持续交付软件。 Screwdriver 最初是由 Yahoo（现在的 Verizon Media）开发的，用于简化 Jenkins 的接口。 它于2016年开源，并经过完全重写以应对大规模部署以及 CI/CD 目标。
Screwdriver 与 DevOps 团队的日常习惯直接相关。它测试 pull request，构建合并提交并部署到任何环境。它还轻松定义了负载测试、金丝雀部署和多环境部署流水线。
立即开始为 Screwdriver 做贡献吧。时刻欢迎提 pull request。从浏览 Screwdriver 贡献指南 开始吧。
“CD 基金会欢迎 Screwdriver。我们相信 Screwdriver 开创了一个良好的开端，我们很高兴能一起工作。通过加入 CD 基金会，Screwdriver 将能够更快地扩展规模，在开发和部署方面取得更大的进步。” CDF 项目经理 Dan Lopez 说。“有了如此多支持的集成，Screwdriver 提供了 DevOps 团队所需要的开放性和灵活性。”
“Screwdriver 团队和平台是 Yahoo 和 Verizon Media 的英雄，他们可以帮助我们运行大规模的软件工程业务。我们在一起也可以使您的 CI/CD 团队英雄成为您公司的英雄。我们邀请您在这个中立的家中与我们合作，以实现卓越的开源。” Verizon Media/Yahoo开 源高级总监 Gil Yehuda 这样说。
“很高兴看到 Screwdriver 加入 CDF。我知道该项目的幕后工作人员与我们一样对同一件事充满热情，并且我们可以一起共同更快地产生更大的影响。事实证明，开源具有实现跨项目边界的独特能力。” Launchable，Inc. 联合首席执行官 Kohsuke Kawaguchi 这样说。
CD Foundation 为项目提供广泛的服务，第一步是从孵化项目开始。有关将开源 CI/CD 项目引入 CDF 的完整详细信息，请参见此处。</description>
    </item>
    
    <item>
      <title>DevOps 的出色表现</title>
      <link>https://jenkins-zh.cn/wechat/articles/2020/03/2020-03-02-good-to-great-with-devops/</link>
      <pubDate>Mon, 02 Mar 2020 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.cn/wechat/articles/2020/03/2020-03-02-good-to-great-with-devops/</guid>
      <description>DevOps 不断发展，自从2009年提出此术语以来，DevOps 的状态每年都呈指数级增长。在2019年飞速发展的过程中，各种规模和形态的组织（从企业到初创公司）在 DevOps 方面都展现了极大的热情。每个组织都有其自己的 DevOps故事，其中一些故事尚未开始，一些故事还处于婴儿期，有些故事已经成熟，有些故事已经达到顶峰。 不同于其他故事，DevOps 故事源于不断改进。
随着企业逐渐变得数字化和软件驱动，人们对 DevOps 旅程的本质和可能性有了更大的认识。不仅工程师或技术领导者，甚至商业领导者都对 DevOps 的概念、实践和应用非常感兴趣。对于实现商业成功的 DevOps 的需求已得到越来越广泛的接受。
《 2019 年 DevOps 状态报告》作为大量在线资源的提供者之一，可用于解和学习 DevOps 如何塑造跨行业的软件交付。该报告极大地总结了软件交付的趋势和挑战，它可以帮助团队研究可用于提升软件交付能力并最终成就卓越。
在此报告中，IT 性能称为软件交付能力，以区分软件交付工作与 IT 服务台和其他支撑功能。这是一个期待已久的可喜变化。我也喜欢的关键更改之一是增加了运营指标以完成软件交付周期。该报告重点介绍了五个被称为“软件交付和运营（SDO）性能指标”的度量或指标，它们侧重于系统级结果。这有助于避免软件度量标准的常见陷阱，后者常常使不同的功能相互冲突，并导致以牺牲总结果为代价的局部优化。
该报告重点介绍了软件交付能力的四个方面，如下所示：
 部署频率 – 对于您从事的主应用程序或服务，您的组织多久部署一次代码？ 变更的前置时间 – 对于您从事的主应用程序或服务，您的变更前置时间是多少（即，从代码提交到成功在生产中运行的代码需要多长时间）？ 恢复服务的时间 – 对于您正在使用的主应用程序或服务，发生服务事件（例如计划外中断或服务受损）时，恢复服务通常需要多长时间？ 变更失败率 – 对于您使用的主应用程序或服务，导致服务质量下降或随后需要修复（例如，导致服务受损、服务中断，需要修改程序、回滚、向前修复、修补程序）的变更的百分比？  然后对这四个方面进行度量，以对四个类别的性能进行排名：精英、高级、中级和低级。下表（从报告中引用）指示了各个方面的详细信息。
我强烈建议添加到此列表中的另一个方面是“团队敬业度指数”，即团队的快乐程度和参与度。我认为团队绩效与团队敬业度成正比。团队敬业度越高，即团队越快乐越敬业，他们产生的结果就越好。
报告中的另一个主题是“ J 转换曲线”。下图突出显示了自动化如何帮助绩效低下的人员提升到中等性能水平，然后测试需求、技术负担和复杂性增加导致手动操作，从而导致进度变慢。这是一个有趣且值得注意的观察。它强调了自动化并不总是答案。如果您使错误的流程自动化，那么您得到的只是错误的结果，而且更快。
无休止的改进、学习、共享和利用专业知识可将您带到高水平或精英绩效水平 – 将团队提升为精英绩效的旅程需要的不仅仅是工具。在各个级别（即团队级别、领导级别和赞助者级别）的坚持、恒心和毅力对于从低绩效水平或中绩效水平取得突破以发挥团队最大潜力至关重要。如果我们踏上精英绩效之旅，您会发现自动化、技术实践和持续改进计划是您旅途的催化剂。鉴于测试需求、技术债务和日益增加的复杂性将成为您的阻碍，我发现锚定和引擎（帆船回顾展）格式提供了一种快速而有趣的方法，可在一幅图片中（如下所示）可视化催化剂（引擎）和阻滞剂（锚定）。
行业看到了更高的精英绩效 该报告证实，精英表演者的比例几乎增加了两倍，低表现者的比例下降了，中等表演者的比例上升了。要注意的一项主要观察结果是，从低性能到中性能再到高性能的移动不是单向的。当面对复杂性增加时，团队（从 J 曲线中突出显示）可以从高位降为中级，也可以从中级降为低级。总体而言，很高兴看到向上增加。
前进之路 软件交付性能可以通过多种方式确定业务成果。 组织推动软件交付绩效的能力包括文化，技术实践，清晰的变更流程，持续交付和基于价值的成果。 这些功能并不是一蹴而就的，需要对组织 DNA 进行根本性的改变。
根据我在不同行业和公司中工作的经验，我可以确认这些软件交付能力集群不是静态的。上面列出的任何功能的更改都会对软件交付能力产生影响，您可能会发现能力集群在两个方向上都从一个级别波动到另一个级别。关键是要保持专注并通过定期将其嵌入组织的工作方式中来维持它。</description>
    </item>
    
    <item>
      <title>T-Mobile 和 Jenkins 案例研究</title>
      <link>https://jenkins-zh.cn/wechat/articles/2020/02/2020-02-28-t-mobile-and-jenkins-case-study/</link>
      <pubDate>Fri, 28 Feb 2020 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.cn/wechat/articles/2020/02/2020-02-28-t-mobile-and-jenkins-case-study/</guid>
      <description>Jenkins 在 T-Mobile 节省数千小时和数百万美元 大多数人都知道 T-Mobile 是无线服务提供商。毕竟，我们拥有国际化的业务，并且是美国第三大移动运营商。但是我们还是一家技术公司，提供的新产品包括 TVision 家庭电视服务，T-Mobile Money 个人银行产品以及 SyncUp Drive 车辆监控和路边辅助设备。
在幕后，T-Mobile 还是开源社区的领导者。我们已经在 GitHub 上共享了 35+ 个代码存储库（包括我们的 POET 流水线框架自动化库），以通过采用健壮和智能的做法来加快 CI/CD 周期，从而帮助其他组织支持内部和外部客户。
我是 T-Mobile 系统可靠性工程（SRE）部门的高级系统可靠性工程师。我们的团队成功地将 POET 实施的第一阶段推广到了 30 多个团队。这是一个巨大的成功，并且计划使用结合在 Kubernetes 集群上运行的 Jenkins 和 CloudBees Core 的稳定、可靠的 CI/CD 流水线，将其扩展到我们的 350 个开发团队和 5,000 个活跃用户。
更少的插件，更多的 Master 我们从构建简化的基于容器的流水线基础结构开始，该基础结构可以集中管理并易于适应开发方法。结果使我们的开发团队有更多的精力专注于开发和测试应用程序，而不是维护 Jenkins 环境。
然后，我们将在 master 中使用的 Jenkins 插件的数量从 200 个减少到了 4 个。有超过 1,000 种此类附加组件，包括构建工具，测试实用程序和云集成资源。它们是扩展平台的绝佳方法，但它们也是 Jenkins 的致命弱点，因为它们可能引起冲突。
接下来，我们从一个单一的 Master 给我们所有的 Jenkins slave 提供动力变成了多个 Master，现在拥有 30 个流水线引擎，每个引擎为大约 10 个团队提供动力。此设置减少了 CPU 负载和其他瓶颈，同时允许 T-Mobile 的 DevOps 团队继续享受水平扩展的优势。</description>
    </item>
    
    <item>
      <title>Jenkins CLI 命令行 v0.0.26</title>
      <link>https://jenkins-zh.cn/wechat/articles/2020/02/2020-02-24-jcli-v0.0.26/</link>
      <pubDate>Mon, 24 Feb 2020 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.cn/wechat/articles/2020/02/2020-02-24-jcli-v0.0.26/</guid>
      <description>本次版本发布，增加了两种包发行版：snapcraft、Chocolatey。snapcraft 是由 Ubuntu 提供的一个全新的 包管理器，它可以在 CentOS、Ubuntu、SUSE 等12种操作系统下使用。因此，Linux 用户可以更加方便地使用 jcli。 命令行自动补全的特性可以大幅提高用户的工作效率，除了 bash 的用户外，zsh 以及 powerShell 的用户，现在也可以使用 jcli 的命令补全特性了。
🚀 功能  支持查看 jcli 的变更日志 (#328) @LinuxSuRen 支持根据父目录搜索任务 (#327) @LinuxSuRen 支持升级所有的插件 (#258) @yJunS 增加对 zsh 和 powerShell 的命令行补全的支持 (#296) @LinuxSuRen  🐛 缺陷修复  修复了无法启动非 LTS 的 Jenkins (#322) @LinuxSuRen 修复无法创建凭据的问题 (#325) @LinuxSuRen  📝 文档完善  增加对 snapcraft 的支持 (#321) @LinuxSuRen 增加对 Chocolatey 的支持 (#312) @LinuxSuRen 增加从 bintray 下载 jcli 的文档描述 (#299) @LinuxSuRen  👻 维护  在构建过程中，通过 GitHub Action 对临时文件的归档 (#333) @LinuxSuRen 升级依赖 github.</description>
    </item>
    
    <item>
      <title>使用容器化和 Docker 实现 DevOps 的基础知识</title>
      <link>https://jenkins-zh.cn/wechat/articles/2020/02/2020-02-21-the-abc-of-devops-implementation-with-containerization-and-docker/</link>
      <pubDate>Fri, 21 Feb 2020 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.cn/wechat/articles/2020/02/2020-02-21-the-abc-of-devops-implementation-with-containerization-and-docker/</guid>
      <description>DevOps 在 IT 行业中风靡一时。维基百科中阐述 DevOps 是将软件开发（Dev）和信息技术维护（Ops）结合在一起的一组实践，旨在缩短系统开发生命周期并提供高质量的持续交付。 DevOps 普及的主要原因是，它使企业可以比传统软件开发方法更快地开发和改进产品。
随着我们工作环境的变化越来越快，对软件开发市场中的快速交付和修复的需求正在上升。 因此，对在短时间内生产高质量输出且有限的后期错误需求催生了 DevOps。
你可能感兴趣：Docker 和 DevOps：开发有状态的应用程序并在 Docker 中进行部署
正如我们已经讨论了转变为 DevOps 软件开发方式的重要性一样，我们现在将对话更改为容器化，这是一种易于使用的技术，经常被用来使 DevOps 的实现更流畅、更便捷。 容器化是一项使 DevOps 实践更容易遵循的技术。 但是容器化到底是什么？ 让我们一探究竟！
什么是容器化？ 容器化是将应用程序及其所需的库、框架和配置文件打包在一起的过程，以便可以在各种计算环境中高效运行它。简单来说，容器化就是应用程序及其所需环境的封装。
近来，它克服了运行虚拟机所带来的挑战，从而获得了广泛的关注。虚拟机模拟主机操作系统内部的整个操作系统，并且需要固定比例的硬件分配才能运行操作系统的所有进程。因此，由于很大的开销，这导致不必要的计算资源浪费。
同时，设置虚拟机需要花费时间，在每个虚拟机中设置特定应用程序的过程也需要时间。这导致仅在设置环境时就花费了大量时间和精力。由开源项目 “Docker” 普及的容器化解决了这些问题，并且通过将所有必需的依赖项与软件一起打包在便携的镜像文件中，从而提高了可移植性。
让我们更深入地研究容器化，它的好处、它的工作原理、选择容器化工具的方式以及它如何胜过虚拟机（VM）的使用。
一些流行的容器提供程序如下：
 Linux 容器，例如 LXC 和 LCD Docker Windows Server 容器  什么是 Docker？ Docker 已经成为 IT 行业中的一个流行术语。 Docker 可以定义为一个开源软件平台，它提供了一种在容器内构建、测试、保护和部署应用程序的简化方法。 Docker 鼓励软件开发人员与云、Linux 和 Windows 操作系统进行协作，以轻松、快速地交付服务。
Docker 是提供容器化的平台。它允许将应用程序及其依赖项打包到一个容器中，从而有助于简化开发并加快软件的部署。它消除了在应该测试解决方案的每台机器上复制本地环境的需求，从而帮助实现了输出的最大化，从而节省了宝贵的时间和精力，而这些宝贵的时间和精力将用于进一步的开发。
Dockerfile 可以在工作人员之间快速传输和测试。 Docker 还简化了容器镜像管理的过程，并迅速改变了我们大规模开发和测试应用程序的方式。
容器化——实现 DevOps Docker 已普及了容器化的概念。 Docker 容器中的应用程序具有能够在多种操作系统和云环境（例如 Amazon ECS 等）上运行的能力。没有技术或供应商局限。</description>
    </item>
    
    <item>
      <title>2019 年 Google 编程之夏活动报告</title>
      <link>https://jenkins-zh.cn/wechat/articles/2020/02/2020-02-18-google-summer-of-code-2019-report/</link>
      <pubDate>Tue, 18 Feb 2020 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.cn/wechat/articles/2020/02/2020-02-18-google-summer-of-code-2019-report/</guid>
      <description>Google 编程之夏活动不仅仅是一个夏日的实习项目，对于组织和一些社区的成员来说，这个活动是他们一整年努力的成果。现在，在里斯本举行的 Devops World | Jenkins World 会议以及最后的回顾会议之后，我们宣布 GSoC 2019 正式画上结束的句号。首先我们感谢所有的参与者：学生们、导师们、主题专家、以及其他一些提出课题构想，参与学生选择，社区联系以及一些后期的讨论与回顾的贡献者们。Google 编程之夏活动是一个大型的活动，如果没有 Jenkins 社区的积极参与此次活动也就无法成行。
在这篇博客里我们想要与各位分享这次活动的成果以及我们从这一年总结的一些经验。
成果 今年成功完成了 5 个 GSoC 课题：角色策略插件性能优化，插件安装管理 CLI 工具/库，working-hours 插件 - UI 优化，具有 Kubernetes 功能的 Apache Kafka 远程处理，GitLab SCM 多分支流水线支持。我们会在后面的内容中讨论一下上面提到的这几个课题。
项目细节 我们在 8 月底举行了最后一次 Jenkins 线上例会的演讲然后 Google 在 9 月 3 日发布了这些成果。最后的这些演讲内容可以从这里找到：第一部分，第二部分，第三部分。我们也在 DevOps World | Jenkins World 旧金山以及 DevOps World | Jenkins World 2019 里斯本会议中发布了2019 Jenkins GSoC 报告。
在下面的章节中，我们对每一个项目做一个简单的总结，第三阶段编码演示文稿的链接以及最后的成品。
角色策略插件性能优化 角色策略插件是 Jenkins 中最广泛被使用的认证插件之一，但因为其架构问题以及对项目角色的正则表达式检查使其没有因性能著称。Abhyudaya Sharma 与他的几位导师：Oleg Nenashev，Runze Xia，Supun Wanniarachchi 一起进行该项目。他为 Jenkins 插件创建了一个基于 JMH 的微基准测试框架，创建微基准测试然后在一些真实场景中得到了 3501% 的提升。然后他继续深入研究创建了一个基于目录的认证策略插件，当权限范围为目录时该插件为 Jenkins 实例提供了更佳的性能。在他的项目中 Abhyudaya 还修复了对 Jenkins 组策略的配置即代码的支持并为 JCasC 插件贡献了一些优化与修复的代码。 - 项目页面 - 发布的博客：Jenkins 微基准测试框架， 引入一个新的目录认证插件，角色策略插件性能优化 - 最终评估：幻灯片，视频 - 源码：角色策略插件，目录认证插件</description>
    </item>
    
    <item>
      <title>Happy Second Birthday Jenkins X!</title>
      <link>https://jenkins-zh.cn/wechat/articles/2020/02/2020-02-17-happy-second-birthday-jenkins-x/</link>
      <pubDate>Mon, 17 Feb 2020 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.cn/wechat/articles/2020/02/2020-02-17-happy-second-birthday-jenkins-x/</guid>
      <description>始于 2019 年初的 Jenkins X 项目在去年的1月14号庆祝了它的第一个生日，这对任何开源项目来说都是一件大事，我们刚刚又庆祝了它的第二个生日。
Jenkins X 的两周年！ Jenkins X 已经从一个关于 CI/CD 如何在云原生世界中被重新设计的愿景，进化到了一个快速发展、创新并迅速成熟的开源项目。
Jenkins X 是为了帮助开发者们能够快速的将代码发布到 Kubernetes 上而创建的。从一开始，Jenkins X 就致力于改善开发者的开发体验。使用一个命令行工具，开发者就能构建 Kubernetes 集群，部署流水线，创建应用，新建 Github 仓库，将应用推送至 Github 仓库，新建 Pull Request，构建容器，在 Kubernetes 中运行该容器并最终合并到产品中。为了做到这些，Jenkins X 对一系列同类最佳开源工具进行了自动化安装与配置，并且自动化了所有流水线的生成。Jenkins X 还通过测试、过渡和生产环境对应用程序的升级进行了自动化改造，使开发人员能够获取大量到的变更反馈。例如，Jenkins X 的预览环境容许快速与及早的反馈，这样开发者便能在自动构建的环境中查看应用的实际功能。我们发现，由 Jenkins X 在流水线中自动创建的预览环境在开发者中十分流行，因为他们能够在将代码合并到 master 分支之前查看变更情况。
Jenkins X 本身是功能专一的，但是却极易拓展。Jenkins X 是为实现 DevOps 最佳实践而创建的，旨在跨团队的可重复、可管理的方式中，能够完成大量分布式微服务的部署工作。Jenkins X 促进了大量已被检验的最佳实践，如基于主干的开发和 GitOps。为了让您能够快速上手与使用，Jenkins X 提供了许多快速入门的例子。
属于 Jenkins X 的 2019 高光时刻 2019 年 2 月：Tekton 的崛起！ 在 2018 年的后半年，Jenkins X 开始了一趟提供 Serverless Jenkins 与仅在需要时运行流水线引擎的旅程。这种流水线引擎基于 knative build-pipeline 项目，该项目进化成为了受到 Jenkins 和 Jenkins X 社区众多帮助与热爱的 Tekton 。Jenkins X 项目在 2019 的 2 月完成了与 Tekton 的初次集成。Tekton 是一个强大和灵活的 Kubernetes 原生开源框架，用于创建 CI/CD 流水线、管理制品和渐进部署。</description>
    </item>
    
    <item>
      <title>展望 2020 年 DevOps 的发展趋势</title>
      <link>https://jenkins-zh.cn/wechat/articles/2020/02/2020-02-14-devops-trends-to-watch-for-in-2020/</link>
      <pubDate>Fri, 14 Feb 2020 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.cn/wechat/articles/2020/02/2020-02-14-devops-trends-to-watch-for-in-2020/</guid>
      <description>Netscape 的创始人 Marc Andreessen 很久之前就谈到过软件是如何吞噬整个世界的。他还说过，当今，每一家公司都可谓是软件公司，它们已经做好准备来接管广阔的经济领域。在 2020 年，您会清晰地看到 DevOps 持续不断的更新是如何改变交付方式的，将软件交付到几乎是无限的市场中。在这个技术竞争激烈的世界中，DevOps 已成为蓬勃发展的必需品了。
导引 虽然每个企业对 DevOps 有着不同的理解，但我们仍然可以将 DevOps 定义为一个团队为了将其工程能力提升到新的高度而采用的一种心态。DevOps 的主要目的是消除工程实践上的障碍，重点是那些存在于想法和实践之间的文化障碍，从而使软件的交付过程变的更好、更快、更廉价和更安全。
无论您怎样称呼 DevOps，它最终都应该归结为自动化，而自动化反过来又应该有助于公司的快速发展、快速交付、快速失败、快速恢复以及快速学习。
从 SDLC（System Development Life Cycle，系统生命周期）模型的出现到今天，情况已经发生了巨大的变化。在 2009 年，DevOps 诞生了，它倡导文化的转型和一些将所有事物都视为代码的技术原则。随后出现了诸如 CI/CD 之类的理念，但是，软件曾经是作为一个巨大的单体被编写的，这个转变过程带来了许多挑战。
因此，在 2011 年引入了微服务架构，它提倡细粒度和松耦合的组件划分方式，其中每个组件都承担特定的职责。
遵循这种松耦合、微服务架构而编写的应用程序被称为云原生应用。当前，众多企业根据其业务需求和目标，正在从虚拟机过渡到 Kubernetes 和 Serverless。
根据 Kelly Shortridge 和 Nicole Forsgren 博士在 Black Hat USA 2019 上发布的幻灯片，在与 DevOps 行业中卓越的实践者进行对标时，有四个因素特别关键，分别是：
 变更前置时间 发布频率 恢复时长 变更失败率  在本文中，我们将会了解到 DevOps 在未来的发展趋势。
云原生将成为必然 Diamanti 对 500 多位 IT 主管进行了调查。结果表明，从所有方面来看，容器技术已经远远超出了预期，它在一年内迅速成熟，并从开发者试验转向了生产环境。云原生技术将会上升到一个新的高度，尤其是对 Kubernetes 的采用。云原生为公司提供了更大的优势，使其以更快的速度将产品推向市场。
什么是云原生 采用云原生意味着更好的创新、更先进的转型以及更丰富的客户体验。如我在的另一篇文章“ Cloud-Native DevOps”中所述，云原生从根本上促进了云自动化，这里指的是云计算服务的安装、配置和监控的自动化管理，它是关于使用技术在恰当的时间为您的云计算资源做出更可靠的业务决策。</description>
    </item>
    
    <item>
      <title>Jenkins 创始人 Kohsuke 的新篇章</title>
      <link>https://jenkins-zh.cn/wechat/articles/2020/02/2020-02-12-a-new-chapter-for-kohsuke/</link>
      <pubDate>Wed, 12 Feb 2020 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.cn/wechat/articles/2020/02/2020-02-12-a-new-chapter-for-kohsuke/</guid>
      <description>2020 年对我来说将是转变的一年。在 1 月底，我将正式退出 Jenkins，将我在 CloudBees 的角色转换为顾问，并将注意力转向我的新创业公司。这篇文章的其余部分将结合这种过渡的背景，如果您没有与我紧密合作，这可能会令您惊讶。
Jenkins 之旅充满神奇，而且从未间断。我非常喜欢这一切，尤其是与造就 Jenkins 如今成就的世界各地的用户会面与交流。作为项目的创建者，在某个时候，我开始想如何将火炬传递给下一任领导者，如何使人们继续推动它前进。如今，由于有了 CloudBees 和社区，新一代的才华横溢、有才干的领导者正在热情地推动事情向前发展，这真令人高兴。例如，新选举的董事会成员和Jenkins X 的伙伴们。这些新人带来了新的文化和新的代码，并且总的来说，这产生了积极的影响，使 Jenkins 不再局限于我所谈论的局部最优方法，他们得到我所有的支持和尊重。实际上，我最近与 Jenkins 的关系更多的是象征意义，有点像日本的天皇或英国的皇后，这就是为什么此公告对 Jenkins 的前进动力几乎没有实际影响的原因。
几年前，我曾经觉得如果我退出的话，天就会塌下来。在 2019 年的某个时刻，我突然发现我没有这种感觉了。这种转变是渐进的、稳定的，所以我不确定自己何时跨过的这道门槛，但是在 2019 年，我显然处于另一端。这样我才知道自己终于可以结束我的这一篇章。回首与 Jenkins 在一起 15 年，与 CloudBees 合作 9 年，这真是很长的一段时间。
我希望您会想知道我的新篇章是什么。我将与我的老伙伴 Harpreet Singh 创办一家新的创业公司，即 Launchable。自从在 Sun Microsystems 和 JavaEE 工作以来，我就认识他，他是我在 CloudBees 领域的合伙人，从头开始建立 Jenkins 业务。他去 Atlassian 经营 BitBucket 业务已有一段时间，但是现在他和我又回到了一起。许多 CloudBees 人投资了 Launchable，包括 Sacha Labourey、Bob Bickel 和 John Vrionis。
通过 Jenkins 和 CloudBees ，我得以推动软件开发中自动化的发展。这种自动化产生了大量数据，但我们并未使用这些数据来改善我们的生活，这确实是一个浪费的金矿。Launchable 正在努力利用这些信息来提高开发人员的生产力。我写了一篇单独的博客文章，以讨论有关我的想法的更多信息。
最后，即使离开 CloudBees 不再作为其一名全职员工，也并没有完全离开，我将继续作为 CloudBees 的顾问，我仍然在情感和财务上都对 CloudBees 进行了大量投资。我仍然是狂热的粉丝，我会继续为他们加油，只不过是在默默观望。Jenkins 也一样，我仍然在董事会中，以确保连续性。我仍在持续交付基金会的技术监督委员会任职，虽然我的主席任期将于 3 月届满。</description>
    </item>
    
    <item>
      <title>WebSocket</title>
      <link>https://jenkins-zh.cn/wechat/articles/2020/02/2020-02-10-webSocket/</link>
      <pubDate>Mon, 10 Feb 2020 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.cn/wechat/articles/2020/02/2020-02-10-webSocket/</guid>
      <description>我很高兴地提出报告，JEP-222 从 Jenkins 每周更新版开始落地。此改进为 Jenkins 带来了实验性的 WebSocket 支持，可在连接入站代理程序或运行 CLI 时使用。WebSocket 协议允许通过 HTTP（S）端口进行双向交互式通信.
尽管 Jenkins 的许多用户都可以受益，但实现该系统对 CloudBees 尤为重要，因为 现代云平台上的 CloudBees Core（即在 Kubernetes 上运行）如何配置网络。当管理员希望将入站（以前称为“JNLP”）外部代理连接到 Jenkins 主服务器（例如在集群外部运行并使用代理服务包装器的 Windows 虚拟机）时，到目前为止，唯一的选择是使用特殊的 TCP 端口。需要使用低级网络配置将此端口开放给外部流量。例如，nginx 入口控制器的用户将需要为集群中的每个 Jenkins 服务代理一个单独的外部端口。有关此操作的说明很复杂，很难调试。
使用 WebSocket，现在可以在存在反向代理的情况下更简单地连接入站代理：如果 HTTP（S）端口已在提供流量，则大多数代理将允许 WebSocket 连接而无需其他配置。可以在代理配置中启用 WebSocket 模式，并且即将推出 Kubernetes 插件中对基于 Pod 的代理的支持。您将需要一个4.0 或更高版本的代理，该代理版本以常规方式与 Jenkins 捆绑在一起（带有该版本的 Docker 镜像即将发布）。
Jenkins 的另一个对反向代理用户造成麻烦的部分是 CLI。除了端口 22 上的 SSH 协议（这又是从外部打开的麻烦）之外，CLI 还具有使用 HTTP（S）传输的功能.不幸的是，用于实现混淆某些技巧的技巧并不十分可移植。Jenkins 2.217 提供了一个新的 webSocket CLI 模式，该模式避免了这些问题。再次说明，您将需要下载新版本的 jenkins-cli.jar 才能使用此模式。
已经针对 Kubernetes 实现示例（包括 OpenShift）对 WebSocket 代码进行了测试，但是很可能仍然存在一些 bugs 和局限性，并且尚未测试重构建负载下代理的可伸缩性。暂时将此功能视为 Beta 版，并让我们了解其工作原理！</description>
    </item>
    
    <item>
      <title>完整的 CI/CD 集合[教程]</title>
      <link>https://jenkins-zh.cn/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.cn/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.cn/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.cn/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.cn/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.cn/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.cn/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.cn/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.cn/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.cn/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.cn/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.cn/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.cn/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.cn/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.cn/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.cn/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.cn/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.cn/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.cn/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.cn/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.cn/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.cn/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.cn/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.cn/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.cn/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.cn/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.cn/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.cn/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.cn/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.cn/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.cn/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.cn/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.cn/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.cn/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.cn/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.cn/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.cn/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.cn/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.cn/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.cn/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.cn/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.cn/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.cn/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.cn/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.cn/wechat/articles/2019/10/2019-10-20-online-activity/</link>
      <pubDate>Sun, 20 Oct 2019 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.cn/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.cn/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.cn/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.cn/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.cn/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.cn/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.cn/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.cn/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.cn/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.cn/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.cn/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.cn/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.cn/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.cn/wechat/articles/2019/09/2019-09-05-award/</link>
      <pubDate>Thu, 05 Sep 2019 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.cn/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.cn/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.cn/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.cn/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.cn/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.cn/wechat/articles/2019/08/2019-08-19-hackathon-signup/</link>
      <pubDate>Mon, 19 Aug 2019 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.cn/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.cn/wechat/articles/2019/08/2019-08-17-award/</link>
      <pubDate>Sat, 17 Aug 2019 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.cn/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.cn/wechat/articles/2019/08/2019-08-16-tutor-recruitment/</link>
      <pubDate>Fri, 16 Aug 2019 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.cn/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.cn/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.cn/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.cn/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.cn/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.cn/wechat/articles/2019/08/2019-08-09-volunteer-recruitment/</link>
      <pubDate>Fri, 09 Aug 2019 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.cn/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.cn/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.cn/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.cn/wechat/articles/2019/08/2019-08-07-hackathon-startup/</link>
      <pubDate>Wed, 07 Aug 2019 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.cn/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.cn/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.cn/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.cn/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.cn/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.cn/wechat/articles/2019/07/2019-07-30-jenkins-meetup/</link>
      <pubDate>Tue, 30 Jul 2019 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.cn/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.cn/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.cn/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 每周版更新</title>
      <link>https://jenkins-zh.cn/wechat/articles/2019/07/2019-07-18-jenkins-weekly-release/</link>
      <pubDate>Thu, 18 Jul 2019 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.cn/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 对 Java 11的支持</title>
      <link>https://jenkins-zh.cn/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.cn/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.cn/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.cn/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.cn/wechat/articles/2019/07/2019-07-09-jenkins-release/</link>
      <pubDate>Tue, 09 Jul 2019 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.cn/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.cn/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.cn/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.cn/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.cn/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.cn/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.cn/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.cn/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.cn/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.cn/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.cn/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.cn/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.cn/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.cn/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.cn/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.cn/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.cn/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.cn/wechat/articles/2019/06/2019-06-09-github-share/</link>
      <pubDate>Sun, 09 Jun 2019 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.cn/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.cn/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.cn/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.cn/wechat/articles/2019/05/2019-05-29-jenkins-release/</link>
      <pubDate>Wed, 29 May 2019 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.cn/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.cn/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.cn/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.cn/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.cn/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.cn/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.cn/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.cn/wechat/articles/2019/05/2019-05-23-chinese-localization/</link>
      <pubDate>Thu, 23 May 2019 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.cn/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.cn/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.cn/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.cn/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.cn/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.cn/wechat/articles/2019/05/2019-05-20-translation-norms/</link>
      <pubDate>Mon, 20 May 2019 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.cn/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.cn/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.cn/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.cn/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.cn/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.cn/wechat/articles/2019/05/2019-05-15-gsoc-annoncement/</link>
      <pubDate>Wed, 15 May 2019 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.cn/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.cn/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.cn/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.cn/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.cn/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.cn/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.cn/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.cn/wechat/articles/2019/05/2019-05-09-jenkins-release/</link>
      <pubDate>Thu, 09 May 2019 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.cn/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.cn/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.cn/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.cn/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.cn/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.cn/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.cn/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.cn/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.cn/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.cn/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.cn/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.cn/wechat/articles/2019/04/2019-04-28-devsecops/</link>
      <pubDate>Sun, 28 Apr 2019 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.cn/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.cn/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.cn/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.cn/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.cn/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.cn/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.cn/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.cn/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.cn/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.cn/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.cn/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.cn/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.cn/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.cn/wechat/articles/2019/04/2019-04-17-aiops/</link>
      <pubDate>Wed, 17 Apr 2019 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.cn/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.cn/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.cn/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.cn/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.cn/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.cn/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.cn/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.cn/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.cn/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.cn/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.cn/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.cn/wechat/articles/2019/03/2019-03-18-weekly-version/</link>
      <pubDate>Wed, 20 Mar 2019 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.cn/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.cn/wechat/articles/2019/03/2019-03-20-cdf-launch/</link>
      <pubDate>Wed, 20 Mar 2019 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.cn/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.cn/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.cn/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.cn/wechat/articles/2019/03/2019-03-13-gsoc2019-announcement/</link>
      <pubDate>Wed, 13 Mar 2019 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.cn/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.cn/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.cn/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.cn/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.cn/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.cn/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.cn/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.cn/wechat/articles/2019/02/2019-02-27-contribution-inspire/</link>
      <pubDate>Wed, 27 Feb 2019 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.cn/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.cn/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.cn/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.cn/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.cn/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>2018年 Jenkins 国内使用情况调查问卷</title>
      <link>https://jenkins-zh.cn/wechat/articles/2018/12/2018-12-19-Jenkins-survey/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.cn/wechat/articles/2018/12/2018-12-19-Jenkins-survey/</guid>
      <description>近年来，在数字化转型的压力之下，以 DevOps 和微服务为代表的云原生技术，作为企业数字化转型的重要支撑，活跃于开源技术的舞台。 而 DevOps 作为一种理念，落地交付必然离不开 CI/CD 等工具的支持。 Jenkins 在此方面的重要作用，相信大家也是有目共睹。Jenkins 之所以深受国内用户的喜爱，不仅因为它开源免费、功能强大、插件众多，其背后社区的开放、包容和活跃，更是其生命力之所在！
在新的一年里， Jenkins 社区希望能够更好地推广和传播这项技术，使越来越多的 Jenkins 中文用户能在实际工作中体会它的魅力。正因如此，我们发起了 “2018年 Jenkins 国内使用情况调查问卷”，希望通过这份问卷的互动，我们能够更加清晰 Jenkins 社区2019年的发展方向。
请扫一扫下面的二维码，或者在微信中长按识别，完成下面的问卷。只需要占用您大概1～2分钟的时间。
问卷有效时间，从 2018年12月19日 到 2019年1月9日 截止。
另外，还有两则好消息与大家分享。
第一则好消息是 Jenkins 中文站点已经正式上线，大家可以在上面找到入门教程、使用案例以及优秀的技术博客，我们会不断完善相关文档和教程。当然，无论是贡献文档、代码，还是其他任何形式的贡献，非常欢迎大家参与其中。从来没有参与过开源项目的朋友也不用担心，可以通过微信公众号留言给我们，志同道合的小伙伴们会主动与你联系，助你一同踏入精彩的开源世界。
另一则好消息是我们将通过此官方微信公众号，陆续推出 Jenkins 相关系列视频，由浅入深地为使用者们介绍 Jenkins 相关知识及使用经验。对于“如何构建特定语言的项目”、“如何在 Kubernetes 集群中更好地利用 Jenkins ”以及“如何排查问题”等大家感兴趣的热门话题，都可以从这些视频中得到经验分享。
最后，欢迎订阅 Jenkins 中文邮件组与我们进行交流和互动。衷心希望能够通过更多小伙伴的加入，不断完善开源社区氛围，深度技术互动，协力共建一个更加开放、更加包容、更加活跃的 Jenkins 社区！
有内容、有态度的 Jenkins 社区，期待有你同行！</description>
    </item>
    
    <item>
      <title>Custom WAR Packager</title>
      <link>https://jenkins-zh.cn/wechat/articles/2018/12/2018-12-5-custom-war-packager/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.cn/wechat/articles/2018/12/2018-12-5-custom-war-packager/</guid>
      <description>我打算给 Jenkins 管理员和开发者介绍一个新的工具 Custom WAR Packager。该工具可以打包 Jenkins 的自定义 WAR 发行版、 Docker 镜像和 Jenkinsfile Runner 包。 它可以打包 Jenkins、插件以及配置为开箱即用的发行版。 Custom WAR Packager 是我们在博客 A Cloud Native Jenkins(/blog/2018/09/12/speaker-blog-a-cloud-native-jenkins/) 中介绍过的无状态 Jenkins master 工具链的一部分。这个工具链已经在 Jenkins X 中被使用，用于构建 serverless 镜像(https://github.com/jenkins-x/jenkins-x-serverless)。
在这篇文章中，我将会介绍几种 Custom WAR Packager 常见的使用场景。
== 历史
正如 Jenkins 本身一样，Custom WAR Packager 开始于一个小的开发工具。在 Jenkins 内运行集成测试很长时间以来都是一个难题。 对此，我们有三个主要的框架： Jenkins Test Harness, Acceptance Test Harness, 和 Plugin Compatibility Tester. 这些框架都需要一个 Jenkins WAR 文件来运行测试。但是假如你想在类似 AWS 一样的自定义环境中进行 Jenkins 测试呢？ 或者，你希望基于 Pluggable Storage 的环境也可以复用 Jenkins 流水线测试，来确保没有回归缺陷？</description>
    </item>
    
    <item>
      <title>Docker Hub 上的官方 Jenkins 镜像</title>
      <link>https://jenkins-zh.cn/wechat/articles/2018/12/2018-12-26-official-docker-image/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.cn/wechat/articles/2018/12/2018-12-26-official-docker-image/</guid>
      <description>目前，在 Docker Hub 上有三个不同的仓库正（或曾经）被当作“官方” Jenkins 镜像。 本文是为了申明哪个是当前的官方镜像(截至2018年12月).
官方的 docker pull jenkins/jenkins
例如：https://hub.docker.com/r/jenkins/jenkins/ 是正确的仓库。
在我的博客 对于使用 Jenkins 官方 Docker 镜像推荐的方法 上也有一些记录。
废弃的 jenkins 已经废弃了很久。 我们停止使用和更新该镜像的简短原因是，我们每次发版时都需要人工参与。 jenkinsci/jenkins 同样已经废弃了很久，但为了过渡，我们会同时更新 jenkins/jenkins（正确的那个） 和 jenkinsci/jenkins。 2018年12月初，我们停止更新 jenkinsci/jenkins（如果您感兴趣的话，查看 INFRA-1934 可以获取更多详情）。
感谢您的阅读！</description>
    </item>
    
    <item>
      <title>Jenkins Configuration-as-Code: 看，我都不用手动配置</title>
      <link>https://jenkins-zh.cn/wechat/articles/2018/12/2018-12-12-gasc/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.cn/wechat/articles/2018/12/2018-12-12-gasc/</guid>
      <description>NOTE: 这篇文章是 Configuration-as-Code 系列的第一部分。
Jenkins 非常灵活，如今已成为实现 CI/CD 的事实标准，同时拥有一个活跃的社区来维护几乎所有工具和用例的插件。但是灵活也是要付出代价的：除了 Jenkins 核心之外，许多插件需要一些系统级别的设置才能正常工作。
在某些情况下，“Jenkins 管理员”是一个全职职位。 Jenkins 管理员在负责维护基础设施的同时，还要为一个巨大的 Jenkins master 提供数百个已安装的插件和数千个托管作业。 维护最新的插件版本是一项挑战，故障转移（failover）也会是一场噩梦。
这就像几年前系统管理员必须要为每个服务管理特定的机器一样。 在 2018 年，通过使用基础架构自动化工具和虚拟化，一切都可以作为代码进行管理。 需要一个新的应用服务器作为你的应用的暂存环境吗？那你只需要部署一个 Docker 容器。 基础设施缺少资源吗？那就在你喜欢的云服务上分配更多资源来使用 Terraform。
在这种情况下，Jenkins 管理员的角色怎么样？他们是否还要花费数小时来点击网页表单上的复选框？也许他们已经采用了一些自动化、依赖于 Groovy 脚本或一些自己写的 XML 模板。
今年早些时候我们发布了第一个 alpha 版本的 “Jenkins Configuration-as-Code” （JCasC），它是一种基于 YAML 配置文件和自动模型发现的 Jenkins 配置管理新方法。&amp;rdquo;JCasC&amp;rdquo; 已经升级为顶级 Jenkins 项目。 同时，对应的 Jenkins 增强提案已经被接受。
JCasC 能为 Jenkins 管理员做些什么？ JCasC 允许我们在启动时或通过 web UI 按需在 Jenkins master 上应用一组 YAML 文件。 与 Jenkins 用于实际储存配置的详细 XML 文件相比，这些配置文件非常简洁易读。 这些文件还有用户友好的命名约定，使管理员能够轻松地配置所有 Jenkins 组件。</description>
    </item>
    
    <item>
      <title>Jenkins 中文社区邀您来上海共同参与2019年的国际开源盛宴</title>
      <link>https://jenkins-zh.cn/wechat/articles/2019/04/2019-04-15-kubecon-cn/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.cn/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.cn/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.cn/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.cn/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.cn/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>Jenkins 微信订阅号</title>
      <link>https://jenkins-zh.cn/wechat/articles/2018/11/2018-11-14-first-voice/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.cn/wechat/articles/2018/11/2018-11-14-first-voice/</guid>
      <description>Jenkins 作为 CI/CD 领域里非常有实力和生命力的平台，不但在国外有很多用户，在国内也有很多的拥趸者。大家拥抱 Jenkins，不仅仅因为它是新的方向，更因为这背后有着一个非常开放、活跃的开源社区。
为了使更多的 Jenkins 中文用户，能够及时、准确地获得来自官方的最新动态，经过社区贡献者的讨论，大家一致认为，开通 Jenkins 微信订阅号是非常必要也非常有意义的一件事情。同时，Jenkins 的创始人 Kohsuke Kawaguchi 先生对这个想法非常认同，他亲自签名并授权，对我们创建 Jenkins 微信订阅号提供了巨大的支持和鼓励。
于是，Jenkins 微信订阅号便在今天，正式与您见面了。
随着 Jenkins 订阅号的开通，我们将有更加直接的平台来与各位分享社区目前在做的一些事情。在这之前，我们早已着手进行 Jenkins 中文本地化的相关工作。目前社区贡献者主要在做的事情包括：创办并维护 Jenkins 以及 Jenkins X 的中文官网、Jenkins Core 以及插件的本地化等。
如果您愿意和其他 Jenkins 用户进行线下面对面的交流和分享，Jenkins Area Meetups（后文简称“JAM”） 将会是一个不错的选择。目前，在社区贡献者和技术爱好者的共同努力下，我们已经在北京、深圳、西安等地成功举办过多次 JAM 活动。在 JAM 上，您除了可以体验到很多有关 Jenkins 的实际应用、最新特性之外，还可以结识社区里的朋友并进行深度互动。
Jenkins 社区贡献者们秉承传播 Jenkins 技术、加强互动交流、推动 Jenkins 中文本地化的理念，将在今后定期举办多种多样的线上线下活动。我们尊重任何形式、任何规模的贡献，并热忱地欢迎新贡献者的加⼊，也欢迎您联系我们来分享您的心得、体会，或者共同举办一次 JAM 活动。Jenkins 官网对如何参与有更加详细的说明，有任何问题，欢迎大家留言给我们。
我们衷心希望，随着 Jenkins 订阅号的开通，能够与更多的小伙伴们一同在线上完善开源社区氛围、线下深度互动，努力构建一个有内容、有态度的优质技术社区。</description>
    </item>
    
    <item>
      <title>Jenkins 的重要安全更新</title>
      <link>https://jenkins-zh.cn/wechat/articles/2018/12/2018-12-26-security-updates/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.cn/wechat/articles/2018/12/2018-12-26-security-updates/</guid>
      <description>我们刚刚发布了版本 2.154 和 LTS 2.150.1 的 Jenkins 安全更新，修复了多个安全漏洞。 由于 2.150.1 是新的 LTS 中的第一个版本，而且，我们还发布了上一个 LTS 2.138.4 版本的安全更新。 这使得管理员们可以安装今天的安全修复，而不必立即升级到新的 LTS 版本。
查看 link:/security/advisory/2018-12-05[安全报告]，了解有哪些被修复。 查看我们的 link:/doc/upgrade-guide/2.138/#upgrading-to-jenkins-lts-2-138-4[LTS 2.138.4 升级指导]，了解影响范围。
当前修复中有关之前发布变更的部分 在八月和十月份的 Jenkins 核心安全更新中，包括一项改进，可以通过设置多个系统属性来禁用。 那些变更是 SECURITY-595 修复的重要部分，因此，我们强烈建议禁用。而且，之前发布的文档已更新。</description>
    </item>
    
    <item>
      <title>Windows 安装程序更新</title>
      <link>https://jenkins-zh.cn/wechat/articles/2019/02/2019-02-27-windows-installers/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.cn/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.cn/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.cn/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>从 Jenkins Master 扩展网络连接</title>
      <link>https://jenkins-zh.cn/wechat/articles/2018/12/2018-12-19-scaling-network-connections/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.cn/wechat/articles/2018/12/2018-12-19-scaling-network-connections/</guid>
      <description>Oleg Nenashev 和我今年将在旧金山的 DevOps World | Jenkins World 上，做从 Jenkins Master 扩展网络连接 的演讲。 多年来，我们一直致力于分析、优化和加强 Remoting channel， 才有了现如今 master 能够协调 agent 的活动，并且接收构建的结果。 尽管许多技术可以改进服务，比如优化代理启动器，但是想要有质的改变，只有从根本上改变传播的内容和方式。
3月，JENKINS-27035 引入了一个框架，用于检查 Remoting channel 在高级别上的通信。 以前，开发人员只能使用一般的低级工具，例如 Wireshark， 它不能精确的识别 Jenkins 负责通信的代码片段。
在过去的几个月里，Cloud Native SIG 在解决根本原因方面取得了进展。 Artifact Manager on S3 plugin 已经发布并与 Jenkins Evergreen 整合， 支持在 agent 和 Amazon 服务器之间，进行大制品的上传和下载， 源生插件允许由 agent 生成的所有构建的日志内容（例如在 steps 的 sh 中） 直接定向流到外部存储服务，如 AWS CloudWatch Logs。 与此同时也开始上传 junit 格式的测试结果，这些测试结果有时会变的很大，将直接从 agent 到存储数据库。 所有这些努力都可以减轻 Jenkins Master 和本地网络的负载，而不需要开发人员修改他们的 pipeline 脚本。</description>
    </item>
    
    <item>
      <title>使用 YAML 文件配置 Jenkins 流水线</title>
      <link>https://jenkins-zh.cn/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.cn/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>回顾 2018: 革新的一年</title>
      <link>https://jenkins-zh.cn/wechat/articles/2018/12/2018-12-25-year-in-review/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.cn/wechat/articles/2018/12/2018-12-25-year-in-review/</guid>
      <description>临近年终，是一个思考总结、展望全局的好时机。那就让我们暂时从日常繁复的工作中停下脚步，一起来盘点 Jenkins 在 2018 这一年的得失与喜乐。
在整个行业中，对进一步自动化的不懈追求仍在继续。我们正以前所未有的速度编写软件，与此同时，对于软件的需求似乎越来越高，我觉得越来越多的企业和高管都敏锐地意识到软件和开发者已登基为王。在底层的角度，我遇到的每个团队都认为软件交付自动化是他们的“软件工厂”的关键部分，对这些团队而言，创建、管理具有不可思议的灵活性和可视性的自动化十分重要。
自诞生14年以来，Jenkins 将继续在实现这一目标上发挥重要作用，总之，增长的步伐似乎正在加速。在这个发展飞快的行业里，成为这一成就的一份子着实让我感到自豪。
把 Jenkins 打造为每个人都会使用的工具，这具有很大的责任感。所以在 Jenkins 社区，我们一直都十分努力。事实上，在各个领域和层面上来说，*2018年是整个项目历史上最具有创新性的一年*。
 随着不断发展壮大，我们亟需探索出能使更多人更好地参与其中的方法。JEPs 和 SIGs 便应运而生。2018年，我们看到了这些形式得到了巨大的吸引力。经过一年的运营，我认为我们已经学到了很多东西，希望我们会在此基础上继续改进。 这些新的形式带来了新的协作方式。例如：中文本地化 SIG运营的 微信公众号和本地化网站。平台 SIG 在 Java 11 support 中也给予了不少帮助。 我也很高兴看到新一批领导者。由于害怕遗漏一些人，所以我不打算在此一一列出，我们在今年秋天祝贺他们中的许多人作为 Jenkins 大使（请在明年提名更多人!）。那些领导关键工作的人往往是那些不熟悉这些角色的人。 一些领导者也努力发掘新的贡献者。我们正在有意识地思考，我们哪一部分的潜在贡献者没有被发掘出来，为什么没有被发掘出来。这也是任一个企业都在做的事情。同时我们也是 Google Summer of Code 和 Outreachy 参与者。 今年我们的安全流程和修复速度再次大幅提升，反映出用户对我们的信任也随之增强。例如，我们今年推出了遥测系统，通知我们更快地开发出更好的修复方案。  现在，社区改进的最重要的地方是我们为您使用的软件带来的影响。在这一方面，我认为我们在2018年做得不错，产生了我所谓的“五个超级武器”
 Jenkins X 可能是今年最明显的创新，使得在 Kubernetes 上创建现代云应用程序变得更加容易。这也标志着 Jenkins 社区及其使命的重大扩展。 Jenkins Configuration as Code 在今年达到了一重要的里程碑 &amp;ldquo;1.0&amp;rdquo; ，并且他继续获得更大的动力。 &amp;ldquo;Cloud Native Jenkins&amp;rdquo; 是我为新努力作的术语，把 Jenkins 转换为 Kubernetes 上大规模运行的通用 CI/CD 引擎。这里还有许多东西需要定义，但你已经可以看到如 Serverless Jenkins 这样的好东西了。 Evergreen 是另一个需要推出的新项目，它有着雄心勃勃的主题——大量地简化了 Jenkins 的使用和操作。 流水线方面的努力形成了一个新的 SIG，我期待它在2019年带来的新影响。  Jenkins 社区能够将用户可见的改变与社区的改进结合在一起，这不仅是不算秘密的秘密，也是社区不断发展的能力。 展望2019年，毫无疑问，随着我们不断地学习和实践，上述提到的事情将不断地发展、变化、融合和分裂。</description>
    </item>
    
    <item>
      <title>在 VS Code 中校验 Jenkinsfile</title>
      <link>https://jenkins-zh.cn/wechat/articles/2018/11/2018-11-21-validate-jenkinsfile/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.cn/wechat/articles/2018/11/2018-11-21-validate-jenkinsfile/</guid>
      <description>在日常工作中，我经常需要创建或修改很多 Jenkinsfile，有时还会发生错误。这是一个非常繁琐的流程——修改 Jenkinsfile，提交、推送，然后等 Jenkins 提醒你少加了一个括号。
Command-line Pipeline Linter(https://jenkins.io/doc/book/pipeline/development/) 可以有效地减少编写 Jenkinsfile 所需要的调试时间，但是它也有一些不方便的地方。你需要使用像 curl 或 ssh 的工具来连接你的 Jenkins，还需要正确地记住验证 Jenkinsfile 的命令。尽管如此，对我来说，这个方案还是不尽如人意。
鉴于每天都会使用 VS Code，于是我开始着手为此研发插件，使得校验 Jenkinsfile 变得更加友好。
Jenkins Pipeline Linter Connector 的作用就是，把当前打开的文件推送到你的 Jenkins，然后在 VS Code 中显示校验结果。
你可以在 VS Code 插件浏览器中或通过下面的地址找到该插件 https://marketplace.visualstudio.com/items?itemName=janjoerke.jenkins-pipeline-linter-connector 。
该插件会在 VS Code 中添加四个配置选项，你必须要使用这些选项来配置用于验证的 Jenkins。
 jenkins.pipeline.linter.connector.url 是 Jenkins 期望的 POST 请求地址，包含你要校验的 Jenkinsfile 文件。通常为 *http:///pipeline-model-converter/validate*。 jenkins.pipeline.linter.connector.user 允许指定你的 Jenkins 用户名。 jenkins.pipeline.linter.connector.pass 允许指定你的 Jenkins 密码。 jenkins.pipeline.linter.connector.crumbUrl 当你的 Jenkins 启用了 CRSF 时必须指定。通常为 *http:///crumbIssuer/api/xml?xpath=concat(//crumbRequestField,%22:%22,//crumb)*。 ​  </description>
    </item>
    
    <item>
      <title>在安全防火墙内通过 WebHook 触发构建</title>
      <link>https://jenkins-zh.cn/wechat/articles/2019/01/2019-01-16-webhook-firewalls/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.cn/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.cn/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.cn/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.cn/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.cn/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.cn/wechat/articles/2019/01/2019-01-09-jenkins-evergreen/</link>
      <pubDate>Mon, 01 Jan 0001 00:00:00 +0000</pubDate>
      
      <guid>https://jenkins-zh.cn/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>