2024年如何保持竞争力:DevOps工程师的关键技能

相信大家最近都总会看到这样或那样的新闻:哪个科技巨头又裁员了。裁员潮似乎成为了这个时代的常态,让许多打工人感到焦虑和不安。

身在大连的我确实深有感触,外企和私企都有在裁员,与前两年相比,岗位越来越少,失业的人越来越多,因此想找到一个满意的岗位将会变得越来越难。

再加上随着人工智能(AI)的发展,作为 DevOps 打工人常常在想,需要掌握哪些关键技能和能力才能让自己保持竞争力。

以下是我认为在 2024 年至关重要的关键技能和能力:

  1. 深入理解 DevOps 理念和工具

    • 熟练掌握持续集成/持续交付(CI/CD)工具和流程。如 Jenkins,GitLab CI/CD,GitHub Actions。
    • 能够设计和优化自动化部署流程,包括自动化测试、构建和发布。
    • 精通容器化技术,如 Docker,以及容器编排工具,如 Kubernetes,Helm。
  2. 云计算和基础设施

    • 对主流云服务提供商(如 AWS、Azure、Google Cloud)的基础设施和服务有深入了解。
    • 能够进行云原生架构设计和实施,包括使用云原生服务和技术。
  3. 自动化和编程能力

    • 精通至少一种编程语言(如 Python、Go、Java 等),能够编写脚本和工具来实现自动化。
    • 对基础架构即代码(IaC)工具有熟练掌握,例如 Terraform、Ansible 等。
  4. 监控和日志管理

    • 熟悉监控和日志管理工具,能够建立完善的监控系统和日志分析平台。
    • 掌握应用性能监控和故障排除技术。如 Prometheus,Grafana,ELK Stack。
  5. 安全和合规性

    • 了解容器和云安全最佳实践,能够设计安全的部署架构。
    • 理解数据隐私和合规性要求,能够实施符合法规的解决方案。如 HashiCorp Vault,Chef InSpec。
  6. 持续学习和技术更新

    • 持续关注新技术和行业趋势,参与培训和研讨会,多于同行交流。
    • 不断学习和提升自身的技能,保持适应快速变化的技术环境。
  7. 团队协作和沟通能力

    • 良好的团队合作和沟通能力,能够与开发团队、运维团队和其他利益相关者有效地协作。
    • 熟练使用版本控制系统和协作工具。
  8. 问题解决和创新思维

    • 具备快速定位和解决问题的能力,善于思考创新解决方案。
    • 鼓励并参与团队中的持续改进和创新活动。
  9. 业务理解和领导能力(对于高级岗位):

    • 具备对业务需求的理解和洞察,能够为业务提供技术支持和解决方案。
    • 如果担任领导职务,需要具备领导团队和推动项目的能力。

只有通过不断学习和拓展技能,保持对最新技术的了解,注重团队协作和创新,才能够在市场不好,AI崛起的环境中继续保持竞争力。

最后,希望大家都能在 2024 年工作顺利,不被裁员;裁员 N+x (x>=1),并顺利过渡到下一份更好的工作 💪


转载本站文章请注明作者和出处,请勿用于任何商业用途。欢迎关注公众号「DevOps攻城狮」

你一定要了解的 GitHub Action 特性:可重用工作流(Reusable Workflows)

什么是 Reusable Workflows

如果你使用过 GitHub Actions,那么你一定要了解 Reusable Workflows 这个特性,它允许你定义工作流并在多个仓库中重复使用它们。

GitHub Actions 是 GitHub 自家的 CI/CD 工具。其他主流的 CI/CD 工具还有 Jenkins,Azure DevOps,Travis CI 等。

通过 GitHub Reusable Workflows 你可以将常见的工作流程定义在单独的 Git 仓库,然后在其他仓库中引用这些工作流,而无需在每个仓库中重复定义它们,这样做带来的好处包括:

  • 一致性: 确保你的团队或组织在不同的仓库中使用相同的标准化工作流程,保持一致性。
  • 维护性: 对工作流程进行更改或更新你只需在一个地方进行修改,而不必修改多个仓库中的代码。
  • 重用性: 将通用的工作流程分离出来,在需要时可以在任何项目中重用,提高了代码的重用性和可维护性。

总的来说,GitHub Reusable Workflows 使得在 GitHub Actions 中管理和组织工作流程变得更加灵活和可维护。

如何使用 Reusable Workflows

使用 GitHub Reusable Workflows 可以让你在 .github 或是其他仓库创建一个工作流,然后在其他仓库中调用该工作流。

以下是使用 GitHub Reusable Workflows 的一般步骤:

  1. 创建可重用工作流程

    • 在你的 GitHub 账户下创建一个新的仓库用于存储你的可重用工作流程。
    • 在仓库中创建一个名为 .github/workflows 的目录(如果不存在的话)。
    • 在该目录下创建一个 YAML 文件,用于定义你的工作流程。
  2. 定义参数化工作流程(可选)

    • 如果你希望你的工作流程是可参数化的,可以在 workflows 中使用 inputs 关键字定义参数。
  3. 将工作流程提交到仓库

    • 将你创建的工作流程 YAML 文件提交到仓库,并确保它位于 .github/workflows 目录中。
  4. 在其他仓库中使用工作流程

    • 打开你希望使用该工作流程的其他仓库。在 .github/workflows 目录下创建一个 YAML 文件,指向你之前创建的可重用工作流程的 YAML 文件。
  5. 提交更改并触发工作流程

    • 将对仓库的更改提交到 GitHub,并将它们推送到远程仓库。
    • GitHub 将自动检测到新的工作流程文件,并根据触发器(例如 pushpull_request 等)来触发工作流程的执行。

以下是一个简单的示例,演示如何创建和使用可重用工作流程:

假设你在名为 reuse-workflows-demo 的仓库中 .github/workflows 目录下创建了一个名为 build.yml 的工作流程文件,用于构建你的项目。该文件的内容如下:

如果不在 .github/workflows 目录下,你会遇到这个错误 invalid value workflow reference: references to workflows must be rooted in '.github/workflows'

name: Build

on:
workflow_call:
inputs:
target:
required: true
type: string
default: ""

jobs:
build:
strategy:
matrix:
target: [dev, stage, prod]
runs-on: ubuntu-latest
steps:
- name: inputs.target = ${{ inputs.target }}
if: inputs.target
run: echo "inputs.target = ${{ inputs.target }}."

- name: matrix.targe = ${{ matrix.target }}
if: matrix.target
run: echo "matrix.targe = ${{ matrix.target }}."

然后,在你的其他仓库中的 .github/workflows 目录下你可以创建一个 workflow build.yml 指向该文件,例如:

name: Build

on:
push:
pull_request:
workflow_dispatch:

jobs:
call-build:
uses: shenxianpeng/reuse-workflows-demo/.github/workflows/build.yml@main
with:
target: stage

更多关于 Reusable Workflows 的实际项目示例可以参考 cpp-linter 组织下的 .github 仓库。

