告别Rocket中国,回连十年再启程

​今天(6月28日)是我在Rocket中国分公司的最后一天,也是效力的第十个年头。这是我职业生涯中效力过最长的一家公司,想借此机会写下一些文字,为这十年画上一个句号。

光阴似箭,岁月如梭。转眼间,十年悄然逝去。唯有认真努力地生活,才能不被时光的流逝所感叹。我一直很喜欢的一句话是:“种一棵树最好的时间是十年前,其次是现在。

受同事的影响,从加入到公司以后我开始爱上软件这个行业,也想成为别人眼中的技术专家。我从最初的测试工程师转为开发人员,最终投身于DevOps领域,在这个过程中收获了快乐和成就。

十年征程,感恩有你。在Rocket中国的十年里,我结识了众多优秀的同事和朋友,从他们身上我学到了很多,也受到了他们的深刻影响。

无数次的团队聚餐、活动、旅游、足球、羽毛球、游泳等等,感谢你们一路的相伴,让这段旅程更加精彩和难忘。

也感谢我的家人,一直以来对我的包容、理解、支持和爱。是你们给了我坚强的后盾,让我无畏前行。感谢这十年里所有美好的回忆。

三十年风雨,五座城市。三十年来,我辗转生活过五个城市:出生在辽宁庄河,大学就读于沈阳,第一份工作在上海,后来又在北京工作了三年。直到2014年,我从京东裸辞,回到了家乡大连。

大连是我最喜欢的城市之一,这里风景优美、气候宜人。我在这里买房、结婚、生子,完成了人生中许多重要的阶段。

天下没有不散的宴席。随着最后一天日期的临近,我的心情也变得复杂。

其中既有对未来的期待和憧憬,也有对挑战和未知的担忧,以及对家人的牵挂。我期待着自己、妻子和孩子都能在未来的道路上变得更好、更强;但从工作到生活,这无疑将充满挑战。我无法确定这一过程是否会顺利,也不确定需要多长时间。

选择欧洲,开启新篇章。或许有人会问,在国内难道不能养家糊口吗?为什么要跑到那么远的地方?其实,这并非对错之分,而是选择。一个人的选择往往与他的经历息息相关。

以前,我从未想过出国,直到加入Rocket中国之后,身边优秀的同事陆续带着家人和孩子去了澳大利亚、欧洲、日本等地。此外,我也有机会去美国出差、去日本旅游,看到了更加广阔精彩的世界。

这些经历逐渐在我心中萌生了一个想法:如果有机会走出去,那将是一次充满挑战和乐趣的人生体验。

我钦佩那些主动打破舒适圈的人,而我则一直被动地等待着机会的降临。如果机会来临,我愿意勇敢地尝试。

恰逢公司业务调整,项目要移至欧洲。对于其他人来说,这可能是一个坏消息,但对我而言,这是一个难得的机会。虽然这并非一个完美的契机,但人生哪有那么多完美呢?

这次机会将让我有机会在全英文的工作环境中锻炼自己;我的两岁女儿也将有机会接受不同的教育,开启她的第二甚至第三外语学习之旅。

对于我们一家来说,这都是一次全新的挑战和开始。虽然我们已经过了35岁,但我始终觉得,我们依然年轻,可以不断学习和探索,保持对世界的好奇心。

选择欧洲的另一个原因是,如果留在国内,程序员想要延续职业生涯到四十岁甚至五十岁、六十岁会非常困难,而在欧美国家相对容易一些。

此外,随着年龄的增长,我对“好公司”的定义也在不断变化。

比如刚毕业去上海工作时,我觉得SIMCom是最好的公司;后来去北京东软工作时,我觉得东软也还不错;再后来,我加入了京东,觉得这可能是我这辈子能加入的最好的公司了;直到我加入到现在这家外企,这十年来我一直觉得这才是一家好公司。

如果还按照现在的标准在大连甚至其他城市来寻找新的工作,恐怕只能在梦里才能实现了。


最后,感谢在Rocket中国这十年里遇到的每一位朋友和同事。

衷心感谢每位同事的临别前的问候和祝福。

希望未来我们在人生的旅途上能够再次相聚。

再见!👋


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

你的软件究竟从哪里来?

软件真是个有趣又深奥的东西,它由看似神奇的代码片段组成,这些代码运行在最终的终端上,本身却并非生命体,但拥有自己的生命周期。

