DevOps 已经走了很长一段路，毫无疑问，它将在今年继续发光。由于许多公司都在寻求有关数字化转型的最佳实践，因此重要的是要了解领导者认为行业发展的方向。从这个意义上讲，以下文章是 DevOps 领导者对 DevOps 趋势的回应的集合，需要在 2021 年关注。

让我们看看他们每个人对来年的 DevOps 有何评价。

1. 迁移到微服务将成为必须 —— Wipro Limited 首席 DevOps 工程师

“从整体迁移到微服务和容器化架构对于所有公司的数字化转型之旅都是必不可少的，它不再是一个选择或选项。这就是Kubernetes 的采用率将上升的地方，当组织迁移到多重云时，Terraform 将成为实现基础架构自动化的最终选择。”

2. Hybrid将成为部署规范 —— JFrog 开发人员关系 VP

“2020年将加速远程工作，加快向云的迁移，并将 DevOps 从最佳实践转变为每个业务的重要组成部分。随着我们进入2021年，该行业将在多个方面拥抱Hybrid。首先，企业将完全采用混合型劳动力，将远程工作和现场团队协作的优势相结合。 其次，商业模式将变得混合，例如将虚拟规模与本地网络合并的会议。最终，随着公司对堆栈进行现代化以利用云原生技术的优势，混合将成为部署规范，但要意识到并非所有事物都可以迁移到外部。2021年的赢家将是拥抱业务，模型和产品混合的公司。”

3. DataOps将蓬勃发展 - 乐天高级 DevOps 工程师

“DataOps 肯定会在 2021 年蓬勃发展，COVID 可能会在其中发挥作用。由于 COVID 和 WFH 的情况，数字内容的消费量猛增，这要求自动缩放和自我修复系统的自动化达到新水平，以满足增长和需求。

到目前为止，DevOps 设置的系统仅用于日志记录，监视和警报（ELK/EFK 堆栈，Prometheus/Grafana/Alertmanager等）。现在，DevOps 现在应该加强并使用可用数据和指标来 产生有价值的见解，学习并应用机器学习模型来预测事件或中断，开发从数据中学习自身并预测能力的自动化以改进预算计划。许多人已经开始对此部分调用 MLOps/AIOps。”

4. 弹性测试将成为主流 —— Neotys 产品负责人

从我的角度来看，可观察性，性能测试和弹性测试之间的交叉点将成为主流。 随着 AWS 和 Google 等 WW 领导者最近发布的 Ops 问题，以及各个领域的数字化转型都在加速发展，市场将逐渐意识到，公共或私有云形式提供的无限可扩展性是不够的。” - Neotys 产品负责人 Patrick Wolf

5. GitOps 将成为常态 —— 梅西百货的首席架构师

“一个“构建，拥有，拥有”的开发过程需要开发人员知道和理解的工具。GitOps 是 DevOps 如何使用开发人员工具来驱动操作的名称。

GitOps 是一种进行持续交付的方法。 更具体地说，它是用于构建统一部署，监视和管理的 Cloud Native 应用程序的操作模型。 它通过将 Git 用作声明性基础结构和应用程序的真实来源来工作。 当在 Git 中推送和批准提交时，自动化的 CI/CD 管道将对你的基础架构进行更改。它还利用差异工具将实际生产状态与源代码控制下的生产状态进行比较，并在出现差异时提醒你。GitOps 的最终目标是加快开发速度，以便你的团队可以安全可靠地对 Kubernetes 中运行的复杂应用程序进行更改和更新。” -梅西百货（Macy’s）首席建筑师 Soumen Sarkar

6. 将会有更多的迁移到无服务器 —— ADP Lifion 的站点 SRE 经理

“2021 年将是注视更多迁移到无服务器的一年。如果容器和业务流程是 Z 代.. 那么无服务器的实时负载将是 Gen+ .. 仅在你使用时使用和付款可能看起来是一样的.. 但请考虑运行基于 k8s pod 的微服务，以便在需要时在无服务器上运行相同的服务。” - ADP Lifion 网站可靠性工程经理 Shivaramakrishnan G

7. NoOps 出现 —— ClickIT Smart Technologies 的 CEO

