Why need branching naming convention

To better manage the branches on Git(I sued Bitbucket), integration with CI tool, Artifactory, and automation will be more simple and clear.

For example, good unified partition naming can help the team easily find and integrate without special processing. Therefore, you should unify the partition naming rules for all repositories.

Branches naming convention

main branch naming

In general, the main’s branch names most like master or main.

Development branch naming

I would name my development branch just called develop.

Bugfix and feature branches naming

For Bitbucket, it has default types of branches for use, like bugfix/, feature/.
So my bugfix, feature combine with the Jira key together, such as bugfix/ABC-1234 or feature/ABC-2345.

Hotfix and release branches naming

For hotfix and release, my naming convention always like release/1.1.0, hotfix/1.1.0.HF1.

Other branches

Maybe your Jira task ticket you don’t want to make it in bugfix or feature, you can name it to start with task, so the branch name is task/ABC-3456.

If you have to provide diagnostic build to custom, you can name your branch diag/ABC-5678.

Summary

Anyway, having a unified branch naming convention is very important for implement CI/CD and your whole team.

Related Reading: Git Branch Strategy (Chinese)

Problem

When you do CI with JFrog Artifactory when you want to download the entire folder artifacts, but maybe your IT doesn’t enable this function, whatever some seasons.

You can try the below JFrog Artifactory API to know if you’re using Artifactory whether allowed to download the entire folder artifacts.

just visit this API URL: https://den-artifactory.company.com/artifactory/api/archive/download/team-generic-release-den/project/abc/main/?archiveType=zip

You will see an error message returned if the Artifactory is not allowed to download the entire folder.

{
  "errors": [
    {
      "status": 403,
      "message": "Download Folder functionality is disabled."
    }
  ]
}

More details about the API could find here Retrieve Folder or Repository Archive

Workaround

So to be enabled to download entire folder artifacts, I found other JFrog Artifactory APIs provide a workaround.

How to download the entire folder artifacts programmatically? this post will show you how to use other Artifactory REST API to get a workaround.

1. Get All Artifacts Created in Date Range

API URL: Artifacts Created in Date Range

This is the snippet code I use this API

# download.sh

USERNAME=$1
PASSWORD=$2
REPO=$3

# which day ago do you want to download
N_DAY_AGO=$4
# today
START_TIME=$(($(date --date="$N_DAY_AGO days ago" +%s%N)/1000000))
END_TIME=$(($(date +%s%N)/1000000))

ARTIFACTORY=https://den-artifactory.company.com/artifactory

if [ ! -x "`which sha1sum`" ]; then echo "You need to have the 'sha1sum' command in your path."; exit 1; fi

RESULTS=`curl -s -X GET -u $USERNAME:$PASSWORD "$ARTIFACTORY/api/search/creation?from=$START_TIME&to=$END_TIME&repos=$REPO" | grep uri | awk '{print $3}' | sed s'/.$//' | sed s'/.$//' | sed -r 's/^.{1}//'`
echo $RESULTS

for RESULT in $RESULTS ; do
    echo "fetching path from $RESULT"
    PATH_TO_FILE=`curl -s -X GET -u $USERNAME:$PASSWORD $RESULT | grep downloadUri | awk '{print $3}' | sed s'/.$//' | sed s'/.$//' | sed -r 's/^.{1}//'`

	echo "download file path $PATH_TO_FILE"
  curl -u $USERNAME:$PASSWORD -O $PATH_TO_FILE
done

Then you just use this as: sh download.sh ${USERNAME} ${PASSWORD} ${REPO_PATH} ${N_DAY_AGO}

2. Get all artifacts matching the given Ant path pattern

More about this API see: Pattern Search

Take an example screenshot of pattern search:

Then you can use Shell, Python language to get the file path from the response, then use curl -u $USERNAME:$PASSWORD -O $PATH_TO_FILE command to download the file one by one.

If you have better solutions, suggestions, or questions, you can leave a comment.

What’s the problem?

Today I am having a problem where the Windows installer I created is not installing, and the following Windows installer box pops up.