软件最初是源代码的形式,仅仅是存放在某个仓库的文本文件,然后通过独特的构建过程,这些源代码会转变为其他形式。例如交付到 web 服务器的压缩 JavaScript 代码块、包含框架代码和业务逻辑的容器镜像,或者针对特定处理器架构编译的原始二进制文件。

这种最终的形态转变,也就是源代码生成的其他形式,通常被称为“软件制品”。在创建之后,制品通常会处于休眠状态,等待被使用。它们可能会被放置在软件包注册表(例如 npm、RubyGems、PyPI 等)或容器注册表(例如 GitHub Packages、Azure Container Registry、AWS ECR 等)中,也可能作为附加到 GitHub 版本发布的二进制文件,或者仅仅以 ZIP 文件的形式存储在某个 Blob 存储服务中。

最终,有人会决定拾取该制品并使用它。他们可能会解压缩包、执行代码、启动容器、安装驱动程序、更新固件 - 无论采用何种方式,构建完成的软件都将开始运行。

这标志着生产生命周期的顶峰,该周期可能需要大量人力投入、巨额资金,并且鉴于现代世界依赖软件运行,其重要性不言而喻。

然而,在许多情况下,我们并不能完全保证所运行的制品就是我们构建的制品。制品经历的旅程细节要么丢失,要么模糊不清,很难将制品与其来源的源代码和构建指令联系起来。

这种缺乏对制品生命周期的可见性是当今许多最严峻的安全挑战的根源。在整个软件开发生命周期 (SDLC) 中,有机会保护代码转换为制品的流程 - 如此一来,可以消除威胁行为者破坏最终软件并造成严重后果的风险。一些网络安全挑战似乎难以成功应对,但这种情况并非如此。让我们深入了解一些背景知识。

哈希值和签名

假设你的目录中有一个文件,并且你想要确保它明天与今天完全相同。你该怎么做?一个好的方法是通过安全的哈希算法生成文件的哈希值。

以下是如何使用 OpenSSL 和 SHA-256 算法完成此操作:

openssl dgst -sha256 ~/important-file.txt

现在,你拥有了一个哈希值(也称为散列值),它是一个由字母和数字组成的 64 字符字符串,代表该文件的唯一指纹。只要更改该文件中的任何内容,然后再次运行哈希函数,你就会得到不同的字符串。你可以将哈希值写在某个地方,然后第二天回来尝试相同的过程。如果你两次没有得到相同的哈希值字符串,则文件中的某些内容已发生更改。

到目前为止,我们可以确定某个文件是否被篡改。如果我们想要对制品进行声明怎么办?如果我们想说“我今天看到了这个制品,我(系统或人)保证这个东西就是我看到的东西”,该怎么办?此时,你需要的是软件制品签名;你需要将哈希值字符串通过加密算法进行处理,以生成另一个字符串,代表使用唯一密钥“签名”该指纹的过程。
如果你随后希望其他人能够确认你的签名,则需要使用非对称加密:使用你的私钥签名哈希值,并提供相应的公钥,以便任何获取你文件的人都可以进行验证。

你可能已经知道,非对称加密是互联网上几乎所有信任的基础。它可以帮助你安全地与银行互动,也可以帮助 GitHub 安全地交付你的存储库内容。我们使用非对称加密来支持诸如 TLS 和 SSH 等技术,以创建可信赖的通信通道,但我们也使用它通过签名来创建信任软件的基础。

Windows、macOS、iOS、Android 等操作系统都具有用于确保可执行软件制品的可信来源的机制,方法是强制要求存在签名。这些系统是现代软件世界中极其重要的组件,构建它们非常困难。

不仅仅是签名 - 还要证明

当我们思考如何展示关于软件制品的更多可信赖信息时,签名是一个好的开端。它表示“某个可信赖的系统确实看到了这个东西”。但是,如果你真的想在整个软件开发生命周期 (SDLC) 的安全性方面取得重大进步,那么你就需要超越简单的签名,而是要考虑证明。

证明是一种事实断言,是对制品或制品所做的声明,并由可被认证的实体创建。之所以可以进行认证,是因为声明已签名,并且用于签名的密钥是可信的。

最重要和最基础的证明类型之一是断言有关制品来源和创建的事实 - 它来自的源代码和将源代码转换为制品的构建指令,我们称之为来源证明。