“我希望出现更多托管服务，并减少我们的 DevOps 运营并减少客户的运营支出。更多无服务器应用程序，更多无服务器服务，例如 Aurora 无服务器，Fargate，Amazon S3 和无服务器静态网站。数据中心中的 Amazon ECS/EKS（新版本 re：invent 2020）以及云管理服务，可让你减少数据中心的维护和开发。同样，将更多云原生的原理和功能移植到数据中心，例如。亲戚。” - ClickIT Smart Technologies 首席执行官 Alfonso Valdes

8. BizDevOps 将大放异彩 —— Petco 的 DevOps 经理

“在架构和公司层次结构方面朝着成本优化的方向发展-随着业务的发展，DevOps 的价值不断提高。

专注于灵活的，云原生的架构和工具，这些功能一旦具备了“大佬”的能力，就可以打包成小型企业使用的包装（Snowflake 或 Hazelcast 与 Oracle/Teradata）

FaaS 才刚刚起步（无服务器，Lambda 等）- 运营问题正在得到解决，人们正在意识到潜力。”

9. 基础设施即代码（IaC）的地位将更高 —— 沃尔沃高级解决方案架构师

“基础架构即代码（IaC）：云中 DevOps 的核心原则。你的基础架构本地或云中的服务器，网络和存储设备（定义为代码）。这使公司可以自动化并简化其基础架构。 IaC 还提供了一个简单的基础结构版本控制系统，该系统可让团队在发生灾难性故障时回退到“有效的最后配置”。这意味着可以快速恢复并减少停机时间。”

10. 自动化和混乱工程变得非常重要 —— 直布罗陀印度开发中心的集团开发经理

“一切都是自动化的-构建，部署，测试，基础架构和发布。

具有所需质量门的生产线。更快，可重复，可自定义和可靠的自动化是任何项目成功的关键。混沌工程-在当今混合基础设施世界中非常关键的方面。系统行为和客户体验紧密结合在一起，你越早对其进行测试，就越能为客户提供更好的体验。”

11. 云原生方法将被标准化 —— Ben Sapp

“由于云空间已经真正地发展起来（最近十年左右），并且容器化已成为规范，所以一切都非常标准化，几乎就像大型机时代一样。

当然，会有趋势和赚钱的机会。但是我不知道下一个大破坏者是什么。现在的一切基本上都与五年前的最佳做法相同，但更加可靠。我想越来越多的人将继续从宠物转移到牛身上，剩下诸如 Ansible 和 puppet 之类的工具仅用于打包程序和云 init 来构建容器主机。

imo 是软件开发的黄金时代。 DevOps 和云原生方法已经实现了许多目标。管道，托管，存储，负载平衡……这些都在 5 分钟之内解决了。”

12. 安全将成为重中之重 —— CloudSkiff

“从 DevSecOps 角度绝对跟踪基础设施中不受控制的变化。作为代码的基础架构很棒，但是有太多可移动的部分：代码库，状态文件，实际云状态。事情倾向于漂移。这些更改可能有多种原因：从开发人员通过 Web 控制台创建或更新基础架构而不告知任何人，到云提供商方面不受控制的更新。处理基础架构漂移与代码库之间的挑战可能会充满挑战。” - CloudSkiff

13. Chaos Engineering 将变得越来越重要 —— International Technology Ventures 的 CTO

“在更多组织中的 DevOps 规划讨论中，混沌工程将变得越来越重要（且更常见）。大多数组织通常不执行混沌工程学（Chaos Engineering），即在生产中对软件系统进行实验以建立对系统抵御动荡和意外情况能力的信心。

如果我们在传统的五个成熟度模型框架内考虑 DevOps，那么 Chaos Engineering 将是第 4 或第 5 级学科，将包含在 DevOps 实践的保护范围内。正如将单独的测试/质量保证小组的传统角色纳入 DevOops 的学科一样，Chaos Engineering 也应如此。”

14. 更关注即时日志以快速验证成功或失败 —— ADESA 平台稳定性总监

“在后期部署中使用日志来验证发布是否成功，或存在严重错误。人们需要建立的最大联系是定义手动流程，然后实现自动化的巨大飞跃。一键部署，即时日志可快速验证成功或失败，然后触发回滚。随之而来的是复杂性以及跨服务依赖性，是否可以回滚某些内容，或者是否需要对其他服务进行进一步测试。想象一下 100 种微服务（又称管道，甚至还有 100 个容器）。