But it works well in the previous build, and I didn’t make any code changes. It is strange, actually fix this problem is very easy but not easy to find.

How to fix it?

In my case, I just remove the space from my build folder naming. I have made follow mistakes:

My previous build name is v2.2.2.3500-da121sa-Developer, but for this build, I named it to v2.2.2.3500-32jkjdk - Developer

How to find the solution?

This problem takes me several hours until I google this article which inspired me.

Just like the above article, if I try to use the command line msiexec.exe other-commands ..., compare with the works installer will also quick to find the root cause.

I realized it immediately I should try to remove the spaces from the build folder… Wow, the installer back to work.

If this happens to you, I hope it also works for you, and leave a comment if it works for you.

本文适用的是 Gradle 来构建和适用 JaCoCo。

分别介绍了 build.gradle 的文件配置，执行测试和生成报告，报告参数说明，以及如何忽略指定的包或类从而影响测试覆盖率的结果。

build.gradle 文件配置

比如使用 gradle 来管理的项目可以在 build.gradle 里添加如下代码

plugins {
    id 'jacoco'
}

jacoco {
    toolVersion = "0.8.5"
}

test {
    useJUnitPlatform()
    exclude '**/**IgnoreTest.class'  // 如果有 test case 不通过，如有必要可以通过这样忽略掉
    finalizedBy jacocoTestReport       // report is always generated after tests run
}

jacocoTestReport {
    dependsOn test // tests are required to run before generating the report
    reports {
        xml.enabled true
        csv.enabled false
        html.destination file("${buildDir}/reports/jacoco")
    }
}

执行测试，生成代码覆盖率报告

然后执行 gradle test 就可以了。之后可以可以在 build\reports\jacoco 目录下找到报告了。

重点是如何分析报告。打开 index.html，报告显示如下：

报告参数说明

Read More

Python 不必多说，它是众多编程语言中最容易学习的动态类型语言。它的跨平台、易读、易写、丰富的 Packages 等众多特性，也是众多DevOps/测试/开发工程师是最常用的语言之一。

相信不少人用它完成了很多工作，但你是不是仅仅止步于功能的实现而忽略了去写出更加简洁，优美的 Pythonic 代码呢？

在我最开始用 Python 时，我还不知道 Pythonic 这个词，直到多年前一位资深的程序员在给我培训的时候提到了项目中有一些代码不够 Pythonic，需要重构。根据语境，我理解他的意思：就是 Python 的代码没有按照 Python 的方式来写。

什么是 Pythonic

充分利用 Python 语言的特性来产生清晰、简洁和可维护的代码。Pythonic 的意思是指代码不仅仅是语法正确，而是遵循 Python 社区的惯例，并以其预期的方式使用该语言。

举例

以下是 C/C++ 程序员的一段代码:

int a = 1;
int b = 100;
int total_sum = 0;
while (b >= a) {
    total_sum += a;
    a++;
}

如果没有学习 Python 编程模式，那么将上面的代码改用 Python 来写可能会是这样：

a = 1
b = 100
total_sum = 0
while b >= a:
    total_sum += a
    a += 1

如果用 Pythonic 的方式来写，应该是这样的：

total_sum = sum(range(1, 101))

再举个常见的例子，如果用 Java 可能是这样写出来一个 For 循环

for(int index=0; index < items.length; index++) {
    items[index].performAction();
}

在 Python中，使用以下方法会更干净一些：

for item in items:
    item.perform_action()

甚至是一个生成器表达式：

(item.some_attribute for item in items)

因此，从本质上讲，当有人说某件事情不符合 pythonic 时，他们是在说这段代码可以用一种更适合 Python 编码风格的方式来重新编写。
另外，去了解 Python Built-in Functions，而不是重新造轮子。

关于 Pythonic 的“官方介绍”

其实，Python 命令行里已经秘密“隐藏”了关于 Pythonic 的介绍。只要打开 Python 控制台，输入 import this，你就能看到：