我们选择的来源证明规范来自 SLSA 项目。SLSA 是考虑软件供应链安全性的绝佳方式,因为它为软件的生产者和消费者提供了一个通用的框架,用于推理安全保证和边界,而这与特定的系统和技术栈无关。

SLSA 基于 in-toto 项目的工作,提供了一种用于生成软件制品来源证明的标准化架构。in-toto 是一个 CNCF 毕业项目,其存在目的之一是提供一系列有关供应链和构建过程的相关信息的标准化元数据架构。

构建这样的东西需要什么?

GitHub 作为托管大量代码和构建管道的全球最大软件开发平台,对此进行了大量的思考。构建认证服务需要许多活动部件。

这样做意味着有一种方法可以:

  • 颁发证书(本质上是绑定到某个经过身份验证的身份的公钥)。
  • 确保这些证书不会被滥用。
  • 在众所周知的上下文中启用工件的安全签名。
  • 以最终用户可以信任的方式验证这些签名。

这意味着设置证书颁发机构 (CA) 并拥有某种客户端应用程序,你可以使用它来验证与该颁发机构颁发的证书相关联的签名。

为了防止证书被滥用,你需要 (1) 维护证书吊销列表或 (2) 确保签名证书是短期的,这意味着需要某种时间戳机构的反签名(可以提供权威印章,表明证书仅在其有效期内用于生成签名)。

这就是 Sigstore 的作用所在,它是一个开源项目,提供 X.509 CA 和基于 RFC 3161 的时间戳机构。它还允许你使用 OIDC 令牌进行身份验证,许多 CI 系统已经生成了令牌并将其与其工作负载相关联。

Sigstore 对软件签名的作用与 Let’s Encrypt 对 TLS 证书的作用相同:使其简单、透明且易于采用。

GitHub 通过在技术指导委员会中的席位帮助监督 Sigstore 项目的治理,是服务器应用程序和多个客户端库的维护者,并且(与来自 Chainguard、Google、RedHat 和 Stacklok 的人员一起)组成了 Sigstore 公共物品实例的运营团队,该团队的存在是为了支持 OSS 项目的公共证明。

Sigstore 需要符合更新框架 (TUF) 规定的标准的安全信任根。这允许客户端跟上 CA 底层密钥的轮换,而无需更新其代码。TUF 的存在是为了缓解在现场更新代码时可能出现的大量攻击媒介。许多项目都使用它来更新长期运行的遥测代理、提供安全的固件更新等。

有了 Sigstore,就可以创建防篡改的纸质跟踪,将工件与 CI 联系起来。这一点非常重要,因为以无法伪造的方式签署软件和捕获出处细节,意味着软件消费者有办法执行他们自己的规则,以确定他们正在执行的代码的来源。

原文:https://github.blog/2024-04-30-where-does-your-software-really-come-from/


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

代码签名(Code Signing) - GaraSign

上次我在 代码签名(Code Signing)的文章中时候提到了 GaraSign,这是我在工作中使用到的另一个代码签名工具。

鉴于关于 GaraSign 的使用并没有多少中文资料,本篇我将介绍关于 GaraSign 的一些实线,希望对你有帮助。

代码签名

这里再次说明什么是代码签名。代码签名证书用于对应用程序、驱动程序、可执行文件和软件程序进行数字签名,客户可通过这种方式验证他们收到的代码未被网络罪犯和黑客篡改或破坏。签名后的交付产品结合了加密令牌和证书,用户可在安装产品前对其进行验证。代码签名可确认谁是软件作者,并证明代码在签名后未被修改或篡改。

Garasign 解决方案

GaraSign 是一个基于 SaaS 的安全协调平台,可对企业基础设施、服务和数据进行集中管理。GaraSign 可与所有主要操作系统、平台和工具的本地客户端集成,确保现有工作流不受干扰,同时改善其整体安全态势和合规性。

GaraSign 由以下组件组成:

  • 加密令牌 - 存储签名密钥的加密设备(通常是一个或多个 HSM - Hardware Security Modules)
  • GaraSign 签名服务器 - 位于存储签名密钥的加密令牌前的 REST 服务器
  • GaraSign Signing 客户端 - 允许与之集成的签名工具在本地散列数据并将签名生成脱载至 GaraSign Signing 服务器的客户端。

