持续更新源代码并不像听起来那么令人生畏，而且是利用新功能和保护代码的最佳方式。
译自 Don't Sleep on Source Code Updates，作者 Evan Prowse。
回溯维护和更新源代码的步骤是一项艰巨的任务，特别是对于依赖于开源软件 (OSS) 且支持窗口有限的组织而言。随着时间的推移和代码的频繁发布，越来越难记住哪些是什么，使用了哪个版本以及为什么有人以这种方式编写代码。随着技术债务的累积，修复潜在问题或 CVE 变得越来越困难。此外，随着 OSS 框架和工具的演变，迁移到最新版本的所需工作量也越来越大。
在高度监管的行业中运营的组织面临着更大的挑战。为了遵守强制性规定和标准，升级可以作为一项关键检查点，必须根据政策规定或出现 CVE 时完成。仅在强制性规定时将这些升级作为一次性事件进行，会给通常复杂且流程繁重的应用程序交付管道增加另一道障碍。
我们在 2023 年底亲眼目睹了这一点，当时开源 Java 框架 Spring Boot (2.x) 版本的OSS 支持结束，许多组织试图在他们的路线图上腾出空间进行升级或通过商业支持延长他们的支持窗口。
在交付新代码需要数月的工作，代码被闲置，在数据中心平稳运行半年的时候，口号很简单：“如果它没有坏，就不要修它。”季度发布是最好的情况。更常见的是，更新每年会进行两次，有时甚至每年只进行一次。
大多数代码更新都集中在为企业提供新功能，很少有时间用于解决技术债务。安全性和稳定性，除非最终用户明确要求，否则经常被忽视。工程师和软件架构师努力为这些关键要素进行辩护，但最终却看到它们随着时间的推移而演变成更大的问题。因此，修补旧代码变成了一项艰巨的任务，因为开发人员一直远离老化的代码库。
这助长了更新源代码是一个复杂、困难且商业价值低的流程的看法。持续更新源代码尚未在组织文化中占据一席之地，许多公司仍然屏住呼吸，采取任何措施来帮助他们逃避 CVE 的迫在眉睫的威胁。
Java/Spring 生态系统是持续代码升级重要性的一个很好的例子。Java 是一种非凡的语言，在其 25 年的历史 中，很少有更新会破坏现有代码。一项了不起的壮举——但也是一把双刃剑。虽然在 90 年代编写的代码可能仍然可以在最新版本的 Java 上运行，但如果在此过程中没有进行任何修补、维护和依赖项更新，那么你将处于糟糕的境地。
如今，事情发展得更快，应用程序表面积面临的威胁也比以往任何时候都多。从更积极的角度来看，创新的步伐也在迅速加快，对最新和最棒的工具和技术的 demand 促使开发团队进行升级。
例如，Java 21 和 Java 22 被广泛认为是 Java 历史上最重要的版本，为进行升级的人提供了关键的新功能和创新。虽然Oracle 提供的 Java 支持一直可用，但许多组织通过不进行升级而错过了潜在的节省和收益。
一些组织抵制升级，认为旧版本更稳定，但这通常并非如此。Spring Boot 3.1 和 3.2 的补丁都在同一天发布，修复了相同的问题，因此没有一个天生就比另一个更稳定。但是，坚持使用 3.1，你就错过了 3.2 中引入的新功能。 例如，Spring Boot 利用 Coordinated Restore at Checkpoint 的能力来加快启动时间。同时，Native Images 能够创建更小的应用程序占用空间，减少暴露的攻击面。这种组合使应用程序不易受到潜在威胁的影响，并减少了托管它们所需的内存。
创建持续升级的文化使您的组织能够跟上创新步伐，更好地防御恶意行为者。当升级成为软件开发生命周期中的一个正常部分时，升级不再需要两到三个冲刺，您也不需要告诉项目经理您无法交付功能，因为您正在处理一系列技术任务。这是工具 + 自动化 + 纪律，让您在进行过程中完成这些工作。前进的道路不是关于您能获得多么酷和花哨，而是关于您的代码的可维护性。它是关于能够展望未来几年，并确信您的代码将得到维护，不会给生产环境中运行的代码增加更多技术债务。虽然重大更新可能仍然需要一些工作量，但将会有简单的按钮和食谱来跟上。
目标是创造一种文化，让持续升级成为您流程中不可或缺的一部分，无需再三思。这是一种保证，您今天发布到市场上的产品将经受住时间的考验，在未来几年内保持安全和可靠，并确保您满足 合规性要求。这听起来很棒，但要实现这一点需要投资。
对于那些尚未进行升级流程，并且仍在使用旧版 Java 的组织来说，升级能力并不总是容易开启的。没有作弊代码可以跳过培训，让它在规模上发挥作用。每个组织都有模式或方法（例如内部库或旧 API），这些模式或方法不能简单地插入现有的食谱中……代码更改将不可避免。
是时候去健身房了——您需要一个锻炼计划。以下列出了三个需要考虑的建议。
与组织内任何重大工作方式变更一样，领导层支持的文化变革对于成功至关重要。在您能够向前迈进之前，负责应用程序功能以外事项的人员必须加入进来。这可能意味着 CIO、CSO、企业架构师，甚至拥有产品组合的应用程序负责人。
软件领导者再也无法将他们的业务（以及他们客户的业务）押注于他们的代码安全可靠。缩短从 CVE 公告到代码修补的时间现在至关重要。
最重要的是，在动手操作任何代码之前，良好的计划和可见性是关键先决条件。这首先要了解哪些版本即将发布。例如，在 2023 年，只有四个星期 Spring Framework 没有发布版本。Spring 团队不断引入第三方依赖项，以便每个版本下的所有内容都已修补，彼此之间经过测试，并经过验证可以正常工作。
了解即将发生的事情，并了解这些依赖项的发布列车非常有价值，因此您将始终知道何时所有内容都已修补。
同样重要的是，您的 CSO 还需要拥有所有已知 CVE 的列表，以及对应用程序产品组合中实际运行的内容的可见性。随着功能和代码库的增长，很容易丢失一些东西。开发人员一直在寻找解决方案来解决他们的问题，因此也许在途中他们在这里和那里插入了一个库来帮助他们解决他们需要解决的问题。您需要持续了解所有这些内容。
通过使用扫描工具和应用程序发现，您可以识别产品组合中最大的风险，将应用程序归类为易于升级的机会，并确定哪些需要更多努力。这就是自动化发挥作用的地方。
自动化工具
当您准备好开始升级应用程序时，您需要确定一个合理的起点，不会影响或中断您现有的开发管道。让所有团队都开始单独处理升级可能不可持续；相反，一个小团队和一些 自动化可能是一个好的起点。
对于分析确定易于升级或需要较少人工干预的应用程序，Open-Rewrite 等工具提供了一种简单的方法来开始自动化重构和修复。Open-Rewrite 包含一个自动重构引擎，它运行预先打包的开源重构配方，用于常见的框架迁移、安全修复和样式一致性任务。
一旦您解决了易于升级的应用程序，就可以开始处理没有现有配方的复杂应用程序。随着您对需要升级的应用程序的了解越来越多，您可以开发自己的配方来扩展升级工作，并建立自己的框架以供将来使用。
应用程序平台
在考虑升级源代码时，可能会出现的一个问题是如何在进行升级时管理生产环境中运行的代码。您是否会在升级时停止应用程序？这就是应用程序平台相对于拼凑在一起的工具和服务的优势所在。根据 2024 年云原生应用程序平台现状报告，企业正在寻找支持多种应用程序类型和部署模式的单一平台体验。云原生应用程序平台允许您运行多个实例，这些实例可以在其他实例运行时进行升级或修补，或者更改在生产环境中使用云原生构建包运行的实例的操作系统层。
要真正实现持续升级的状态，需要“即使疲惫和酸痛也要回到健身房”。但是，一旦您找到了适合自己生活方式的锻炼方式，您就会将其纳入日常生活中。通过完成升级过程，您将弄清楚哪些模式适合您的组织，学习如何更好地利用 Open-Rewrite 等工具，并创建配方和自己的框架以帮助大规模应用它们。
如今，一切都发展得更快，恶意行为者有更多机会，但也存在更多可以利用的可能性和创新。因此，不要将您的业务押注在过去一直采用的方式上；从今天开始实施小的改变，并努力建立自己的持续升级文化。