# cpp-linter/.github/.github/workflows
.
├── codeql.yml
├── main.yml
├── mkdocs.yml
├── pre-commit.yml
├── py-coverage.yml
├── py-publish.yml
├── release-drafter.yml
├── snyk-container.yml
├── sphinx.yml
└── stale.yml

GitHub Reusable Workflows 的 7 点最佳实践:

  1. 模块化设计:将工作流程分解为小的、可重用的模块,每个模块专注于执行特定的任务。这样可以提高工作流程的灵活性和可维护性,并使其更容易被重用和组合。
  2. 参数化配置:使工作流程能够接受参数,以便在每次使用时进行配置。这样可以使工作流程更通用,适应不同项目和环境的需求。
  3. 版本控制:确保你的可重用工作流程受到版本控制,并定期更新以反映项目需求的变化。可以使用 GitHub 的分支或 tag 来管理工作流程的不同版本,并在需要时轻松切换或回滚。
  4. 文档和注释:为工作流程提供清晰的文档和注释,以帮助其他开发人员理解其目的和操作步骤。注释关键步骤的目的和实现细节,以便其他人可以轻松理解和修改工作流程。
  5. 安全性:谨慎处理包含敏感信息(如凭据、密钥等)的工作流程文件,确保它们不会意外地泄露。将敏感信息存储在 GitHub 的 Secrets 中,并在工作流程中使用 Secrets 来访问这些信息。
  6. 测试和验证:在引入可重用工作流程到项目之前,进行测试和验证,确保它们能够正确地集成和执行所需的操作。可以在单独的测试仓库中模拟和测试工作流程,以确保其正确性和可靠性。
  7. 优化性能:优化工作流程的性能,尽量减少不必要的步骤和资源消耗,以确保工作流程能够在合理的时间内完成任务,并尽量减少对系统资源的占用。

遵循这些最佳实践可以帮助你更好地利用 GitHub Reusable Workflows 并为你的项目和团队提供更高效和可维护的自动化工作流程。

Reusable Workflows 和 Jenkins Shared Library 有什么不同和相同

最后,说一下我对 GitHub Reusable Workflows 和 Jenkins Shared Library 的理解和总结。有一些相似之处,但也有一些区别。

相同点:

  1. 可重用性: 两者都旨在提供一种机制,使得可以将通用的自动化工作流程定义为可重用的组件,并在多个项目中共享和重用。
  2. 组织性: 都有助于更好地组织和管理自动化工作流程,使其易于维护和更新。
  3. 参数化: 都支持参数化,使得可以根据需要在不同的上下文中定制和配置工作流程。

不同点:

  1. 平台: Reusable Workflows 是 GitHub Actions 的一部分,而 Shared Library 是 Jenkins 的功能。它们在不同的平台上运行,具有不同的生态系统和工作原理。
  2. 语法: Reusable Workflows 使用 YAML 语法来定义工作流程,而 Shared Library 使用 Groovy 语言来定义共享库。
  3. 易用性: Reusable Workflows 在 GitHub 平台上使用起来相对较简单,特别是对于那些已经在 GitHub 上托管代码的项目。Shared Library 则需要配置 Jenkins 服务器和相关插件,并且需要对 Jenkins 构建流程有一定的了解。

综上所述,尽管 GitHub Reusable Workflows 和 Jenkins Shared Library 都旨在提供可重用的自动化工作流程,并且具有一些相似之处,但是它们在平台、语法、易用性等方面存在显著的差异。

具体选择使用哪种取决于你的需求、工作流程和所需要使用的平台。


转载本站文章请注明作者和出处,请勿用于任何商业用途。欢迎关注公众号「DevOps攻城狮」

2023 年开源状况和人工智能的崛起(GitHub)

最近看到一篇非常有信息量的关于人工智能、云原生、开源的趋势报告,出自于GitHub,翻译并分享给大家,以下是报告全文。

英文原文在这里:https://github.blog/2023-11-08-the-state-of-open-source-and-ai/?utm_source=banner&utm_medium=github&utm_campaign=octoverse


新技术成为主流意味着什么?

Git 于 2005 年首次发布,当我们创建 GitHub 时,Git 还是一个新的开源版本控制系统。如今,Git 已成为现代开发人员体验的基本元素 — 93% 的开发人员使用它在各地构建和部署软件。

2023 年,GitHub 数据凸显了另一种技术如何迅速开始重塑开发者体验:人工智能。去年,越来越多的开发人员开始使用人工智能,同时也尝试构建人工智能驱动的应用程序。 Git 从根本上改变了当今的开发人员体验,现在人工智能正在为软件开发的下一步奠定基础。

在 GitHub,我们知道开发人员喜欢边做边学,开源可以帮助开发人员更快地采用新技术,将其集成到他们的工作流程中,并构建下一代技术。开源还为几乎所有现代软件提供动力——包括大部分数字经济。当我们探索技术如何成为主流时,GitHub 在弥合开源技术实验与广泛采用之间的差距方面继续发挥着关键作用,这些技术支撑着我们软件生态系统的基础。

在今年的报告中,我们将研究围绕人工智能、云和 Git 的开源活动如何改变开发人员体验,并日益增强对开发人员和组织的影响。

我们发现了三大趋势:

  • 开发人员正在大量使用生成式人工智能进行构建。
    我们看到越来越多的开发人员尝试使用 OpenAI 和其他 AI 参与者的基础模型,开源生成式 AI 项目甚至会在 2023 年进入按贡献者数量计算的前 10 个最受欢迎的开源项目。几乎所有开发人员 (92%) 都在使用或试验借助 AI 编码工具,我们期望开源开发人员能够在 GitHub 上推动下一波 AI 创新浪潮。
  • 开发人员正在大规模运营云原生应用程序。
    我们看到使用基于 Git 的基础设施即代码 (IaC) 工作流程的声明性语言有所增加,云部署的标准化程度更高,开发人员使用 Dockerfile 和容器、IaC 和其他云原生的速度急剧增加技术。
  • 2023 年首次开源贡献者数量最多。
    我们继续看到商业支持的开源项目在首次贡献者和总体贡献中占据最大份额,但今年,我们还看到生成式 AI 项目进入了首次贡献者最受欢迎的前 10 个项目。我们还看到 GitHub 上的私人项目显著增长,同比增长 38%,占 GitHub 上所有活动的 80% 以上。

在 GitHub 上构建的全球开发者社区

在全球范围内,开发人员正在使用 GitHub 来构建软件并进行比以往更多的协作,而且涉及公共和私人项目。这不仅证明了 Git 在当今开发者体验中的基础价值,也展示了全球开发者社区使用 GitHub 构建软件的情况。

我们用 GitHub 上的账户总数来计算特定开发者社区的账户数,从而绘制出这张热图。

美国拥有 2020 万开发者,过去一年开发者增长 21%,继续拥有全球最大的开发者社区。

但自 2013 年以来,我们不断看到其他社区在整个平台上实现了更多增长,我们预计这种情况会持续下去。 GitHub 上开发人员的全球分布显示了哪些地区拥有最多的开发人员。

亚太地区、非洲、南美洲和欧洲的开发者社区逐年扩大,其中印度、巴西和日本处于领先地位。