garasign components

Garasign 代码签名散列方法 - 大幅提高速度

garasign approach

安装 GaraSign

关于如何安装 GaraSign 这里不过去介绍,可以到官网找相关的安装文档。这里要注意目前 GaraSign 对操作系统版本的要求还是很高的,比如

  • Windows 最低要求是 Windows 2019, Win10 and Win11
  • Linux 最低要求是 RHEL 7.9, 8.0, 9.0,CentOS 7.9, 8.0, 9.0,Rocky 8.0

如果你的构建环境还是比较旧的或是不符合其支持的版本,建议你向我一样设置一台专用的 GaraSign 机器(推荐 Linux)。

如果你使用 Jenkins 来构建,可以将这台机器设置为一台 Jenkins agent,通过创建一个 Jenkins pipeline,这样其他所有的要需要发布的包都可以通过这个 pipeline 来进行签名。

如何签署独立签名

如果你已经设置好了 GaraSign 环境,以 Linux 为例,那么就可以通过下面的命令进行签署。

注:在 Windows 与 Linux 在签署不同的类型文件所使用到的命令不同,因此推荐在 Linux 进行签名会更加简单。

openssl dgst -sign <private key file> -keyform PEM -sha256 -out <signature-file-name.sig> -binary <binary file to sign>

具体的实施

加入你的 Artifacts 存在 Artifactory 上面,下面就 Jenkins 为例,来实施一个可以自动签名的 pipeline。包括:

  1. 从 Artifactory 上下载需要签名的 Artifacts
  2. 使用 GaraSign 进行签名
  3. 验证 GaraSign 是否成功
  4. 上传签名文件和公钥到 Artifactory 上的同一个目录下
pipeline{

agent {
node {
label 'garasign'
}
}

parameters {
string(
name: 'REPO_PATH',
defaultValue: '',
description: 'Repository Path on Artifactory. eg. generic-stage/test_repo/devel/54/mybuild_1.1.0_752d0821_64bit.exe'
)
}

environment {
BOT = credentials("BOT-credential")
ART_URL = "https://my.org.com/artifactory"
}

stages {
stage('GaraSign'){
steps {
script {
if (! params.REPO_PATH){
error "REPO_PATH can not empty, exit!"
}
// Update Job description
def manualTrigger = true
currentBuild.upstreamBuilds?.each { b ->
currentBuild.description = "Triggered by: ${b.getFullDisplayName()}\n${REPO_PATH}"
manualTrigger = false
}
if (manualTrigger == true) { currentBuild.description = "Manual sign: ${REPO_PATH}" }

sh '''
# download artifacts
curl -u${BOT_USR}:${BOT_PSW} -O ${ART_URL}/${REPO_PATH}
file_name=$(basename ${REPO_PATH})
repo_folder=$(dirname ${REPO_PATH})

# garasign
openssl dgst -sign grs.privkey.pem -keyform PEM -sha256 -out $file_name.sig -binary $file_name

# verify
grs.pem.pub.key
output=$(openssl dgst -verify grs.pem.pub.key -keyform PEM -sha256 -signature $file_name.sig -binary $file_name)
if echo "$output" | grep -q "Verified OK"; then
echo "Output is Verified OK"
else
echo "Output is not Verified OK"
exit 1
fi

# upload signature file (.sig) and public key (.pem.pub.key)
curl -u${BOT_USR}:${BOT_PSW} -T $file_name.sig ${ART_URL}/${repo_folder}/
curl -u${BOT_USR}:${BOT_PSW} -T grs.pem.pub.key ${ART_URL}/${repo_folder}/
'''
}
}
}
}
}

如何验证独立签名

还是以 Linux 为例,使用如下命令可以进行签名的验证。

openssl dgst -verify <public key file> -signature <signature> <file to verify>

当你的 Artifacts 已经进行了签名,在提供给客户的时候,你不但需要提供发布的包,而且需要提供签名文件 (.sig) 和公钥 (.pem.pub.key)。

举个例子,如下 CLI 产品分别提供了 Windows,Linux 和 AIX 三个平台的安装包,客户可以参考如下进行签名验证。