C:\Users\xshen>python
Python 3.8.6 (tags/v3.8.6:db45529, Sep 23 2020, 15:52:53) [MSC v.1927 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import this
The Zen of Python, by Tim Peters

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!
>>>

直译过来是：Tim Peters 的《Python的禅意》

美丽的比丑陋的好。
明确的比含蓄的好。
简单的比复杂的好
复杂的比复杂的好
扁平的比嵌套的好。
稀疏比密集好。
可读性很重要。
特殊情况不特殊，不足以打破规则。
虽然实用性胜过纯粹性。
错误永远不应该默默地通过。
除非明确沉默。
在面对模棱两可的情况下，拒绝猜测的诱惑。
应该有一个--最好只有一个--明显的方法。
虽然这种方式一开始可能并不明显，除非你是荷兰人。
现在总比不做要好。
虽然从不比现在*好。
如果实现很难解释，那就是个坏主意。
如果实现很容易解释，它可能是个好主意。
命名空间是一个非常棒的想法--让我们做更多的命名空间!

关于 Pythonic 你 get 到了吗？

Problem

When you use Jenkins multibranch pipeline, you may want to have different default parameters settings for defferent branches build.

For example:

For develop/hotfix/release branches, except regular build, you also want to do some code analyzes, like code scanning, etc.
For other branches, like feature/bugfix or Pull Request that you just want to do a regular build.

So you need to have dynamic parameter settings for your multibranch pipeline job.

Solution

So for these cases, how to deal with Jenkins multibranch pipeline. Here are some code snippet that is works well in my Jenkinsfile.

def polarisValue = false
def blackduckValue = false

if (env.BRANCH_NAME.startsWith("develop") || env.BRANCH_NAME.startsWith("hotfix")
 || env.BRANCH_NAME.startsWith("release")) {
	polarisValue = true
	blackduckValue = true
}

 pipeline {
   agent { node { label 'gradle' } }

   parameters {
       booleanParam defaultValue: polarisValue, name: 'Polaris',  description: 'Uncheck to disable Polaris'
       booleanParam defaultValue: blackduckValue, name: 'BlackDuck', description: 'Uncheck to disable BD scan'
   }

   stages {
     // ...
   }
 }

背景

代码审查（Code Review），就是让别人来审查你的代码，其目的就是确保代码库的整体代码运行状况随着时间推移而不断改善。

中国有句古话：三人行必有我师。

代码审查同样如此：

• 他人的审查或许会有不一样的思考和建议；
• 人都会犯错，多一个人检查就减少犯错的机率。

因此代码审查是你编写的代码在合并到主分支前最重要的一项检查工作，也是一项最直接、最低成本的发现软件中的错误绝佳方式。

既然代码审查这么重要，而且有这样显而易见的收益，但总能听到代码审查在团队里执行起来不容易、效果不理想的问题。问题出在哪呢？

据我观察有两点原因：

第一，读别人代码需要花时间，往往还需要代码提交者带着业务为审查者讲一遍，同时占用双方时间；
其次，如果代码审查者工作繁重、压力大而没有时间，也很容易造成执行不到位，走过场；

如何才能比较好的开展代码审查？让我们先来看看大公司是怎么做的，Google 的这篇关于代码审查的文章里给出了具体法则。

Google 的代码审查法则

在进行代码审查时，应确保：

• 代码经过精心设计
• 该功能对代码用户很有帮助
• 任何 UI 更改都是明智的，并且看起来不错
• 任何并行编程都是安全完成的
• 代码没有比需要的复杂
• 开发人员没有实现他们将来可能需要的东西
• 代码具有适当的单元测试
• 测试经过精心设计
• 开发人员对所有内容使用了清晰的名称
• 注释清晰实用，并且主要说明Why而不是What
• 代码已正确文档化
• 该代码符合我们的样式指南

确保检查要求你检查的每一行代码，查看上下文，确保你在改善代码运行状况，并称赞开发人员所做的出色工作。

原文：https://google.github.io/eng-practices/review/reviewer/looking-for.html

代码审查法的落地

可见，想要更好的落地代码审查，需要先要确立法则，你可以根据实际情况对上述法则进行借鉴、删减或补充；

第二，作为技术领导应当积极布道，让开发者了解统一的代码审查法则；

第三，应当把法则里的具体规则尽可能地通过流程控制、自动化检查则纳入到 Pull Request 中。

另外提醒作为 Reviewer 要 Peaceful ！！！在代码审查时注意不要带有“教育”性质的去给别人提出修改建议，那样很容易适得其反。

以下是一些不完全实践，供参考。

流程控制

规避任何不经 Review 的代码进入到主分支

以 Bitucket 为例。GitHub，GitLab 在设置上大同小异。

• 打开分支权限设置里的选项 Prevent changes without a pull request 打开它。当然如果有需要可以在这个选项里添加 Exception，被添加的人可以不通过 Pull Reuqest 来提交代码。

• 在 Merge Check 里开启 Minimum approvals 这个选项。比如设置 Number of approvals = 1，这样需要至少有一个 Reviewers 点击 Approve 按钮才允许 Merge。

自动化检查

通过CI流水线验证编译和测试

• 建立自动化构建和测试 Pipeline，这样在创建 Pull Request 的时候可以自动构建、测试以及检查。Jenkins 的 Multi-branch pipeline 可以满足这个需求。

• 开启 Bitucket 的 Merge Check 里 Minimum successful builds 选项，验证构建/测试结果，以防止任何没有通过构建和测试的代码可以 Merge 到主分支。

• 另外，可以通过自行编写工具来实现，或可以集成其他 CI 工具来做检查，例如：

  • 针对 Pull Request 的修改历史来分析提交历史并推荐 Reiewer；
  • 通过 Lint 工具来检查编码规范；
  • 通过 REST API 检查是否需要压缩 Commits 来保证清晰的提交历史；
  • 通过 SonarQube 检查 Quality Gate 等。

实现自动化检查，可以帮助 Reviewers 将审查的工作精力放在代码的具体实现上，其他的交给工具。

最后

代码审查做的好不好，跟一个团队有没有良好的技术氛围，或者是否存在有技术领导力，有“品位”的技术大牛也是正相关的。

• 如果团队里大多数都是有“品位”的工程师，他们会以写出优秀的代码（或挑刺）乐此不疲。
• 相反如果团队不重视规范，只追求短期的绩效达成，只会让技术债越欠越多，产品越做越烂。

欢迎留言分享你的意见或建议。

Today, when I tried to upgrade my team’s Jenkins server from Jenkins 2.235.1 to Jenkins 2.263.3, I met a problem that can not launch the Windows agent.

[2021-01-29 23:50:40] [windows-agents] Connecting to xxx.xxx.xxx.xxx
Checking if Java exists
java -version returned 11.0.2.
[2021-01-29 23:50:40] [windows-agents] Installing the Jenkins agent service
[2021-01-29 23:50:40] [windows-agents] Copying jenkins-agent.exe
ERROR: Unexpected error in launching an agent. This is probably a bug in Jenkins
Also: java.lang.Throwable: launched here
at hudson.slaves.SlaveComputer._connect(SlaveComputer.java:286)
at hudson.model.Computer.connect(Computer.java:435)
at hudson.slaves.SlaveComputer.doLaunchSlaveAgent(SlaveComputer.java:790)
...
...
at java.lang.Thread.run(Thread.java:748)
java.lang.NullPointerException
at hudson.os.windows.ManagedWindowsServiceLauncher.launch(ManagedWindowsServiceLauncher.java:298)

This issue had been raised in the Jenkins Jira project: JENKINS-63198 and JENKINS-63198

There is also a Windows Support Updates guide here that mentioned this problem.

Finally, I fixed this problem by the following steps:

1. Update windows-slaves-plugin to the lastest version 1.7 (fixes for Jenkins 2.248+)

Then the error should be like this

[2021-01-30 23:53:40] [windows-agents] Connecting to xxx.xxx.xxx.xxx
Checking if Java exists
java -version returned 11.0.2.
[2021-01-30 23:53:47] [windows-agents] Copying jenkins-agent.xml
[2021-01-30 23:53:48] [windows-agents] Copying agent.jar
[2021-01-30 23:53:48] [windows-agents] Starting the service
ERROR: Unexpected error in launching an agent. This is probably a bug in Jenkins
org.jinterop.dcom.common.JIException: Unknown Failure
	at org.jvnet.hudson.wmi.Win32Service$Implementation.start(Win32Service.java:149)
Caused: java.lang.reflect.InvocationTargetException
	at sun.reflect.GeneratedMethodAccessor219.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at org.kohsuke.jinterop.JInteropInvocationHandler.invoke(JInteropInvocationHandler.java:140)
Also:   java.lang.Throwable: launched here

2. Then change jenkins-agent.exe.config file. remove or comment out this line <supportedRuntime version="v2.0.50727" /> as below

also do this for jenkins-slave.exe.config in case it also exists.

<configuration>
  <runtime>
    <!-- see http://support.microsoft.com/kb/936707 -->
    <generatePublisherEvidence enabled="false"/>
  </runtime>
  <startup>
    <!-- this can be hosted either on .NET 2.0 or 4.0 -->
    <!-- <supportedRuntime version="v2.0.50727" /> -->
    <supportedRuntime version="v4.0" />
  </startup>
</configuration>

3. Then try to Launch agent.

If it still does not work and has this error message “.NET Framework 2.0 or later is required on this computer to run a Jenkins agent as a Windows service”, you need to upgrade your .NET Framework.

Here is a link for update .NET Framework.

Hopefully, this could help you to fix connect the issue of the Windows agent. Let me know in case of any questions.

DevOps 实际上是什么意思？🤔

DevOps 是一种软件开发方法，涉及持续开发，持续测试，持续集成，部署和监视。这一系列过程跨越了传统上孤立的开发和运营团队，DevOps 试图消除它们之间的障碍。

因此，DevOps 工程师基本上与 Development 和 Operations 团队合作。它是这两个主要部分之间的链接。

概念与工具

DevOps 包括诸如构建自动化、CI/CD、基础架构即代码等概念，并且有许多工具可以实现这些概念。由于这些工具数量众多，因此可能会造成混乱和压倒性的结果。

最重要的是要了解概念，并为每个类别的学习找一种特定的工具。例如，当你已经知道什么是 CI/CD 并知道如何使用 Jenkins 时，也将很容易学习同类型的其他替代工具。

接下来让就来看看学习 DevOps 需要掌握哪些技能。

1）软件开发的概念

作为一名 DevOps 工程师，你不会直接对应用程序进行编程，但是当你与开发团队紧密合作以改善和自动化他们的任务时，你需要了解以下概念：

• 开发人员的工作方式
• 他们正在使用哪个 git 工作流程
• 如何配置应用程序
• 自动化测试

2）操作系统

作为 DevOps 工程师，你负责准备在操作系统上部署应用程序的所需要的基础结构环境。并且由于大多数服务器是 Linux 服务器，因此你需要了解 Linux 操作系统，并善于使用命令行，所以你需要知道：

• 基本的 Shell 命令
• Linux 文件系统
• 管理服务器的基础知识
• SSH 密钥管理
• 在服务器上安装不同的工具

3）网络与安全

你还需要了解网络和安全性的基础知识才能配置基础架构，例如：

• 配置防火墙以保护应用程序
• 了解 IP 地址，端口和 DNS 的工作方式
• 负载均衡器
• 代理服务器
• HTTP/HTTPS

但是，要在 DevOps 和 IT Operations 之间划清界线，你不是系统管理员。因此，在这里不需要高级知识，理解和了解基本知识就够了。IT 方面是这些 SysAdmins，Networking 或 Security Engineers 人的专长。

4）容器化

随着容器成为新标准，你可能会将应用程序作为容器运行，这意味着你需要大致了解：

• 虚拟化的概念
• 容器的概念
• 学习哪个工具？ Docker - 当今最受欢迎的容器技术

5）持续集成和部署

在 DevOps 中，所有代码更改（例如开发人员的新功能和错误修复）都应集成到现有应用程序中，并以自动化方式连续地部署到最终用户。因此，建立完整的 CI/CD 管道是 DevOps 工程师的主要任务和职责。

在完成功能或错误修正后，应自动触发在 CI 服务器（例如 Jenkins ）上运行的管道，该管道：

• 运行测试
• 打包应用程序
• 构建 Docker 镜像
• 将 Docker Image 推送到工件存储库，最后
• 将新版本部署到服务器（可以是开发，测试或生产服务器）

因此，你需要在此处学习技能：

• 设置 CI/CD 服务器
• 构建工具和程序包管理器工具以执行测试并打包应用程序
• 配置工件存储库（例如 Nexus，Artifactory）

当然，可以集成更多的步骤，但是此流程代表 CI/CD 管道的核心，并且是 DevOps 任务和职责的核心。

学习哪个工具？Jenkins 是最受欢迎的人之一。其他：Bamboo，Gitlab，TeamCity，CircleCI，TravisCI。

6）云提供商

如今，许多公司正在使用云上的虚拟基础架构，而不是管理自己的基础架构。这些是基础架构即服务（IaaS）平台，可提供一系列服务，例如备份，安全性，负载平衡等。

因此，你需要学习云平台的服务。例如。对于 AWS，你应该了解以下基本知识：

• IAM 服务-管理用户和权限
• VPC 服务-你的专用网络
• EC2 服务-虚拟服务器
• AWS 提供了更多的服务，但是你只需要了解你实际需要的服务即可。例如，当 K8s 集群在 AWS 上运行时，你还需要学习 EKS 服务。

AWS 是功能最强大，使用最广泛的一种，但也是最困难的一种。

学习哪个工具？AWS 是最受欢迎的一种。其他热门：Azure，Google Cloud，阿里云，腾讯云。

7）容器编排

如前所述，容器已被广泛使用，在大公司中，成百上千个容器正在多台服务器上运行，这意味着需要以某种方式管理这些容器。

为此目的，有一些容器编排工具，而最受欢迎的是 Kubernetes。因此，你需要学习：

• Kubernetes 如何工作
• 管理和管理 Kubernetes 集群
• 并在其中部署应用程序

学习哪个工具？Kubernetes - 最受欢迎，没有之一。

8）监视和日志管理

软件投入生产后，对其进行监视以跟踪性能，发现基础结构以及应用程序中的问题非常重要。因此，作为 DevOps 工程师的职责之一是：

• 设置软件监控
• 设置基础架构监控，例如用于你的 Kubernetes 集群和底层服务器。

学习哪个工具？Prometheus, Grafana…

9）基础设施即代码

手动创建和维护基础架构非常耗时且容易出错，尤其是当你需要复制基础架构时，例如用于开发，测试和生产环境。

在 DevOps 中，希望尽可能地自动化，那就是将“基础结构即代码（Infrastructure as Configuration）”引入其中。因此使用 IaC ，我们将使用代码来创建和配置基础结构，你需要了解两种 IaC 方式：

• 基础设施配置
• 配置管理

使用这些工具，可以轻松地复制和恢复基础结构。因此，你应该在每个类别中都知道一种工具，以使自己的工作更有效率，并改善与同事的协作。

学习哪个工具？

基础架构设置：Terraform 是最受欢迎的一种。
配置管理：Ansible，Puppet，Chef。

10）脚本语言

作为 DevOps 工程师就常见的工作就是编写脚本和小型的应用程序以自动化任务。为了能够做到这一点，你需要了解一种脚本或编程语言。

这可能是特定于操作系统的脚本语言，例如 bash 或 Powershell。

还需要掌握一种独立于操作系统的语言，例如 Python 或 Go。这些语言功能更强大，更灵活。如果你善于使用其中之一，它将使你在就业市场上更具价值。

学习哪个工具？Python：目前是最需要的一个，它易于学习，易于阅读并且具有许多可用的库。其他：Go，NodeJS，Ruby。

11）版本控制

上述所有这些自动化逻辑都作为代码编写，使用版本控制工具（例如Git）来管理这些代码和配置文件。

学习哪个工具？Git - 最受欢迎和广泛使用，没有之一。

DevOps Roadmap [2021] - How to become a DevOps Engineer

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 的翻译。