预测未来五年排名前 10 的开发者社区

为了了解哪些开发者社区将在未来五年内增长最快,我们根据当前的增长率进行了预测。在此标题下,我们预计到 2027 年印度将取代美国成为 GitHub 上最大的开发者社区。

这些预测假设线性增长,以预测到 2028 年哪些开发者社区将成为 GitHub 上最大的社区。

亚太地区发展最快的开发者社区

我们继续看到,在印度、日本和新加坡等经济中心的推动下,亚太地区出现了可观的增长。

开发人员数量 同比增长
01 新加坡 >100 万开发者 39%
02 印度 >1320 万开发者 36%
03 香港(特别行政区) >160 万开发者 35%
04 越南 >150 万开发者 34%
05 印度尼西亚 >290 万开发者 31%
06 日本 >280 万开发者 31%
07 菲律宾 >130 万开发者 31%
08 泰国 >857K 开发者 25%
09 韩国 >190 万开发者 22%
10 澳大利亚 >140 万开发者 21%

表 1:2023 年开发者总数增长,较 2022 年增长百分比。

印度的开发者社区继续实现同比大幅增长

在去年的 Octoverse 中,我们预测印度的开发者总数将超过美国。这仍然有望发生。印度的开发者人数同比增长 36%,2023 年有 350 万新开发者加入 GitHub。

作为联合国支持的数字公共产品联盟的一部分,印度一直在利用开放材料(从软件代码到人工智能模型)建设数字公共基础设施,以改善数字支付和电子商务系统。以下是印度开发人员在 GitHub 上构建并贡献的开源软件 (OSS) 项目列表。

新加坡今年是亚太地区开发者人数增长最快的国家

并且以开发者占总人口的比例最高而位居全球第一。新加坡国立大学计算机学院将 GitHub 纳入其课程,高增长也可能归因于该国在东南亚的监管重要性。

由于对技术和初创公司的投资,我们还可能在明年看到日本的开发人员持续增长。

非洲发展最快的开发者社区

非洲地区拥有世界上增长最快的人口和不断增加的开发人员,已被认为是有前途的科技公司中心。(例如,在肯尼亚,小学和中学必须教授编程。)

开发人员数量 同比增长
01 新加坡 >100 万开发者 39%
02 印度 >1320 万开发者 36%
03 香港(特别行政区) >160 万开发者 35%
04 越南 >150 万开发者 34%
05 印度尼西亚 >290 万开发者 31%
06 日本 >280 万开发者 31%
07 菲律宾 >130 万开发者 31%
08 泰国 >857K 开发者 25%
09 韩国 >190 万开发者 22%
10 澳大利亚 >140 万开发者 21%

表 2:2023 年开发者总数增长,较 2022 年增长百分比。

尼日利亚是 OSS 采用和技术投资的热点,其 45% 的同比增长率(全球增幅最高)反映了这一点。GitHub 上还有至少 200 个由尼日利亚开发者制作的项目集合,可以在“非洲制造”集合下找到。

南美洲发展最快的开发者社区

南美洲的开发者增长率与亚太和非洲一些增长最快的开发者社区相当。

开发人员数量 同比增长
01 新加坡 >100 万开发者 39%
02 印度 >1320 万开发者 36%
03 香港(特别行政区) >160 万开发者 35%
04 越南 >150 万开发者 34%
05 印度尼西亚 >290 万开发者 31%
06 日本 >280 万开发者 31%
07 菲律宾 >130 万开发者 31%
08 泰国 >857K 开发者 25%
09 韩国 >190 万开发者 22%
10 澳大利亚 >140 万开发者 21%

表 3:2023 年开发者总数增长,较 2022 年增长百分比。

2023年,巴西的开发者人数是该地区最多的,并继续以两位数增长,同比增长30%。此前,巴西的私人和公共组织持续投资。查看巴西开发人员在 GitHub 上创建和贡献的 OSS 项目列表

我们还看到阿根廷和哥伦比亚的持续增长,这两个国家在过去几年中已成为组织的热门投资目标。

欧洲发展最快的开发者社区

整个欧洲的社区开发人员总数继续增加,但他们的发展现在更接近于美国的总体发展,因为南美洲、非洲和亚太地区的社区增长超过了他们。

开发人员数量 同比增长
01 新加坡 >100 万开发者 39%
02 印度 >1320 万开发者 36%
03 香港(特别行政区) >160 万开发者 35%
04 越南 >150 万开发者 34%
05 印度尼西亚 >290 万开发者 31%
06 日本 >280 万开发者 31%
07 菲律宾 >130 万开发者 31%
08 泰国 >857K 开发者 25%
09 韩国 >190 万开发者 22%
10 澳大利亚 >140 万开发者 21%

值得注意的是,法国的增长是在政府推动吸引更多科技初创企业之后实现的。我们还看到西班牙和意大利的增长有所上升,这说明这两个地区为支持其国内技术市场所做的努力。

2023 年生成式 AI 爆发式增长

虽然生成式人工智能在 2023 年引起了轰动,但对于 GitHub 上的开发者来说,它并不是全新的。事实上,过去几年我们已经在 GitHub 上看到了几个生成式 AI 项目的出现,以及许多其他专注于 AI 的项目。

但 2023 年的 GitHub 数据反映了这些人工智能项目如何从更面向专业的工作和研究发展到更主流的采用,开发人员越来越多地使用预先训练的模型和 API 来构建由人工智能驱动的生成应用程序。

就在去年过半的时候,我们看到 2023 年的生成式 AI 项目数量是 2022 年全年的两倍多。 我们知道这只是冰山一角。

随着越来越多的开发人员尝试这些新技术,我们期望他们能够推动软件开发中的人工智能创新,并继续将该技术快速发展的功能带入主流。

开发人员越来越多地尝试人工智能模型。 在过去的几年里,我们看到开发人员使用 tensorflow/tensorflowpytorch/pytorch 等机器学习库构建项目,而现在我们看到更多的开发人员尝试使用 AI 模型和LLM(例如 ChatGPT API)。

保持聪明: 我们预计企业和组织也将利用预先训练的人工智能模型,特别是随着越来越多的开发人员熟悉如何使用它们进行构建。

开源人工智能创新多种多样,顶级人工智能项目由个人开发者拥有。 分析 GitHub 上排名前 20 的开源生成式 AI 项目,其中一些顶级项目归个人所有。这表明 GitHub 上的开源项目继续推动创新,并向我们所有人展示行业的未来发展,社区围绕最令人兴奋的进步而构建。

生成式人工智能正在推动生成式人工智能项目的个人贡献者在全球范围内大幅增长,同比增长 148%,生成式人工智能项目总数也同比增长 248%。 值得注意的是,美国、印度和日本在开发者社区中处于领先地位,其他地区(包括香港特别行政区)、英国和巴西紧随其后。

了解生成式人工智能的开发人员数量大幅增加将对企业产生影响。 随着越来越多的开发人员熟悉构建基于人工智能的生成式应用程序,我们预计不断增长的人才库将支持寻求开发自己的基于人工智能的产品和服务的企业。

