当 CI 或更糟的是生产发生灾难性故障时，“在我的计算机上工作”一直是毫无帮助的答案。除其他外，Nix 是一种通过提供可重复、声明性和可靠的系统来解决此问题的方法。这使得它成为通常称为 DevOps 的两个方面的绝佳工具：操作系统的开发和流程。这篇文章将通过一个实际示例展示这两个方面，但首先，让我们从鸟瞰的角度看看这些承诺到底意味着什么。
Commit Check 更新：新增两个实用功能提升代码质量保障
最近有用户提出两个需求：一是支持在 Pull Request 中增加评论，二是检查 Pull Request 是否已经 rebase。
经过几晚的努力，现在正式宣布在最新的 commit-check 以及 commit-check-action 中新增两个重要功能：pr-comments 和 base-merge。
这两个功能旨在进一步提升 Pull Request (PR) 的检查能力。
PowerShell is not recognized as an internal or external command
Recently, while setting up a new Windows Server 2022, I encountered an issue where my Ansible playbook, which previously worked without problems, failed to execute.
Here’s the configuration I used for the Windows host in my Ansible inventory:
从早到晚，我的 DevOps 一天
What Optimizations I Made During the Jenkins Upgrade
Background
Recently, I’ve been working on migrating and upgrading Jenkins. The main motivation is the vulnerability CVE-2024-23897.
Jenkins 2.441 and earlier, LTS 2.426.2 and earlier does not disable a feature of its CLI command parser that replaces an ‘@’ character followed by a file path in an argument with the file’s contents, allowing unauthenticated attackers to read arbitrary files on the Jenkins controller file system.
To address this, Jenkins needs to be upgraded to at least version 2.442 or LTS 2.426.3 or above. This was also an opportunity to rework parts of the setup that weren’t initially optimized.
从 Jenkins 升级，我做了哪些优化
背景
我最近在做的一件事情是迁移并升级 Jenkins。主要动机是因为这个漏洞 CVE-2024-23897
Jenkins 2.441 及更早版本、LTS 2.426.2 及更早版本未禁用其 CLI 命令解析器的一项功能，该功能会将参数中文件路径后的“@”字符替换为文件内容，从而允许未经身份验证的攻击者读取 Jenkins 控制器文件系统上的任意文件。
因此需要将 Jenkins 至少升级到 2.442 或 LTS 2.426.3 及以上版本，也趁此机会重新重构之前没有做满意的部分。
DevOps进阶：揭秘首席DevOps工程师的职责与技能
想象一下，你是一名 DevOps 工程师，不论初级、中级还是高级，老板总有一天拍拍你的肩膀说：“加油干，兄弟，未来你就是我们的首席 DevOps 工程师了！”你可能会心想：“啥是首席 DevOps？这是个什么新饼？”
今天就带你了解一下，所谓的“首席 DevOps 工程师”到底干啥，职责是什么？
我们一起看看，顺便找准未来的职业发展方向。毕竟，谁都希望能进阶到高级角色嘛，对吧？
约定式分支规范中文版正式发布！
上周正式发布《约定式分支规范》后，受到了广泛关注，不少人询问何时推出中文版。
经过一周末的努力，中文版已正式上线，详情请访问：https://conventional-branch.github.io/zh/。
此外，我们对原始版本进行了部分细微调整。以下为《约定式分支规范》中文版的完整内容。
Conventional Branch Specification Released!
Summary
Conventional Branch refers to a structured and standardized naming convention for Git branches which aims to make branch more readable and actionable. We’ve suggested some branch prefixes you might want to use but you can also specify your own naming convention. A consistent naming convention makes it easier to identify branches by type.
初步了解 PyPA（Python Packaging Authority）下的知名项目和关系
PyPA（Python Packaging Authority）是管理和维护 Python 包相关工具的一个社区组织。PyPA 管理的知名项目包括 pip、packaging、setuptools、wheel、twine、build 等等。了解这些项目的关于有助于我们更好的了解 Python 的生态系统。
以下是这些项目的介绍以及它们之间的关系：
告别Rocket中国，回连十年再启程
今天（6月28日）是我在Rocket中国分公司的最后一天，也是效力的第十个年头。这是我职业生涯中效力过最长的一家公司，想借此机会写下一些文字，为这十年画上一个句号。
光阴似箭，岁月如梭。转眼间，十年悄然逝去。唯有认真努力地生活，才能不被时光的流逝所感叹。我一直很喜欢的一句话是：“种一棵树最好的时间是十年前，其次是现在。
你的软件究竟从哪里来？
软件真是个有趣又深奥的东西，它由看似神奇的代码片段组成，这些代码运行在最终的终端上，本身却并非生命体，但拥有自己的生命周期。
软件最初是源代码的形式，仅仅是存放在某个仓库的文本文件，然后通过独特的构建过程，这些源代码会转变为其他形式。例如交付到 web 服务器的压缩 JavaScript 代码块、包含框架代码和业务逻辑的容器镜像，或者针对特定处理器架构编译的原始二进制文件。
这种最终的形态转变，也就是源代码生成的其他形式，通常被称为“软件制品”。在创建之后，制品通常会处于休眠状态，等待被使用。它们可能会被放置在软件包注册表（例如 npm、RubyGems、PyPI 等）或容器注册表（例如 GitHub Packages、Azure Container Registry、AWS ECR 等）中，也可能作为附加到 GitHub 版本发布的二进制文件，或者仅仅以 ZIP 文件的形式存储在某个 Blob 存储服务中。
最终，有人会决定拾取该制品并使用它。他们可能会解压缩包、执行代码、启动容器、安装驱动程序、更新固件 - 无论采用何种方式，构建完成的软件都将开始运行。
这标志着生产生命周期的顶峰，该周期可能需要大量人力投入、巨额资金，并且鉴于现代世界依赖软件运行，其重要性不言而喻。
然而，在许多情况下，我们并不能完全保证所运行的制品就是我们构建的制品。制品经历的旅程细节要么丢失，要么模糊不清，很难将制品与其来源的源代码和构建指令联系起来。
这种缺乏对制品生命周期的可见性是当今许多最严峻的安全挑战的根源。在整个软件开发生命周期 (SDLC) 中，有机会保护代码转换为制品的流程 - 如此一来，可以消除威胁行为者破坏最终软件并造成严重后果的风险。一些网络安全挑战似乎难以成功应对，但这种情况并非如此。让我们深入了解一些背景知识。
代码签名（Code Signing） - GaraSign
上次我在 代码签名（Code Signing）的文章中时候提到了 GaraSign，这是我在工作中使用到的另一个代码签名工具。
鉴于关于 GaraSign 的使用并没有多少中文资料，本篇我将介绍关于 GaraSign 的一些实线，希望对你有帮助。