作为一项，我总是庆祝成功的回滚，因为它不会对服务产生影响，而且是成功的。” -ADESA平台稳定性总监Craig Schultz

15. DevSecOps 将成为 DevOps 的默认部分 —— JFrog 的 DevOps 架构师

DevSecOps 的 “Sec” 部分将越来越成为软件开发生命周期中不可或缺的一部分，真正的安全性 “向左移动” 方法将成为新的规范，CI/CD 管道中的专用安全性步骤将更少从开发人员的 IDE 到依赖关系和静态代码分析，安全和自动识别和采取措施将是所有流程步骤的一部分。在没有适当（自动？）解决这些问题的情况下，不会发布软件组件。真正的安全问题是免费软件。”

希望你喜欢我们对 DevOps 趋势的专家综述，并在 2021 年关注。如果你认为这里缺少应考虑的内容，请在评论中分享你的观点。

原文 15 DevOps Trends to Expect in 2021 的翻译。

This is just a note to myself about the difference between Jenkins result and currentResult.

Declarative Pipeline

Here is a test code from this ticket JENKINS-46325

pipeline {
    agent any
    stages {
        stage ('Init') {
            steps {
                echo "Init result: ${currentBuild.result}"
                echo "Init currentResult: ${currentBuild.currentResult}"
            }
            post {
                always {
                    echo "Post-Init result: ${currentBuild.result}"
                    echo "Post-Init currentResult: ${currentBuild.currentResult}"
                }
            }
        }
        stage ('Build') {
            steps {
                echo "During Build result: ${currentBuild.result}"
                echo "During Build currentResult: ${currentBuild.currentResult}"
                sh 'exit 1'
            }
            post {
                always {
                    echo "Post-Build result: ${currentBuild.result}"
                    echo "Post-Build currentResult: ${currentBuild.currentResult}"
                }
            }
        }
    }
    post {
        always {
            echo "Pipeline result: ${currentBuild.result}"
            echo "Pipeline currentResult: ${currentBuild.currentResult}"
        }
    }
}

Output

Init result: null
Init currentResult: SUCCESS
Post-Init result: null
Post-Init currentResult: SUCCESS
During Build result: null
During Build currentResult: SUCCESS
[test-pipeline] Running shell script
+ exit 1
Post-Build result: FAILURE
Post-Build currentResult: FAILURE
Pipeline result: FAILURE
Pipeline currentResult: FAILURE
ERROR: script returned exit code 1
Finished: FAILURE

Scripted Pipeline

Here is a test code from cloudbees support case

Example that forces a failure then prints result:

node {
    try {
        // do something that fails
        sh "exit 1"
        currentBuild.result = 'SUCCESS'
    } catch (Exception err) {
        currentBuild.result = 'FAILURE'
    }
    echo "RESULT: ${currentBuild.result}"
}

Output:

Started by user anonymous
[Pipeline] Allocate node : Start
Running on master in /tmp/example/workspace/test
[Pipeline] node {
[Pipeline] sh
[test] Running shell script
+ exit 1
[Pipeline] echo
RESULT: FAILURE
[Pipeline] } //node
[Pipeline] Allocate node : End
[Pipeline] End of Pipeline
Finished: FAILURE

Example that doesn’t fail then prints result:

node {
    try {
        // do something that does not fail
        echo "Im not going to fail"
        currentBuild.result = 'SUCCESS'
    } catch (Exception err) {
        currentBuild.result = 'FAILURE'
    }
    echo "RESULT: ${currentBuild.result}"
}

Output:

Started by user anonymous
[Pipeline] Allocate node : Start
Running on master in /tmp/example/workspace/test
[Pipeline] node {
[Pipeline] echo
Im not going to fail
[Pipeline] echo
RESULT: SUCCESS
[Pipeline] } //node
[Pipeline] Allocate node : End
[Pipeline] End of Pipeline
Finished: SUCCESS

As I have management our team’s git repositories for more than two years, and as my daily work using Bitbucket, so I’ll take it as an example.

Here are some settings recommend you to enable.

