不要坐視源代碼更新

持續更新源代碼并不像聽起來那麼令人生畏，而且是利用新功能和保護代碼的最佳方式。

譯自 Don't Sleep on Source Code Updates，作者 Evan Prowse。

回溯維護和更新源代碼的步驟是一項艱巨的任務，特别是對于依賴于開源軟體 (OSS) 且支援視窗有限的組織而言。随着時間的推移和代碼的頻繁釋出，越來越難記住哪些是什麼，使用了哪個版本以及為什麼有人以這種方式編寫代碼。随着技術債務的累積，修複潛在問題或 CVE 變得越來越困難。此外，随着 OSS 架構和工具的演變，遷移到最新版本的所需工作量也越來越大。

在高度監管的行業中營運的組織面臨着更大的挑戰。為了遵守強制性規定和标準，更新可以作為一項關鍵檢查點，必須根據政策規定或出現 CVE 時完成。僅在強制性規定時将這些更新作為一次性事件進行，會給通常複雜且流程繁重的應用程式傳遞管道增加另一道障礙。

我們在 2023 年底親眼目睹了這一點，當時開源 Java 架構 Spring Boot (2.x) 版本的OSS 支援結束，許多組織試圖在他們的路線圖上騰出空間進行更新或通過商業支援延長他們的支援視窗。

商業價值始終至上

在傳遞新代碼需要數月的工作，代碼被閑置，在資料中心平穩運作半年的時候，口号很簡單：“如果它沒有壞，就不要修它。”季度釋出是最好的情況。更常見的是，更新每年會進行兩次，有時甚至每年隻進行一次。

大多數代碼更新都集中在為企業提供新功能，很少有時間用于解決技術債務。安全性和穩定性，除非最終使用者明确要求，否則經常被忽視。工程師和軟體架構師努力為這些關鍵要素進行辯護，但最終卻看到它們随着時間的推移而演變成更大的問題。是以，修補舊代碼變成了一項艱巨的任務，因為開發人員一直遠離老化的代碼庫。

這助長了更新源代碼是一個複雜、困難且商業價值低的流程的看法。持續更新源代碼尚未在組織文化中占據一席之地，許多公司仍然屏住呼吸，采取任何措施來幫助他們逃避 CVE 的迫在眉睫的威脅。

更新的重要性：Spring/Java 示例

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），這些模式或方法不能簡單地插入現有的食譜中……代碼更改将不可避免。

是時候去健身房了——您需要一個鍛煉計劃。以下列出了三個需要考慮的建議。

1. 從上司層的認可開始

與組織内任何重大工作方式變更一樣，上司層支援的文化變革對于成功至關重要。在您能夠向前邁進之前，負責應用程式功能以外事項的人員必須加入進來。這可能意味着 CIO、CSO、企業架構師，甚至擁有産品組合的應用程式負責人。

軟體上司者再也無法将他們的業務（以及他們客戶的業務）押注于他們的代碼安全可靠。縮短從 CVE 公告到代碼修補的時間現在至關重要。

2. 優先考慮釋出計劃和産品組合可見性

最重要的是，在動手操作任何代碼之前，良好的計劃和可見性是關鍵先決條件。這首先要了解哪些版本即将釋出。例如，在 2023 年，隻有四個星期 Spring Framework 沒有釋出版本。Spring 團隊不斷引入第三方依賴項，以便每個版本下的所有内容都已修補，彼此之間經過測試，并經過驗證可以正常工作。

了解即将發生的事情，并了解這些依賴項的釋出列車非常有價值，是以您将始終知道何時所有内容都已修補。

同樣重要的是，您的 CSO 還需要擁有所有已知 CVE 的清單，以及對應用程式産品組合中實際運作的内容的可見性。随着功能和代碼庫的增長，很容易丢失一些東西。開發人員一直在尋找解決方案來解決他們的問題，是以也許在途中他們在這裡和那裡插入了一個庫來幫助他們解決他們需要解決的問題。您需要持續了解所有這些内容。

3. 利用工具和自動化

通過使用掃描工具和應用程式發現，您可以識别産品組合中最大的風險，将應用程式歸類為易于更新的機會，并确定哪些需要更多努力。這就是自動化發揮作用的地方。

自動化工具

當您準備好開始更新應用程式時，您需要确定一個合理的起點，不會影響或中斷您現有的開發管道。讓所有團隊都開始單獨處理更新可能不可持續；相反，一個小團隊和一些 自動化可能是一個好的起點。

對于分析确定易于更新或需要較少人工幹預的應用程式，Open-Rewrite 等工具提供了一種簡單的方法來開始自動化重構和修複。Open-Rewrite 包含一個自動重構引擎，它運作預先打包的開源重構配方，用于常見的架構遷移、安全修複和樣式一緻性任務。

一旦您解決了易于更新的應用程式，就可以開始處理沒有現有配方的複雜應用程式。随着您對需要更新的應用程式的了解越來越多，您可以開發自己的配方來擴充更新工作，并建立自己的架構以供将來使用。

應用程式平台

在考慮更新源代碼時，可能會出現的一個問題是如何在進行更新時管理生産環境中運作的代碼。您是否會在更新時停止應用程式？這就是應用程式平台相對于拼湊在一起的工具和服務的優勢所在。根據 2024 年雲原生應用程式平台現狀報告，企業正在尋找支援多種應用程式類型和部署模式的單一平台體驗。雲原生應用程式平台允許您運作多個執行個體，這些執行個體可以在其他執行個體運作時進行更新或修補，或者更改在生産環境中使用雲原生建構包運作的執行個體的作業系統層。

沖洗，重複，學習

要真正實作持續更新的狀态，需要“即使疲憊和酸痛也要回到健身房”。但是，一旦您找到了适合自己生活方式的鍛煉方式，您就會将其納入日常生活中。通過完成更新過程，您将弄清楚哪些模式适合您的組織，學習如何更好地利用 Open-Rewrite 等工具，并建立配方和自己的架構以幫助大規模應用它們。

如今，一切都發展得更快，惡意行為者有更多機會，但也存在更多可以利用的可能性和創新。是以，不要将您的業務押注在過去一直采用的方式上；從今天開始實施小的改變，并努力建立自己的持續更新文化。