底线: 在过去的一年里,我们看到基于基础模型(例如 ChatGPT)构建的应用程序呈指数级增长,因为开发人员使用这些 LLM 来开发面向用户的工具,例如 API、机器人、助手、移动应用程序和插件。全球开发人员正在帮助为主流采用奠定基础,而实验正在帮助组织建立人才库。

最流行的编程语言

自从我们在 2019 年看到云原生开发的巨大增长以来,IaC 在开源领域也持续增长。 2023 年,Shell 和 Hashicorp 配置语言 (HCL) 再次成为开源项目中的顶级语言,这表明运维和 IaC 工作在开源领域越来越受到重视。

  • HCL 采用率同比增长 36%,这表明开发人员正在为其应用程序利用基础设施。
  • HCL 的增加表明开发人员越来越多地使用声明性语言来指示他们如何利用云部署。

JavaScript 再次夺得第一大最受欢迎语言的桂冠,并且我们继续看到 Python 和 Java 等熟悉的语言逐年保持在前五名语言之列。

TypeScript 越来越受欢迎。 今年,TypeScript 首次取代 Java,成为 GitHub 上 OSS 项目中第三大最受欢迎的语言,其用户群增长了 37%。 TypeScript 是一种集语言、类型检查器、编译器和语言服务于一体的语言,它于 2012 年推出,标志着渐进类型的到来,它允许开发人员在代码中采用不同级别的静态和动态类型。

用于数据分析和操作的流行语言和框架显著增加。 T-SQL 和 TeX 等古老语言在 2023 年不断发展,这凸显了数据科学家、数学家和分析师如何越来越多地使用开源平台和工具。

底线: 编程语言不再仅仅局限于传统软件开发领域。

与 GitHub 上使用的总体最流行语言相比,我们发现 2023 年创建的项目中使用的最流行语言具有显著的一致性。一些值得注意的异常值包括 Kotlin、Rust、Go 和 Lua,它们在 GitHub 上的新项目中出现了更大的增长。

Rust 和 Lua 都以其内存安全性和效率而闻名,并且都可以用于系统和嵌入式系统编程,这可以归因于它们的增长。Go 最近的增长是由 Kubernetes 和 Prometheus 等云原生项目推动的。

开发者活动是新技术采用的领头羊

2023 年初,我们庆祝了超过 1 亿开发者使用 GitHub 的里程碑 —— 自去年以来,我们看到 GitHub 上的全球开发者帐户数量增长了近 26%。更多的开发人员跨时区协作并构建软件。私人和公共存储库中的开发人员活动强调了哪些技术正在被广泛采用,以及哪些技术有望得到更广泛的采用。

开发人员正在自动化更多的工作流程。 在过去的一年里,开发人员使用 GitHub Actions 分钟数增加了 169%,用于自动化公共项目中的任务、开发 CI/CD 管道等。

  • 平均而言,开发人员在公共项目中每天使用 GitHub Actions 的时间超过 2000 万分钟。随着 GitHub Marketplace 中的 GitHub Actions 数量在 2023 年突破 20,000 个大关,社区不断发展。
  • 这凸显了开源社区对 CI/CD 和社区管理自动化的认识不断增强。

超过 80% 的 GitHub 贡献都贡献给私有存储库。 其中,私人项目贡献超过 42 亿美元,公共和开源项目贡献超过 3.1 亿美元。这些数字显示了通过免费、团队和 GitHub Enterprise 帐户在公共、开源和私人存储库中发生的活动的巨大规模。大量的私人活动表明了内部源代码的价值,以及基于 Git 的协作不仅有利于开源代码的质量,而且也有利于专有代码的质量。

事实上,在最近 GitHub 赞助的一项调查中,所有开发人员都表示他们的公司至少采用了一些内部源实践,超过一半的开发人员表示他们的组织中有活跃的内部源文化。

GitHub 是开发人员操作和扩展云原生应用程序的地方。 2023 年,430 万个公共和私有存储库使用 Dockerfile,超过 100 万个公共存储库使用 Dockerfile 来创建容器。过去几年,我们看到 Terraform 和其他云原生技术的使用量不断增加。 IaC 实践的增加也表明开发人员正在为云部署带来更多标准化。

生成式人工智能进入 GitHub Actions。 人工智能在开发者社区中的早期采用和协作能力在 GitHub Marketplace 中的300 多个人工智能驱动的 GitHub Actions40 多个 GPT 支持的 GitHub Actions中显而易见。开发人员不仅继续尝试人工智能,还通过 GitHub Marketplace 将其带入开发人员体验及其工作流程的更多部分。

底线: 开发人员尝试新技术并在公共和私人存储库中分享他们的经验。这项相互依赖的工作凸显了容器化、自动化和 CI/CD 在开源社区和公司之间打包和发布代码的价值。

开源的安全状况

今年,我们看到开发人员、OSS 社区和公司等通过自动警报、工具和主动安全措施更快地响应安全事件,这有助于开发人员更快地获得更好的安全结果。我们还看到 GitHub 上共享了负责任的 AI 工具和研究。

更多的开发人员正在使用自动化来保护依赖关系。 与 2022 年相比,2023 年开源开发人员合并的针对易受攻击包的自动化Dependabot拉取请求数量增加了 60%,这凸显了共享社区对开源和安全性的奉献精神。得益于 GitHub 上的免费工具(例如 Dependabot、代码扫描和密钥扫描),开源社区的开发人员正在修复更多易受攻击的软件包并解决代码中的更多漏洞。

更多的开源维护者正在保护他们的分支机构。受保护的分支为维护者提供了更多方法来确保其项目的安全性,我们已经看到超过 60% 的最受欢迎的开源项目 使用它们。自从我们今年早些时候在 GA 中在 GitHub 上推出存储库规则以来,大规模管理这些规则应该会变得更加容易。

开发人员正在 GitHub 上分享负责任的 AI 工具。 在实验性生成人工智能时代,我们看到人工智能信任和安全工具的发展趋势。开发人员正在围绕负责任的人工智能、人工智能公平、负责任的机器学习和道德人工智能创建和共享工具。

乔治城大学安全与新兴技术中心也在确定哪些国家和机构是值得信赖的人工智能研究的顶级生产者,并在 GitHub 上分享其研究代码。

底线: 为了帮助 OSS 社区和项目保持更加安全,我们投资了 Dependabot、受保护的分支、CodeQL 和秘密扫描,免费向公共项目提供。2023 年的新采用指标显示这些投资如何成功帮助更多开源项目提高整体安全性。我们还看到软件开发人员和机构研究人员对创建和共享负责任的人工智能工具感兴趣。

开源状态

2023 年,开发者为 GitHub 上的开源项目做出了总计 3.01 亿的贡献,其中包括 Mastodon 等热门项目到 Stable DiffusionLangChain 等生成式 AI 项目。

商业支持的项目继续吸引一些最开源的贡献,但 2023 年是生成式 AI 项目也进入 GitHub 上十大最受欢迎项目的第一年。说到生成式 AI,几乎三分之一拥有至少一颗星的开源项目都有一位使用 GitHub Copilot 的维护者。

