CI/CD 不是一次性的项目,而是一个不断演进的系统

今天这篇文章,起因是我看到前同事发的一条朋友圈。

同事的朋友圈

我感觉他这是在赤裸裸地夸我 :)
(不好意思,得瑟一下~)

不过说实话,这几年在 CI/CD 这块,我确实一直在做两件事:

  • 一边关注行业里最新的实践;
  • 一边筛选出适合我们业务的部分落地实施,或者写文章进行分享。

但我发现一个常见的误区是:

很多人觉得 CI/CD 做完了就完了,是一劳永逸的事情。

其实并不是。

罗马不是一天建成的,CI/CD 也不是

不论是 CI/CD 流水线,还是底层的程序、工具、库、平台,它们都属于基础设施的一部分。基础设施的一个显著特点是:

需要长期投入与持续维护。

否则,哪怕你现在搭建得再好,几年之后,也会因为无人维护而变成一个臃肿、失控的“技术债堆积场”。最终不得不推翻重来。

举几个例子你就会明白:

如果不维护,风险很快就会显现

1. 安全风险:

如果你没关注 CVE-2024-23897,可能根本不知道你的 Jenkins 存在任意文件读取漏洞,有被攻击者入侵的风险。

2. 功能缺失与兼容性问题:

不看 Jenkins 的更新日志,可能会错过一些关键修复或新特性;
不更新 CI/CD 工具链,代码可能突然就编译不了了,测试也不再通过。

3. 技术债积累与维护成本上升:

没有引入新的实践和工具,流水线就会越来越复杂、难维护,开发体验也会越来越差。

再来看 Python 项目这边

1. 依旧使用 setup.py?

那你可能错过了 PEP 518 推出的 pyproject.toml 所带来的统一构建生态。

2. 依旧用 pip install 安装 CLI 工具?

那你可能还不了解 pipx 和 uvx 能如何更方便、高效地管理工具依赖。

3. 不了解 PEP、不了解包结构和发布规范?

那很容易写出不规范、难以维护、别人无法复用的代码。

这些问题,表面上看似无伤大雅,但背后隐藏的是维护成本、团队协作效率以及项目未来发展的可持续性。

所以说,重构是软件工程的日常功课

很多时候,这些工作并不显眼,甚至容易被认为是“做多了”“瞎折腾”或“浪费时间”。

但实际上,恰恰是这些“隐性的工作”,才是软件工程真正的根基。

没有重构,系统只会越来越臃肿;
没有持续进化,CI/CD 迟早变成一个烂摊子;
没有持续学习和探索,就会离最佳实践越来越远。

所以,希望这篇文章能给你一点启发:

CI/CD 不是一次性的建设项目,而是一个持续演进、不断重构和成长的 DevOps 系统。

如果你也正在做这些“看不见的工作”,别灰心。你正在为整个系统的长期可持续打下基础。

你是否也遇到过相关的坑?欢迎留言分享你的故事。


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