1. Set Reject Force Push
2. Set Branch Prevent deletion
3. Set tags for each hotfix/GA releases
4. Merge Check -> Minimum approvals (1)
5. Yet Another Commit Checker

Reject Force Push

This is the first setting I highly recommend you/your team to open it. if not, when someone using the git push -f command to the git repository, you may lost commits if his local code is old then remote repository.

you have to recover the lost commits manually, I have heard 3 times around me. so enable the hook: Reject Force Push ASAP!

Set Branch Prevent deletion

If some branch is very important, you don’t want to lost it, set Branch Prevent deletion ASAP!

Set tags for each hotfix/GA releases

For each hotfix/GA release, highly recommend create tags after release.

Merge Check

Pull Request is a very good workflow process for each team. in case of commits were merged directly without review, we enable Minimum approvals (1).

So, every branch wants to be merged to the main branch MUST add a reviewer (not allow yourself) and the review must click the Approve button otherwise the merge button is disabled.

Yet Another Commit Checker

This is a very powerful feature. it helps to standardize commit messages and create a branch.

More details about this tool you can refer to this introduction

I have a Chinese article to describe how to use Yet Another Commit Checker implement. if you interest it, you can see the post here

Recently our Bamboo server has an error when connecting to the Windows build system.

Some errors like: Can not connect to the host XXXX 22 port.

I log into the build machine find port 22 with the below command

netstat -aon|findstr "22"

but not found port 22 is inbound.

Inbound port 22

There’s a lot of articles will tell you how to open ports on Windows. see this one

https://www.windowscentral.com/how-open-port-windows-firewall

But still not works for me

My problem is when I inbound port 22, execute the above command still can’t see the port 22 is listening.

So I install the Win32-OpenSSH, this will lanch two services, then port 22 is listening.

Here are the wiki page about download and installation https://github.com/PowerShell/Win32-OpenSSH/wiki/Install-Win32-OpenSSH

This post just a note to myself and it works on my environment. it has not been widely tested.

Enable git sparse-checkout

Just in my case, I cloned a git repo exists problems on the Windows platform with some folder, in order to work on the Windows platform we get a work around solution as following:

Case 1: when you not already cloned a repository

mkdir git-src
cd git-src
git init
git config core.sparseCheckout true
echo "/assets/" >> .git/info/sparse-checkout
git remote add origin git@github.com:shenxianpeng/shenxianpeng.git
git fetch
git checkout master

Case 2: when you already cloned a repository

cd git-src
git config core.sparseCheckout true
echo "/assets/" >> .git/info/sparse-checkout
rm -rf <other-file/folder-you-dont-need>
git checkout

Disable git sparse-checkout

git config core.sparseCheckout false
git read-tree --empty
git reset --hard

相信许多程序员在新年开始在做 code sign (数字签名)的时候可能遇到 Verisign Timestamp 服务器不好用了 http://timestamp.verisign.com/scripts/timstamp.dll 的情况。出现了如下错误：

原因是 code sign 默认的时间戳服务器无法访问了。

在 Stack overflow 这个 post 里上面有人给出了答案，是来自于 Verisign Support 的回复：

他们的身份验证服务已出售给赛门铁克(Symante)，现在的服务商是 Digicert。该服务器已弃用了。

他们建议联系 Digicert 或在网络上找免费的 timestamp servers

以上是别人的回复，我在网络上没有找到一个官方回复，因此打算发邮件正式确认一下，发完不一会就得到了回复：

和上面的回复类似：几年前，Verisign 的身份验证和证书业务被出售给赛门铁克(Symantec)，目前已过渡到Digicert。您将需要与当前供应商合作以获得支持或更新的时间戳URL。请访问 http://www.digicert.com 了解更多信息。

好了，这下实锤了，放心大胆的开始动手修改到新的时间戳了。

我找到了 Digicert 的时间戳服务器是 http://timestamp.digicert.com。更换到新的时间戳服务器后，数字签名恢复正常。

除了上面 Digicert 那个网址，还有如下网址可以作为替换:

• http://timestamp.comodoca.com/authenticode
• http://timestamp.globalsign.com/scripts/timestamp.dll
• http://tsa.starfieldtech.com