# 下载安装包、签名文件和公钥
$ ls
cli.pem.pub.key CLI_AIX_1.1.0.zip CLI_AIX_1.1.0.zip.sig CLI_LINUXX86_1.1.0.zip CLI_LINUXX86_1.1.0.zip.sig CLI_WINDOWS_1.1.0.zip CLI_WINDOWS_1.1.0.zip.sig

# 验证签名
openssl dgst -verify cli.pem.pub.key -signature CLI_AIX_1.1.0.zip.sig CLI_AIX_1.1.0.zip
Verified OK

openssl dgst -verify cli.pem.pub.key -signature CLI_LINUXX86_1.1.0.zip.sig CLI_LINUXX86_1.1.0.zip
Verified OK

openssl dgst -verify cli.pem.pub.key -signature CLI_WINDOWS_1.1.0.zip.sig CLI_WINDOWS_1.1.0.zip
Verified OK

# 当包和签名文件不符时会验证失败
openssl dgst -verify cli.pem.pub.key -signature CLI_AIX_1.1.0.zip.sig CLI_LINUXX86_1.1.0.zip
Verification Failure

以上就是关于 GaraSign 的实现分享,如有任何问题或是建议咱们评论区见。


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

Python 软件基金会 (PFS) 基础设施概览

Python 软件基金会 (PFS) 或许大家比较熟知,它是开源 Python 编程语言背后的组织,致力于为 Python 和 Python 社区的发展壮大创造条件。

继上次我们看完了 Apache 的基础设施介绍,本篇文章我们一起来看看 Python 软件基金会 (PFS) 的基础设施,看看可以从中学到哪些。

PSF 基础设施概述

PSF 运行各种基础设施服务来支持其使命,从 PyCon 站点CPython Mercurial 服务器。本页的目标是列举所有这些服务,它们在哪里运行,以及主要联系人是谁。

基础架构团队

基础架构团队最终负责维护 PSF 基础设施。但是,它不需要成为运行 PSF 服务的基础设施。事实上,大多数的日常运营服务由不在基础设施团队中的人员处理。这基础设施团队可以协助建立新服务并为维护人员提供建议的个别服务。其成员通常还处理对敏感的更改全球系统,例如 DNS。目前的团队成员是:

  • Alex Gaynor (has no responsibilities)
  • Benjamin Peterson
  • Benjamin W. Smith
  • Donald Stufft
  • Ee Durbin (PSF Director of Infrastructure)
  • Noah Kantrowitz

联系基础架构团队的最佳方式是发送邮件 infrastructure-staff@python。也经常有人在 Libera 的 #python-infra 频道联系他们。

基础设施提供商

PSF 为其基础架构使用多个不同的云提供商和服务。

Fastly
Fastly 慷慨捐赠其内容分发网络(CDN)到 PSF。我们最高的流量服务(即 PyPI, www.python.org, docs.python.org)使用此 CDN 来改善最终用户延迟。

DigitalOcean
DigitalOcean 是当前的主要托管对于大多数基础设施,此处部署的服务由 Salt 管理。

Heroku
Heroku 托管了许多 CPython 核心工作流机器人,短暂的或概念验证的应用程序,以及其他适合部署在 Heroku 的 Web 应用程序。

Gandi
Gandi 是我们的域名注册之星。

Amazon Route 53
Amazon Route 53 托管所有域的 DNS,它目前由基础设施人员手动管理。

DataDog
DataDog 提供指标、仪表板和警报。

Pingdom
Pingdom 提供监控,当服务中断时向我们投诉。

PagerDuty
PagerDuty 用于 PSF 的待命轮换基础设施员工在一线,志愿者作为后援。

OSUOSL
俄勒冈州立大学开源实验室举办一个 PSF 的硬件服务器,speed.python.org 用于运行基准测试,此主机是使用 Chef 和他们的配置管理位于 PSF-Chef Git 存储库中。

数据中心

PSF DC Provider Region
ams1 Digital Ocean AMS3
nyc1 Digital Ocean NYC3
sfo1 Digital Ocean SFO2

各种服务的详细信息

本部分列举了 PSF 服务、有关其托管的一般情况以及所有者的联系信息。

Buildbot
buildbot master 是由 python-dev@python 运行的服务。特别是 Antoine Pitrou and Zach Ware.

bugs.python.org
bugs.python.org 由 PSF 在 DigitalOcean 上托管,由 Roundup 提供支持。它还部署了 bugs.jython.org 和 issues.roundup-tracker.org。