商业支持的项目继续领先。 2023 年,贡献者总数最大的项目获得了压倒性的商业支持。这是去年以来的持续趋势,microsoft/vscode、flutter/flutter 和 vercel/next.js 在 2023 年再次跻身前 10 名。

生成式人工智能在开源和公共项目中快速发展。 2023 年,我们看到基于 AI 的生成式 OSS 项目,如 langchain-ai/langchain 和 AUTOMATIC1111/stable-diffusion-webui,在 GitHub 上按贡献者数量跃居榜首。越来越多的开发人员正在使用预先训练的人工智能模型构建法学硕士应用程序,并根据用户需求定制人工智能应用程序。

开源维护者正在采用生成式人工智能。 几乎三分之一拥有至少一颗星的开源项目都有使用 GitHub Copilot 的维护者。这是我们向开源维护人员免费提供 GitHub Copilot 的计划,并表明生成式 AI 在开源领域的采用日益广泛。

开发人员看到了组合包和容器化的好处。 正如我们之前指出的,2023 年有 430 万个存储库使用了 Docker。另一方面,Linux 发行版 NixOS/nixpkgs 在过去两年中一直位居贡献者开源项目的榜首。

首次贡献者继续青睐商业支持的项目。 去年,我们发现,与其他项目相比,围绕流行的、商业支持的项目的品牌认知度吸引了更多的首次贡献者。这种情况在 2023 年继续出现,一些在 Microsoft、Google、Meta 和 Vercel 支持的首次贡献者中最受欢迎的开源项目。

但社区驱动的开源项目(从 home-assistant/core 到 AUTOMATIC1111/stable-diffusion-webui、langchain-ai/langchain 和Significant-Gravitas/Auto-GPT)也见证了首次贡献者的活动激增。这表明,基础模型的开放实验增加了生成人工智能的可及性,为新的创新和更多合作打开了大门。

2023 年,首次为开源项目做出贡献的贡献者数量最多。 新的开发人员通过 freeCodeCamp、First Contributions 和 GitHub Education 等计划参与到开源社区中。我们还看到大量开发人员参与了 Google 和 IBM 等公司的在线开源教育项目。

底线是:开发人员正在为开源生成式人工智能项目做出贡献,开源维护者正在采用生成式人工智能编码工具,而公司则继续依赖开源软件。这些都表明,公开学习并分享新技术实验的开发人员提升了整个全球开发人员网络 - 无论他们是在公共存储库还是私人存储库中工作。

总结

正如 Git 已成为当今开发人员体验的基础一样,我们现在也看到了人工智能成为主流的证据。仅在过去一年,就有高达 92% 的开发人员表示在工作内外使用基于人工智能的编码工具。在过去的一年里,GitHub 上托管的各种开源项目的人工智能实验也出现了爆炸性增长。

我们给您留下三个要点:

  1. GitHub 是生成式 AI 的开发者平台。 生成式 AI 将于 2023 年从专业领域发展成为主流技术,开源活动的爆炸式增长反映了这一点。随着越来越多的开发人员构建和试验生成式 AI,他们正在使用 GitHub 进行协作和集体学习。
  2. 开发人员正在 GitHub 上大规模运行云原生应用程序。 2019 年,我们开始看到开源中使用基于容器的技术的开发人员数量大幅增加,并且越来越多的开发人员使用基于 Git 的 IaC 工作流程、容器编排和其他云原生技术的速度急剧增加2023 年。如此大量的活动表明开发人员正在使用 GitHub 来标准化他们将软件部署到云的方式。
  3. GitHub 是开源社区、开发人员和公司构建软件的地方。 2023 年,我们看到私有存储库的数量增加了 38%,占 GitHub 上所有活动的 81% 以上。但我们看到开源社区持续增长,他们使用 GitHub 来构建未来并推动行业向前发展。数据显示新的开源开发人员的增加以及开放社区可能实现的快速创新步伐,很明显开源从未如此强大。

转载本站文章请注明作者和出处,请勿用于任何商业用途。欢迎关注公众号「DevOps攻城狮」

cpp-linter-action 最新版支持 Pull Request Review 功能了 👏

作为 cpp-linter 的创建者和贡献者,我很高兴地宣布 —— cpp-linter-action 从 v2.9.0 版本开始支持 Pull Request Review 功能了 👏

以下是 cpp-linter-action 的 release notes

release notes

其中 Bump cpp-linter from 1.6.5 to 1.7.1 by @dependabot in #191 是其中最重要的变化。注:cpp-linter 包是​ cpp-linter-action 的核心依赖。

什么是 cpp-linter-action

如果你还不了解 cpp-linter-action 可以查看我之前的文章

简单来说,cpp-linter-action 是 cpp-linter 组织下的一个 GitHub Action,针对 C/C++ 代码做代码格式、诊断和修复典型的编程错误。

目前 cpp-linter-action 大概被超过 500 个开源项目所使用(闭源项目无法统计到),这其中包括 Microsoft、Linux Foundation、CachyOS、nextcloud、Jupyter 等知名组织或项目。

可以说目前 cpp-linter-action 是 GitHub 上 C/C++ 项目的最佳 Linter 选择。

关于 Pull Request Review 功能

此次新增的 Pull Request Review 功能可以直接在 cpp-linter-action 检查完成后给出 review 建议,开发者无需本地修改检查到的错误,并提交到远程。
而是可以直接点击 GitHub 上的 Commit suggestions 按钮,就可以把建议修改直接 merge 到当前的 pull request 中,省去了人为的修改和推送。

format-review

format-suggestion

tidy-review

一旦所有的 suggestions 都已经修复了,github-action bot 会自动你 approve 你的 pull request。

cpp-linter-action 其他已经支持的功能

除了 Pull Request Review 功能之外,cpp-linter-action 目前还支持另外三个选项:Annotations,Thread Comment 和 Step Summary。

GitHub Annotations

即在指定的需要修改的代码行位置提示执行结果​。

clang-format annotations
clang-tidy annotations

Thread Comment

即在 Pull Request 上以评论形式添加执行结果。​

comment

Step Summary

​即在 GitHub Action job 运行界面添加并显示执行结果。

step summary

关于本次发布背后的故事

我终于在大年初八的晚上孩子睡着了之后有时间坐下来写一篇文章了,来记录一下本次发布背后的故事。

这次发布要特别感谢 cpp-linter 联合创建者 @2bndy5 的贡献。他和我素未谋面,但却与我一起“共事”了三年。
我们的相识是因为他的一次主动贡献而开始的,但一直以来的交流仅限于 GitHub 上的 issue 和 pull request 的讨论,只有不公开信息才会通过邮件来传达。

正如 @2bndy5 的个人介绍那样:热衷于编程,喜欢 DIY 电子产品,坚持写易懂的文档。他是我认识的人当中少有的技术全面且文档十分友好的极客

不久前我收到了他的邮件说:因家中变故,他要休息一段时间,他没有动力坐下来写代码了,并告诉我 Pull Request Review 所有改动似乎都通过测试了。如果我想主导发布,他可以提供支持。