但我都没有选用，我还是选择了官方的时间戳服务，留作备用吧。一旦又抽风 “官方” 哪天又被卖了呢？

前言

自 2020 年因疫情开始，越来越多的 IT 公司都因不得不在家办公从而彻底转为 WFH（Work From Home） 公司，因此对于 IT 从业者来说，工作机会今后将会是全球性的。

如果你有意想进入一个跨国公司工作，想与世界各地的人在一起工作，那么就不能仅仅的关注国内的这些大厂，要将眼光放眼到全世界，看看这些耳熟能详的公司对于工程师的职位要求有哪些。

今天就先来看看 DevOps 岗位的需求是什么样的，了解这些，一来可以帮助我们在2021 年树立学习方向，而来如果你有意向去这些公司，了解并提早做准备才能有机会获取你想要的岗位。

由于这些职位的介绍和要求会很长，因此我就先说结论。

主要技能

• 国外很多公司他们使用的云服务商主要是 AWS，因此熟悉和使用 AWS
• 熟练使用 DevOps 工具，如 Jenkins, Ansible（Chef）, Git 等
• Docker 和 Kubernetes 是每个想从事 DevOps 需要掌握的
• 熟悉操作系统，至少要 Linux
• 大多数都是要求 Python 很熟练，高级一些的岗位会要求熟悉 Go, Java 语言
• 最后，乐于学习，积极主动，具有创造性思维是每个 DevOps 最重要的特质，因此新的技术和工具层出不穷，我们需要保持和新进同行

具体的职位要求细节，请看后面的职位介绍吧 …

Read More

时间飞快，马上就迎来了 2021 年，又到了总结自己这一年来的所有的经历和收获的时候了。

2020 是非比寻常的一年，对于每个人不论是生活还是工作，都因为新冠病毒被影响着。

但生活总归要继续。刷微博、抖音各种社交媒体是一天；工作学习也是一天。我是那种一段时间感觉没进步就特别恐慌的人，做完后者总会让我感觉更安心一些。

回顾 2020

关于工作

对于 2020 年，我一直努力想要去做到最好，年尾回头看看，还算满意吧。

在年底写下工作工作总结的时候，发现自己这一年确实做了很多工作。除了做好构建和发布的本职工作之外，做了很多改进流程和提高效率工作，捡一些重要的来说：

• 通过 Jenkins Shared Libraries 和 Multi-branch Pipeline 完成了无人值守的自动化构建，为团队和我节省了大量的时间；同时也通过验证 PR 构建和测试，提高签入代码的稳定和质量。

  输出文章 每个 Jenkins 用户都应该知道这三个最佳实践

• 推动团队迁移到企业级的 Artifactory 来下载和存储构建，从而改进 CI/CD 的效率和无人值守的能力。为更好的自动化下载、安装、测试等提供方便。

  输出文章 写给那些想使用 JFrog Artifactory 管理制品的人

• 使用 Python 来做了很多关于 Jira, BitBucket 的集成，通过自动化提高效率。另外还发布了一个 Python 项目 UOPY。

  输出文章 在 GitHub 上发布一个 Python 项目需要注意哪些

• 落地了 Git 提交信息和分支创建规范，统一了 Git 提交信息和分支创建规范。

  输出文章 程序员自我修养之Git提交信息和分支创建规范

• 学习和使用了一些新工具，比如 Ansible playbook、ELK、JaCoCo 等并应用到项目中。

  输出文章 初识 Ansible，JaCoCo 实践

作为 DevOps/软件工程师还需要有良好的表达能力，否则你做的东西再好，但无法很清晰的跟同事及领导分享出来也是事倍功半。尤其像我在外企，还需要用英文去做分享。

另外，我想通过坚持阅读和实践，让自己在技术上有比较大的提高。有一段时间我坚持的比较好，完成了好几本技术书籍的阅读，但好的习惯就怕被打破，一旦被打破就很难坚持了。之前一般都是中午午休的时间会阅读半个小时以上的技术书，后来常常因为中午要去新房盯装修，加上每天要做的事情很多（工作、学英语、阅读、装修）的时候，很多时候往往是事情做了，但效果并没有达到预期。

分享上

2020 年博客上一共更新了 41 篇文章，在公众号『DevOps攻城狮』上面一共更新了 26 篇文章。

