最近开车的时候我总爱听赵雷的歌,尤其是那首《我记得》。
我觉得这首歌就是回忆的交响曲,每每听到就仿佛看到了一部老电影。它像是一种声音,一种触动人心的触感,让我们回忆起那些已经消逝的时光,反思我们的生活方式和人生的方向。
今天(6月28日)是我在Rocket中国分公司的最后一天,也是效力的第十个年头。这是我职业生涯中效力过最长的一家公司,想借此机会写下一些文字,为这十年画上一个句号。
光阴似箭,岁月如梭。转眼间,十年悄然逝去。唯有认真努力地生活,才能不被时光的流逝所感叹。我一直很喜欢的一句话是:“种一棵树最好的时间是十年前,其次是现在。
软件真是个有趣又深奥的东西,它由看似神奇的代码片段组成,这些代码运行在最终的终端上,本身却并非生命体,但拥有自己的生命周期。
软件最初是源代码的形式,仅仅是存放在某个仓库的文本文件,然后通过独特的构建过程,这些源代码会转变为其他形式。例如交付到 web 服务器的压缩 JavaScript 代码块、包含框架代码和业务逻辑的容器镜像,或者针对特定处理器架构编译的原始二进制文件。
这种最终的形态转变,也就是源代码生成的其他形式,通常被称为“软件制品”。在创建之后,制品通常会处于休眠状态,等待被使用。它们可能会被放置在软件包注册表(例如 npm、RubyGems、PyPI 等)或容器注册表(例如 GitHub Packages、Azure Container Registry、AWS ECR 等)中,也可能作为附加到 GitHub 版本发布的二进制文件,或者仅仅以 ZIP 文件的形式存储在某个 Blob 存储服务中。
最终,有人会决定拾取该制品并使用它。他们可能会解压缩包、执行代码、启动容器、安装驱动程序、更新固件 - 无论采用何种方式,构建完成的软件都将开始运行。
这标志着生产生命周期的顶峰,该周期可能需要大量人力投入、巨额资金,并且鉴于现代世界依赖软件运行,其重要性不言而喻。
然而,在许多情况下,我们并不能完全保证所运行的制品就是我们构建的制品。制品经历的旅程细节要么丢失,要么模糊不清,很难将制品与其来源的源代码和构建指令联系起来。
这种缺乏对制品生命周期的可见性是当今许多最严峻的安全挑战的根源。在整个软件开发生命周期 (SDLC) 中,有机会保护代码转换为制品的流程 - 如此一来,可以消除威胁行为者破坏最终软件并造成严重后果的风险。一些网络安全挑战似乎难以成功应对,但这种情况并非如此。让我们深入了解一些背景知识。
上次我在 代码签名(Code Signing)的文章中时候提到了 GaraSign,这是我在工作中使用到的另一个代码签名工具。
鉴于关于 GaraSign 的使用并没有多少中文资料,本篇我将介绍关于 GaraSign 的一些实线,希望对你有帮助。
Python 软件基金会 (PFS) 或许大家比较熟知,它是开源 Python 编程语言背后的组织,致力于为 Python 和 Python 社区的发展壮大创造条件。
继上次我们看完了 Apache 的基础设施介绍,本篇文章我们一起来看看 Python 软件基金会 (PFS) 的基础设施,看看可以从中学到哪些。
当谈到软件开发和安全性时,Code Signing(代码签名)是一个至关重要的概念。在这篇文章中,我们将探讨什么是代码签名,为什么它重要,以及两个代码签名工具的对比。
代码签名是一种数字签名技术,用于验证软件或代码的真实性和完整性。它通过使用加密技术,为软件文件附加一个数字签名,证明该文件是由特定的开发者创建并未被篡改过。
代码签名的过程通常涉及以下步骤:
今天翻译一篇我在 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é 喜欢和家人一起到户外散步、阅读和观看自己喜欢的节目。
相信大家最近都总会看到这样或那样的新闻:哪个科技巨头又裁员了。裁员潮似乎成为了这个时代的常态,让许多打工人感到焦虑和不安。
身在大连的我确实深有感触,外企和私企都有在裁员,与前两年相比,岗位越来越少,失业的人越来越多,因此想找到一个满意的岗位将会变得越来越难。
如果你使用过 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 中管理和组织工作流程变得更加灵活和可维护。
最近看到一篇非常有信息量的关于人工智能、云原生、开源的趋势报告,出自于GitHub,翻译并分享给大家,以下是报告全文。
作为 cpp-linter 的创建者和贡献者,我很高兴地宣布 —— cpp-linter-action 从 v2.9.0 版本开始支持 Pull Request Review 功能了 👏
以下是 cpp-linter-action 的 release notes。
其中 Bump cpp-linter from 1.6.5 to 1.7.1 by @dependabot in #191 是其中最重要的变化。注:cpp-linter 包是 cpp-linter-action 的核心依赖。
本篇介绍的是大名鼎鼎的开源软件基金会 Apache 所使用的服务(Services)和工具(Tools),这或许能帮助你打开视野,在选择工具的时候提供参考。如果你是一名 DevOps、SRE 或是 Infra 工程师,通过本篇文章内容结果帮助你更好的展示团队所提供的服务有哪些,以及窥探到 Apache Infra 是怎样组织和管理他们的。
如果你不太了解 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 基础设施各部分状态的监控工具,则向所有人开放。
这里只列出了几个挺有意思的连接,比如项目网址检查器,它会检查顶级项目是否有 License, Donate, Sponsors, Privacy 等正确的连接。
如果你使用过 GitHub 发布过项目,你会知道 GitHub 可以自动生成 Release Notes。
就像这样 GitHub 自动生成的 Release Notes。
这个截图里的 Release Notes 内容很少,看起来还很清晰。但如果内容很多,以 Jenkinsci 组织下的 configuration-as-code-plugin 项目为例,可以看出来这里的 Release Notes 中的内容是按照标题进行分类的,假如这些内容混在一起将会非常糟糕的体验。(不要误以为这是手动进行分类的,程序员才不愿意干这种事😅)
本文将分享针对需要对 GitHub Release Notes 的内容按照标题进行自动分类的两种方式。
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)