在此,我想对发生在他身上的事情再次表示最深切的同情和慰问🙏

继续他的工作我需要先认真阅读他的修改并搞清楚这部分功能,但年底了迟迟没有一个充足的时间来开始,想等着春节假期再来补作业吧。

可是还没有到春节放假,就在腊月二十七孩子生病了,并告知需要住院治疗,因为我们发现得早,病症不严重,孩子在除夕当天恢复得很好,期待着再观察两天就可以出院了。
哎,可是意外发生了,孩子不小心胳膊被烫伤了,作为父母非常痛心,这是我永远都不想回忆的至暗时刻。总之就是雪上加霜。就这样我们从年前腊月二十七一直住院到正月初六,住了 10 天医院。
孩子出院的第二天我和妻子都生病了,可能是当放松下来,人一下子就累病了。

在这段时间里 @2bndy5 完成了对 Pull Request Review 功能测试、文档修改和发布。他在评论里说花时间在编码上会让他短暂地逃离现实。

终于上班的前一天我差不多恢复了体力,就迫不及待的打开 GitHub,审查并测试别人对项目的贡献代码,这次是一个 Title 是来自于德国多特蒙德大学的天体物理学家的贡献者,确实有点惊讶到我了。

但这就是开源的有趣之处,它能让你有机会和任何高手近距离免费过招。如果你给 Linux 内核提交代码,那你极有可能得到 Linus 的指导 :)

最后,欢迎使用 cpp-linter 组织下的任何项目并提出您的宝贵意见、建议、或贡献代码。

———— 于 2024 年 2 月 17 日 23:34


转载本站文章请注明作者和出处,请勿用于任何商业用途。欢迎关注公众号「DevOps攻城狮」

看看顶级的开源组织都在用哪些服务和工具

本篇介绍的是大名鼎鼎的开源软件基金会 Apache 所使用的服务(Services)和工具(Tools),这或许能帮助你打开视野,在选择工具的时候提供参考。如果你是一名 DevOps、SRE 或是 Infra 工程师,通过本篇文章内容结果帮助你更好的展示团队所提供的服务有哪些,以及窥探到 Apache Infra 是怎样组织和管理他们的。

Apache 是谁

如果你不太了解 Apache,下面是关于 Apache 的简要介绍。

Apache 是一个开源软件基金会(Apache Software Foundation,简称 ASF)的缩写。ASF 是一个非营利性的组织,致力于支持和发展开源软件项目。Apache 软件基金会通过提供法律、财务和基础设施支持,帮助开发者共同合作创建和维护开源软件。其中,Apache 软件基金会最为著名的项目之一是 Apache HTTP 服务器,也称为 Apache Web 服务器。此外,ASF 还托管了许多其他流行的开源项目,像 ECharts,Superset,Dubbo,Spark,Kafka 等等。

服务与工具

Apache Infra 团队维护着供 PMC(项目管理委员会)、项目提交者和 Apache 董事会使用的各种工具。这些工具中的部分工具只提供给有特定职责或角色的人员使用。其他工具,如显示 Apache 基础设施各部分状态的监控工具,则向所有人开放。

为顶级项目(TLP)提供的服务

网站

这里只列出了几个挺有意思的连接,比如项目网址检查器,它会检查顶级项目是否有 License, Donate, Sponsors, Privacy 等正确的连接。

电子邮件

  • 所有新建电子邮件列表的申请都应通过自助服务系统进行。
  • 电子邮件服务器 - QMail/QSMTPD

Read More

2023 年终总结

时间过得很快,2023 年转瞬即逝。如果不记录下自己在这一年里发生的事情,过不了多久就很难回想起来这一年都发生过什么。

因此按照惯例还是要先回顾 2023 年,然后展望 2024 年。

回顾 2023

回顾这一年,我想用三个关键词来形容生活、工作以及业余。

生活中,是“奶爸”

从孩子一出生就是我和我的队友独立带娃,白天我上班,她带娃;晚上下班我火速回去接班、陪玩、家务直到孩子睡觉。周末至少有一天会带孩子出去溜达。

带娃的过程中会觉得辛苦,漫长,然而回顾这一年会发现孩子一眨眼就长大了。年初时候还只会爬、扶站;到了年末孩子已经能爬桌子能跑了,有消耗不完的能量。

接下来就是流水账的记录了,记录一下平凡一年中的小事件:

  • 四月:跟公司活动去了一趟发现王国、爬了童牛岭、玩了三国杀、在渔公码头吃了海鲜自助
  • 五月:在星海和庄河分别给孩子办了生日宴
  • 九月:第一次带娃住酒店,去了金石滩希尔顿住了一晚、吃了一顿酒店自助早餐
  • 十月:国庆回庄河住了一晚,吃了一顿家庭烧烤;回来去了一趟横山寺,吃了一顿自助素食餐;假期踢了一场球;办了大连森林动物园的卡开始打卡动物园
  • 十一月:去了大连森林动物园、旅顺太阳沟、大连自然博物馆、参加了公司在钱库里的聚餐
  • 十二月:收到非常突发的消息(以后有机会再细说)、参加组内团建、大连博物馆、陪爸爸住院检查、逛旅顺博物馆

工作中,是“最佳实践”的坚守着

这一年我依旧坚持 DevOps 最佳实践:

  1. 继续拓展 Ansible Playbook 仓库的应用范围
  2. 创建了 Infrastructure as Code 仓库,用 Code 来管理 Infra
  3. 创建了 Docker Image 仓库来容器化产品,在 Bitbucket 仓库中应用了很多我的 DevOps 实践
  4. 承担了更多产品的 Build 和 Release 工作
  5. 提出并实施了 Software Supply Chain Security 想法
  6. 在团队内部分享 DevOps 实践,以 Jenkins 共享库的形式分享给其他团队

业余时间,是“开源和写作”的爱好者

和去年一样,业余时间我还做同样的事情:

  1. 开源项目
  • cpp-linter-action 截至目前已经有 400 多个用户在使用,包括微软、Jupyter、Waybar、libvips、desktop、chocolate-doom 等知名开源项目,希望之后还有更多的想法去改进
  • commit-check 目前处在初期发展阶段,目前的用户很少,还需要优化它以及引入更多好的想法
  1. 写作 - 2023 年我一共更新了 20 篇博客 + 6 篇公众号文章,距离年初设定的 24(博客)+ 12(公众号)打了一些折扣
  2. 学习 - 加入的知名社区里学习和贡献这件事没有做到,有了孩子之后确实没有多少业余时间了,希望 2024 娃能早睡我能有更多自己的时间

展望 2024

每年的愿望或是 Flag 还是要设置的,万一实现了呢?

  1. 希望能顺利的度过职业发展期,希望会是一个崭新的、充满挑战的开始
  2. 家人身体健康,工作和家庭的平衡,带她们多出去走走
  3. 补足在 DevOps 一些方面的不足,争取参与到实际的项目中来获得提升
  4. 以教促学,持续在博客、公众号等分享,坚持个人成长
  5. 保持运动,不论是跑步还是踢球,把体重降下来