这个数量和质量跟一些其他的技术公众号真的没法比，但对于我个人：一个不以写作为生、只写原创文章的攻城狮，只要能不间断的输出，达到这个数量我已经比较满意了。

而且在年初有一个清华大学的编辑老师找到我，想让我出一本书，这真是让我受宠若惊。我知道自己几斤几两，但能够受到邀请，并寄给我合同，就已经是对我写作的最大鼓励了。

当时打算写一本《Jenkins 2实践指南》，如果签了合同，我就需要投入至少一年的业余时间死磕自己才有可能完成。

最后考虑到自己当时的状况：优先做好工作；其次还有比Jenkins更重要的技术我需要去学习；另外周末要装修等一系列的事情…我最终放弃了这个机会。

我知道自己还处在输入比输出更加迫切的阶段，我想只要心中的小火苗还在，但行好事，莫问前程。

工作 flag

对于个人年终总结，不仅可以回顾自己过去的一年做了哪些，哪些没做好，有什么可以改进的，还能通过回顾和总结为新年立一个 flag。

2021 我希望自己能更加专注，利用好时间，更加有效的工作和学习。

除了做好工作，最重要的是提高英语口语和深入学习技术，其次才是输出。

光有 flag 不行，还要落到具体的行动上。

提高英语口语

🚩 2021 继续坚持至少每天半小时口语打卡练习；另外每周一次 50 分钟的与外教的口语交流。希望能够脱稿进行英文分享，同时能通过英语托业考试。

深入学习技术

我现在学习技术的方式有这么几种：直接去官网阅读英文文档；如果读完还是没搞明白，就去 Linkedin Learning 或是 Udemy 上去搜相应的技术，不但学习了技术，同时也练习了英文听力；如果需要深入系统的去学习一门编程语言以及一些底层技术，会去读一些经典技术书籍。

🚩 2021 年坚持每天也至少半个小时来阅读技术，一个月至少读完一本技术书籍并且有输出。

生活 flag

生活上希望家人和朋友都能身体健康，生活幸福。

🚩 财务稳定，最好能增长；自己能够健康生活，减重 10 斤。

最后，不时的来回顾自己 2021 年的 flag，时不时的看看自己是否偏离了最初的方向。2021 我来了！

过去的年终总结

2019 年终总结
2018 从测试到开发的五个月

I believe most of you have used the Jenkins configuration as code principle, so you build/test/release process will be described in code.

It looks like all is good, but not all of the configuration is in code, same of the Jenkins system configuration is store in the Jenkins service, so we also need to backup Jenkins in case of any disaster.

There are two ways to backup Jenkins, one used Jenkins plugin, the other is create shell scripts.

Using plug-in backup

I used the ThinBackup plugin, here is my thinBackup configuration.

Read More

想要对 Java 项目进行代码覆盖率的测试，很容易就找到 JaCoCo 这个开源代码覆盖率分析工具是众多工具中最后欢迎的哪一个。

本篇仅仅是在学习 JaCoCo 时对其实现设计文档 https://www.jacoco.org/jacoco/trunk/doc/implementation.html 的粗略翻译。

实现设计(Implementation Design)

这是实现设计决策的一个无序列表，每个主题都试图遵循这样的结构:

• 问题陈述
• 建议的解决方案
• 选择和讨论

覆盖率分析机制(Coverage Analysis Mechanism)

覆盖率信息必须在运行时收集。为此，JaCoCo 创建原始类定义的插装版本，插装过程发生在加载类期间使用一个叫做 Java agents 动态地完成。

有几种收集覆盖率信息的不同方法。每种方法都有不同的实现技术。下面的图表给出了 JaCoCo 使用的技术的概述:

字节码插装非常快，可以用纯 Java 实现，并且可以与每个 Java VM 一起工作。可以将带有 Java 代理钩子的动态插装添加到 JVM 中，而无需对目标应用程序进行任何修改。

Java 代理钩子至少需要 1.5 个 JVMs。用调试信息(行号)编译的类文件允许突出显示源代码。不幸的是，一些 Java 语言结构被编译成字节代码，从而产生意外的突出显示结果，特别是在使用隐式生成的代码时（如缺省构造函数或 finally 语句的控制结构）。

Read More