docs.python.org
Python 文档托管在 DigitalOcean 上,通过 Fastly 提供。负责人是 Julien Palard。

hg.python.org
CPython Mercurial 存储库托管在 Digital Ocean VM 上。负责人是 Antoine Pitrou 和 Georg Brandl。

mail.python.org
python.org Mailman 实例托管在 https://mail.python.org 和 SMTP(Postfix)上。所有查询都应定向到 postmaster@python。

planetpython.org 和 planet.jython.org
它们托管在 DigitalOcean VM 上。Planet 代码和配置托管在 GitHub 上,并由团队在 planet@python。

pythontest.net
pythontest.net 托管 Python 测试套件。python-dev@python 对其最终负责维护。

speed.python.org
speed.python.org 是一个跟踪 Python 性能的 Codespeed 实例。Web 界面托管在 DigitalOcean VM 上,基准测试在 strongfy 上运行机器在 OSUOSL 上,由 Buildbot 主节点调度。由 speed@python 和 Zach Ware 维护。

wiki.python.org
它托管在 DigitalOcean VM 上。负责人是 Marc-André Lemburg。

www.jython.org
这是从 Amazon S3 存储桶托管的。设置非常简单,不应该需要很多调整,但基础设施工作人员如有需要可以对它进行调整。

www.python.org
主要的 Python 网站是一个 Django 应用程序,托管在 Heroku。它的源代码可以在 GitHub 上找到,并且该网站的问题可能是报告给 GitHub 问题跟踪器
Python 下载 (即 https://www.python.org/ftp/ 下的所有内容)都托管在单独的 DigitalOcean 虚拟机。整个网站都在 Fastly 后面。还有用于测试站点的 https://staging.python.org。http://legacy.python.org 是从静态镜像托管的旧网站。

PyCon
PyCon 网站托管在 Heroku 上。联系地址是 pycon-site@python。

PyPI
Python 包索引的负载最多 任何 PSF 服务。它的源代码可在 GitHub 上找到。
它的所有基础设施都在 由 pypi-infra 配置的 AWS,它以 Fastly 为首。基础设施是由 Ee Durbin, Donald Stufft, 和 Dustin Ingram 维护的,联系地址是 admin@pypi。

PyPy properties
PyPy 网站托管在 DigitalOcean VM 上并进行维护作者:pypy-dev@python。

如需要参看原文。可访问地址

最后

从 PFS 基础设施来看,他们更多的使用了 Cloud 服务商和技术来部署他们的应用。因此想要参与到 PFS 基础设施管理用,需要对 CDN,DigitalOcean,Heroku,Amazon Route 53,Amazon S3,DataDog,Pingdom 这些技术有比较深入的使用经验。

我们羡慕那些可以为开源软件全职工作的人,他们拿着薪水做着很多程序员都羡慕的事情。

但拥有这样的工作需要我们自己的技能可以匹配的上,并且积极主动的去寻求这些机会,才有可能得到一份全职开源软件工程师的职位。共勉!


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

代码签名(Code Signing)

当谈到软件开发和安全性时,Code Signing(代码签名)是一个至关重要的概念。在这篇文章中,我们将探讨什么是代码签名,为什么它重要,以及两个代码签名工具的对比。

什么是代码签名?

代码签名是一种数字签名技术,用于验证软件或代码的真实性和完整性。它通过使用加密技术,为软件文件附加一个数字签名,证明该文件是由特定的开发者创建并未被篡改过。

代码签名的过程通常涉及以下步骤:

  1. 生成数字证书:开发者使用数字证书来创建数字签名。证书通常由可信任的第三方证书颁发机构(CA)签发。
  2. 对软件进行签名:开发者使用专门的工具,如 Microsoft 的 SignTool 或 Apple 的 codesign 工具,对软件进行数字签名。
  3. 分发已签名的软件:带有数字签名的软件可以被分发到用户设备上。

为什么代码签名重要?

代码签名的重要性体现在以下几个方面:

  1. 完整性验证:代码签名可以确保软件在分发过程中未被篡改。用户可以通过验证签名来确认软件的完整性,确保软件来自可信任的来源。

  2. 身份验证:签名附带的数字证书可以用来验证软件的发布者身份。用户可以查看证书,了解软件的制造商,并评估其可信度。

  3. 安全性增强:通过数字签名,可以防止恶意软件插入合法软件包中,确保用户下载的软件是安全可靠的。

  4. 操作系统信任:大多数操作系统和应用商店要求开发者对软件进行代码签名才能发布。没有签名的软件可能会被视为不安全或不可信。

代码签名工具

我在工作中主要接触到两个 Code signing 工具,分别是代码签名证书Code Signing CertificatesGaraSign,它们是比较有代表性的两类工具。

这里简单介绍一下代码签名证书与 GaraSign 的区别:

代码签名证书GaraSign 都是用于验证软件完整性和来源的解决方案,但它们在工作方式和功能方面存在一些关键差异。

功能 代码签名证书 GaraSign
颁发者 受信的证书颁发机构 (CA) GaraSign
形式 数字证书 云服务
验证方法 加密哈希 加密哈希
功能 验证软件完整性、确保软件未被篡改 验证软件完整性、确保软件未被篡改、提供集中式管理、支持审计和合规性
成本 每年 100 美元到数千美元不等 按使用付费
管理 需要购买和管理证书 无需管理证书
可扩展性 适用于需要签署大量软件的组织 适用于任何规模的组织

总的来说,代码签名证书和 GaraSign 都是有效的解决方案,可用于验证软件完整性和来源。 最适合你的选择将取决于你的特定需求和预算。以下是一些需要考虑的因素:

  • 成本: 如果你需要签署大量软件,GaraSign 可能更具成本效益。
  • 可扩展性: 如果你需要签署大量软件,GaraSign 可能是更好的选择。
  • 审计和合规性: 如果你需要满足严格的审计和合规性要求,GaraSign 可能是更好的选择。
  • 易用性:从我目前使用体感来说代码签名证书更容易设置和使用。GaraSign 则需要搭建服务和安装、配置客户端,非常繁琐[^1]。

[^1]: 目前我还在初步使用 GaraSign 后续如果有必要,我会单独写一些篇关于它的使用体验文章。

其他签名工具还包括微软的 SignTool.exeDocker trust sign等,这里就不一一介绍了。

结论

通过代码签名,开发者可以增加软件的安全性和可信度,同时帮助用户避免恶意软件和篡改的风险。
在今天的数字化环境中,代码签名是保障软件完整性和安全性的重要一环,提高软件供应链安全。

更过关于软件供应链安全内容可以参考这一系列文章


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

【分享】通过 Jenkins-X 社区最终进入到 Jenkins 基础设施团队成为 SRE 的经历

今天翻译一篇我在 Jenkins Contributors 页面上看到的一篇文章。

其作者是 Hervé Le Meur,我早在关注 Jenkins-Infra 的项目的时候就关注到他,他是一个法国人。以下是关于他如何通过 Jenkins-X 社区最终进入到 Jenkins 基础设施团队成为 SRE 的经历。

说实话有点羡慕。希望这个分享能给每一个想加入开源、并且在开源组织中找到一份全职工作带来一点启发。

以下是我对原文的翻译:


Hervé Le Meur 是一名 SRE(网站可靠性工程师),目前是 Jenkins 基础设施团队的成员。他是通过 Jenkins X 进入开源社区的,随后转到 Jenkins 基础设施工作。

Hervé 的父亲是一名木匠,母亲是一名室内装潢师,他出身于一个模拟技术背景的家庭,但在六岁时就通过 Amstrad CPC 464 电脑第一次真正接触到了技术。

如今,在不从事 Jenkins 任务的时候,Hervé 喜欢和家人一起到户外散步、阅读和观看自己喜欢的节目。

在加入 Jenkins 之前,你的背景是什么?

大学毕业后,我在一家小型 B2B 营销咨询公司工作了 10 年,当时我是开发我们所用工具的万事通,但那里既没有 CI/CD,也没有开源。

之后,我进入一家建筑信息建模(BIM)软件公司,从软件开发人员做起。有些团队在使用 Jenkins,但对他们来说,当时的 Jenkins 看起来既麻烦又缓慢。

随着我逐渐成长为软件架构师,我的任务是基于 Jenkins X 建立一个新的 CI/CD,这花了我几个月的时间。
由于 Jenkins X 刚刚出炉,而我又是 Kubernetes 的新手,这项任务比预期的要困难得多,尤其是 Jenkins X 进入测试阶段后,我不得不多次重做大部分工作。

通过这项工作,我学到了很多关于 Kubernetes 和 CI/CD 的知识,同时也为 Jenkins X 做出了不少贡献。
被这份工作解雇后,我联系了 James StrachanJames Rawlings,他们给了我一个链接,让我从 CloudBees 公司的 Oleg Nenashev 那里获得一个职位空缺,也就是我现在的职位。

在我的脑海中,我是一名程序员,而不是系统管理员。因此,当 Mark Waite 解释说最后一轮面试将与人际网络有关时,我有点害怕。
我以为我会因此失去机会,因为这可能是不可能完成的任务。然而,当我与 Mark、Damien DuportalOlivier Vernin 面谈时,他们却问我如何将 CI/CD 与 Jenkins X 集成:这真是一次奇妙的经历。我们进行了有意义的讨论,这让我感觉更舒服,也让我更容易做出决定。

面试前15分钟,我收到了另一家公司( Damien 和 Jean-Marc Meessen 之前恰好在这家公司工作过)的最终录用通知,当时我犹豫了一下,但结果是最好的,因为我现在仍然是 Jenkins 项目的一员,这可以说是我梦寐以求的工作。

我还有过主持在线论坛的经验,所以社区部分的工作对我来说很熟悉。

你使用 Jenkins 多久了?

我从 Jenkins X 开始,但从未接触过 Jenkins 本身。除了共享 Jenkins 的名称外,它们没有任何共同之处。
我对 Jenkins 的预想是负面的。我认为它是一个笨重、过时、复杂的 Java 程序。这些印象都是我在以前的公司里从其他使用它的人那里听来的。然而,当我开始使用 Jenkins 后,这种对比简直是天壤之别。
我的先入之见是,与其他程序相比,它既笨重又缓慢。我并不是唯一一个认为 Jenkins 不一定是最好、最快或最新的项目的人,但事实证明,一旦我开始使用这个项目,我就错了。

为什么选择 Jenkins 而不是其他项目?

我并不一定选择 Jenkins,因为它是我工作的主要部分。当我开始查看 Tyler、Olivier、Damien 和 Mark 为 Jenkins 基础设施所做的工作时,我意识到 Jenkins 比我想象的要完善和高效得多。
我还喜欢我们使用 Jenkins 开发和发布 Jenkins 的事实。这种用法是独一无二的,因为大多数开源工具都不具备转发成功的能力。
Jenkins 花费了大量的时间和精力,以配合开发人员的流程和功能。在我看来,这是 Jenkins 成功的主要原因之一。Jenkins 还集成了 Terraform、Puppet、Kubernetes 和 Helmfile 等其他工具,但 Jenkins 仍然是这些工具的协调者。

对我来说,为 Jenkins 工作是我的最高成就,因为我一直喜欢创建和开发工具,即使不是开发 Jenkins 的核心。

加入 Jenkins 项目后,你看到 Jenkins 有哪些增长?

我们已经有越来越多的实例被定义为代码。因此,我们可以重新创建任何实例,而无需手动配置设置,这大大提高了我们的恢复能力。我们还在慢慢实现将 ci.jenkins.io 定义为代码并进行管理。

你对 Jenkins 的哪方面特别感兴趣?

现在,我正在重构 Jenkins 控制器和代理的官方 Docker 镜像的构建过程,这让我感到非常有趣。
我也喜欢在贡献者方面工作,因为这就像一个谜题,知道我需要达到什么目标以及我的起点会让我更愉快。

什么样的贡献最成功或最有影响力?

Basil Crow 提出了使用 SQLite 代替文件系统的有趣想法。改用 JDK 17 非常成功,随着 JDK 21 的推出,Jenkins 可以在更新的平台上运行,并跟上时代的进步。
由于我们喜欢让 Jenkins 基础架构保持领先(例如始终运行最新的 Jenkins Weekly),下一步将引入 JDK22。插件健康分数标识对于可视化整个插件生态系统的健康状况非常有用。

给新开发人员和开源社区新成员的建议

首先要提醒我的是项目的庞大性,并指示我一开始要选择一件事来专注。

不要犹豫,大胆尝试;开源意味着对所有人开放。不要害怕提交 pull request,它并不需要完美无缺。

你可能最终会喜欢它,并继续提交贡献!


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

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攻城狮」