过去的年终总结

2022 年终总结
2020 年终总结
2019 年终总结
2018 从测试转开发


转载本站文章请注明作者和出处,请勿用于任何商业用途。欢迎关注公众号「DevOps攻城狮」

如何把 GitHub Release Notes 按照 New features、Bug Fixes ... 进行自动分类

如果你使用过 GitHub 发布过项目,你会知道 GitHub 可以自动生成 Release Notes

就像这样 GitHub 自动生成的 Release Notes。

Example 1

这个截图里的 Release Notes 内容很少,看起来还很清晰。但如果内容很多,以 Jenkinsci 组织下的 configuration-as-code-plugin 项目为例,可以看出来这里的 Release Notes 中的内容是按照标题进行分类的,假如这些内容混在一起将会非常糟糕的体验。(不要误以为这是手动进行分类的,程序员才不愿意干这种事😅)

Example 2

本文将分享针对需要对 GitHub Release Notes 的内容按照标题进行自动分类的两种方式。

方式一:使用 GitHub 官方提供的功能

方式一是通过 GitHub 提供的功能对 Release Notes 进行自动分类,即在仓库下面创建配置文件 .github/release.yml。这个功能与 GitHub 的 Issue Template 和 Pull Request Template 类似。具体的配置选项可以参考官方文档

以下我是在 commit-check-action 项目的配置

changelog:
exclude:
labels:
- ignore-for-release
categories:
- title: '🔥 Breaking Changes'
labels:
- 'breaking'
- title: 🏕 Features
labels:
- 'enhancement'
- title: '🐛 Bug Fixes'
labels:
- 'bug'
- title: '👋 Deprecated'
labels:
- 'deprecation'
- title: 📦 Dependencies
labels:
- dependencies
- title: Other Changes
labels:
- "*"

针对上面的示例,在添加了 .github/release.yml 配置文件之后,当再次生成 Release Notes 时就会自动将其内容进行自动归类(下图中的标题 📦 Dependencies 是自动添加的)

Example 3

方式二:使用 Release Drafter

方式二是使用 Release Drafter,即在仓库创建配置文件 .github/release-drafter.yml

从 Release Drafter 项目提供的配置参数可以看出来它提供的功能更多,使用也更加复杂。另外它还支持将配置文件放到组织下的中央仓库 .github 来实现统一的配置、并将其共享给其他仓库。

目前方式一 .github/release.yml 不支持通过中央仓库 .github 来实现统一的配置,详见这个讨论

这里还以 jenkinsci/configuration-as-code-plugin 为例看到它的 .github/release-drafter.yml 的配置。

_extends: .github

这个配置的 _extends: .github 表示从中央仓库 .github/.github/release-drafter.yml 继承过来的配置。

# Configuration for Release Drafter: https://github.com/toolmantim/release-drafter
name-template: $NEXT_MINOR_VERSION
tag-template: $NEXT_MINOR_VERSION
# Uses a more common 2-digit versioning in Jenkins plugins. Can be replaced by semver: $MAJOR.$MINOR.$PATCH
version-template: $MAJOR.$MINOR

# Emoji reference: https://gitmoji.carloscuesta.me/
# If adding categories, please also update: https://github.com/jenkins-infra/jenkins-maven-cd-action/blob/master/action.yaml#L16
categories:
- title: 💥 Breaking changes
labels:
- breaking
- title: 🚨 Removed
labels:
- removed
- title: 🎉 Major features and improvements
labels:
- major-enhancement
- major-rfe
- title: 🐛 Major bug fixes
labels:
- major-bug
- title: ⚠️ Deprecated
labels:
- deprecated
- title: 🚀 New features and improvements
labels:
- enhancement
- feature
- rfe
- title: 🐛 Bug fixes
labels:
- bug
- fix
- bugfix
- regression
- regression-fix
- title: 🌐 Localization and translation
labels:
- localization
- title: 👷 Changes for plugin developers
labels:
- developer
- title: 📝 Documentation updates
labels:
- documentation
- title: 👻 Maintenance
labels:
- chore
- internal
- maintenance
- title: 🚦 Tests
labels:
- test
- tests
- title: Other changes
# Default label used by Dependabot
- title: 📦 Dependency updates
labels:
- dependencies
collapse-after: 15
exclude-labels:
- reverted
- no-changelog
- skip-changelog
- invalid

template: |
<!-- Optional: add a release summary here -->
$CHANGES

replacers:
- search: '/\[*JENKINS-(\d+)\]*\s*-*\s*/g'
replace: '[JENKINS-$1](https://issues.jenkins.io/browse/JENKINS-$1) - '
- search: '/\[*HELPDESK-(\d+)\]*\s*-*\s*/g'
replace: '[HELPDESK-$1](https://github.com/jenkins-infra/helpdesk/issues/$1) - '
# TODO(oleg_nenashev): Find a better way to reference issues
- search: '/\[*SECURITY-(\d+)\]*\s*-*\s*/g'
replace: '[SECURITY-$1](https://jenkins.io/security/advisories/) - '
- search: '/\[*JEP-(\d+)\]*\s*-*\s*/g'
replace: '[JEP-$1](https://github.com/jenkinsci/jep/tree/master/jep/$1) - '
- search: '/CVE-(\d{4})-(\d+)/g'
replace: 'https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-$1-$2'
- search: 'JFR'
replace: 'Jenkinsfile Runner'
- search: 'CWP'
replace: 'Custom WAR Packager'
- search: '@dependabot-preview'
replace: '@dependabot'

autolabeler:
- label: 'documentation'
files:
- '*.md'
branch:
- '/docs{0,1}\/.+/'
- label: 'bug'
branch:
- '/fix\/.+/'
title:
- '/fix/i'
- label: 'enhancement'
branch:
- '/feature\/.+/'
body:
- '/JENKINS-[0-9]{1,4}/'

以上是中央仓库的 .github/.github/release-drafter.yml 配置,可以看到 Jenkins 官方使用了很多特性,比如模板、替换、自动加 label 等,需要在通读 Release Drafter 的文档之后能更好的理解和使用。

总结

以上两种方式都可以帮助你在自动生成 Release Notes 的时候自动进行标题分类,但两者有一些如下差别,了解它们可以帮助你更好的进行选择。

  1. GitHub 官方提供的方式更容易理解和配置,可以满足绝大多数的项目需求。主要的不足是不支持从中央仓库 .github 中读取 .github/release.yml
  2. Release Drafter 提供了更为强大的功能,比如模板、排序、替换、自动对 pull request 加 label 等等,尤其是可以通过中央仓库来设置一个模板,其他项目来继承其配置。

如果是大型的开源组织,Release Drafter 是更好的选择,因为它提供了强大的功能以及支持继承中央仓库配置。如果是个人项目,GitHub 官方提供的方式基本满足需求。

以上就是我对两个生成 GitHub Release Notes 并进行自动分类的分享。

如果有任何疑问或建议欢迎在评论区留言。


转载本站文章请注明作者和出处,请勿用于任何商业用途。欢迎关注公众号「DevOps攻城狮」

How to make Jenkins pipeline not fail if a specific error occurs

Sometimes you don’t want Jenkins pipeline failed for a specific error occurs. so you can use catchError to catch error and update stage or build result to SUCCESSFUL or UNSTABLE or FAILURE (if you want)

Catch Error Jenkins pipeline

Here is the Jenkinsfile of pipeline

pipeline {
agent { node { label 'linux' } }

stages {
stage('Catch Error') {
steps {
catchError(buildResult: 'UNSTABLE', stageResult: 'UNSTABLE', message: 'abc: command not found') {
sh "abc"
}
}
}
}
}

Here is the output of pipeline

17:14:07  [Pipeline] Start of Pipeline
17:14:08 [Pipeline] node
17:14:08 Running on linux in /agent/workspace/Stage-Job/catch-error
17:14:08 [Pipeline] {
17:14:08 [Pipeline] stage
17:14:08 [Pipeline] { (Catch Error)
17:14:08 [Pipeline] catchError
17:14:08 [Pipeline] {
17:14:08 [Pipeline] sh
17:14:08 + abc
17:14:08 /agent/workspace/Stage-Job/catch-error@tmp/durable-303b03ca/script.sh: line 1: abc: command not found
17:14:08 [Pipeline] }
17:14:08 ERROR: abc: command not found
17:14:08 ERROR: script returned exit code 127
17:14:08 [Pipeline] // catchError
17:14:08 [Pipeline] }
17:14:08 [Pipeline] // stage
17:14:08 [Pipeline] }
17:14:08 [Pipeline] // node
17:14:08 [Pipeline] End of Pipeline
17:14:08 Finished: UNSTABLE

转载本站文章请注明作者和出处,请勿用于任何商业用途。欢迎关注公众号「DevOps攻城狮」

How to adopt Supply Chain Security for GitHub and Non-GitHub projects

Why Software Supply Chain Security is important?

Software supply chain security is the act of securing the components, activities, and practices involved in creating software.

Attacks in the software supply chain have become more and more frequent in recent years, SonaType reported more than 700% of attacks in open-source software from 2019 to 2022.

SonaType reported

In this Google Security Blog, there are many real examples of software supply chain attacks that pose growing threats to users and Google proposed a solution called SLSA in 2021.

Also, some well-known organizations such as Linux Foundation and CNCF have created standards and tools to address the issue of how to produce trusted software and attestations.

LF & CNCF

Based on this background, many organizations want to incorporate best practices from the open-source community into our CICD pipeline.

How to adopt Supply Chain Security for GitHub and Non-GitHub projects

Next, I will show you how to adopt on both GitHub and Rocket Bitbucket as an example to show you how we integrate software supply chain security

GitHub projects

On GitHub, the easiest and most popular option is to use slsa-github-generator, a tool provided by the official slsa-framework for native GitHub projects to create attestations during the build process and upload signed attestations to Rekor a transparency log system created by Sigstore. Here is the demo reposistory for reference.

Before installing your product package, the user can download the package and verify the provenance file at the end of .intoto.jsonl first, then run the following command manually or in their CI pipeline to verify whether the artifact is tampered with or not

bash-4.4$ slsa-verifier verify-artifact test-1.0.0-py3-none-any.whl --provenance-path test-1.0.0-py3-none-any.whl.intoto.jsonl --source-uri github.com/shenxianpeng/slsa-provenance-demo
Verified signature against tlog entry index 49728014 at URL: https://rekor.sigstore.dev/api/v1/log/entries/24296fb24b8ad77af7063689e8760fd7134f37e17251ec1d5adc16af64cb5cb579493278f7686e77
Verified build using builder "https://github.com/slsa-framework/slsa-github-generator/.github/workflows/generator_generic_slsa3.yml@refs/tags/v1.9.0" at commit fb7f6df9f8565ed6fa01591df2af0c41e5573798
Verifying artifact test-1.0.0-py3-none-any.whl: PASSED

PASSED: Verified SLSA provenance

Non-GitHub projects

However, there are many organizations’ codes are hosted on Non-GitHub SCM, so you can use the Witness, a tool from CNCF in-toto, which can help us generate and verify attestations.

It’s easy to scale Witness to your products, just integrate witness command into the existing build command it will generate proof of the software build and release execution process and can be verified.

You can follow this demo to integrate with witness, then will generate the build package along with attestations file, policy-signed.json file, and a public key.

Before user installing your product package, they can run the following command manually or in their CI pipeline to verify whether the artifact is tampered or not.

witness verify -f dist/witness_demo-1.0.0-py3-none-any.whl -a witness-demo-att.json -p policy-signed.json -k witness-demo-pub.pem
INFO Using config file: .witness.yaml
INFO Verification succeeded
INFO Evidence:
INFO 0: witness-demo-att.json

转载本站文章请注明作者和出处,请勿用于任何商业用途。欢迎关注公众号「DevOps攻城狮」

Witness 和 SLSA 💃

由于近些年针对软件的供应链的攻击越来越频繁,因此 Google 在 2021 提出的解决方案是软件工件供应链级别(Supply chain Levels for Software Artifacts,”SLSA”)

本篇将介绍在非 GitHub 生态系统中,我们如何生成和验证软件工件的来源,从而提高你的项目的 SLSA Level。

Witness 是一个可插拔的软件供应链风险管理框架,它能自动、规范和验证软件工件出处。它是 in-toto 是 CNCF 下的项目之一。它的最初作者是 Testifysec,后来捐赠给了 in-toto

什么是 Witness

Witness 是一个可插拔的供应链安全框架,可创建整个软件开发生命周期(SDLC)的证据(Provenance)跟踪,确保软件从源代码到目标的完整性。它支持大多数主要的 CI 和基础架构提供商,是确保软件供应链安全的多功能、灵活的解决方案。

安全 PKI (Public Key Infrastructure - 公钥基础设施)分发系统的使用和验证 Witness 元数据的能力进一步增强了流程的安全性,并有助于减少许多软件供应链攻击向量。

Witness 的工作原理是封装在持续集成流程中执行的命令,为软件开发生命周期(SDLC)中的每个操作提供证据跟踪,这样就可以详细、可验证地记录软件是如何构建的、由谁构建以及使用了哪些工具。

这些证据可用于评估政策合规性,检测任何潜在的篡改或恶意活动,并确保只有授权用户或机器才能完成流程中的某一步骤。

总结 - Witness 可以做什么

  • 验证软件由谁构建、如何构建以及使用了哪些工具
  • 检测任何潜在的篡改或恶意活动
  • 确保只有经授权的用户或机器才能完成流程的每一步
  • 分发证词(Attestations)和策略(Policy)

如何使用 Witness

主要分三步:

  1. witness run - 运行提供的命令并记录有关执行的证词。
  2. witness sign - 使用提供的密钥签署提供的文件。
  3. witness verify - 验证 witness 策略。

快速开始

这是我创建的 Witness Demo 仓库用于演示 witness 的工作流程,具体可以根据如下步骤进行。

Read More