您如何決定何時升級項目中的庫？

Question

我在一個使用多個開源Java庫的項目上工作。 當升級到這些庫時，我們傾向於遵循保守的策略：

1. 如果沒有破損，請不要修復它
2. 如果它沒有我們想要的新功能，請忽略它

我們遵循這一策略是因為我們通常沒有時間放入新庫並徹底測試整個應用程序。 （像許多軟件開發團隊一樣，我們總是落后於幾個月前承諾的功能。）

但是，我有時想知道這種策略是否明智，因為一些性能改進和大量的bug修復通常伴隨着庫升級。 （即“誰知道，也許事情會以我們無法預見的方式更好地運作......”）

在項目中做出這些類型的決策時，您使用什么標准？

Answer 1

重要：避免技術債務 。

“如果它沒有破產，不要升級”是一個瘋狂的政策，導致軟件如此破碎，沒有人可以解決它。

皮疹，未經測試的改變是一個壞主意，但不像累積技術債務那么糟糕，因為它在短期內看起來更便宜。

獲得“夜間構建”過程，以便您可以持續測試所有更改 - 您的更改以及您依賴的包。

在您進行持續集成過程之前，您可以執行包含基礎架構升級的季度主要版本。

避免技術債務。

Answer 2

我已經吸取了足夠的教訓來完成以下工作：

1. 檢查庫的更改列表。 他們修復了什么？ 我關心的？ 如果沒有更改列表，則我的項目中不使用該庫。
2. 人們在圖書館論壇上發帖的是什么？ 發布后不久就會發出大量帖子，指出明顯的問題？
3. 與2號一樣，不要立即升級。 每個人發布都不好。 我不打算成為第一個得到這個小蟲子的人。 （再也是）。 這並不意味着要等6個月。 在發布的第一個月內，你應該知道缺點。
4. 當我決定繼續升級時; 測試，測試測試。 這里的自動化測試非常重要。

編輯：我想添加一個至少同樣重要的項目，也許比其他項目更重要。

• 這個版本引入了哪些重大變化？ 換句話說，圖書館是朝着不同的方向發展的嗎？ 如果庫正在棄用或替換功能，您將希望保持最佳狀態。

Answer 3

一種方法是在您自己的源代碼控制下使用您使用的開源庫。 然后定期將上游更改合並到下一個發布分支中，或者如果它們是安全修復程序，則會更快，並運行自動化測試。

換句話說，使用相同的標准來決定是否像在內部編寫的代碼一樣使用上游更改。 考慮開源開發人員加入虛擬開發團隊。 無論如何，情況確實如此，只是您是否選擇將其視為開發實踐的一部分。

Answer 4

雖然您不想僅因為有新版本而升級，但還有另一個考慮因素，即舊版本的可用性。 我遇到了試圖構建開源項目的問題。

Answer 5

我通常認為忽略一個新版本的庫（因為它沒有任何有趣的功能或改進）是一個錯誤，因為有一天你會發現這個版本是遷移到下一個版本所必需的。你可能想要升級到。

所以我的建議是仔細審查新版本中的變化，並考慮變更是否需要大量測試，或者很少。

如果需要進行大量測試，最好在軟件的下一個版本（主要版本）升級到更新的庫（例如從v8.0升級到v8.5時）。 當發生這種情況時，我猜還有其他重大修改，因此進行了大量測試。

Answer 6

我不想讓版本在依賴庫上落后太多。 除非知道安全性或性能問題，否則大多數庫可以使用長達一年的時間。 具有已知安全問題的庫是必須刷新的。

我定期下載每個庫的最新版本並使用它們運行我的應用程序單元測試。 如果它們通過，我會在我們的開發和集成環境中使用它們一段時間，並在我滿意它們不吸吮時推送到QA。

上述過程假設API沒有顯着變化。 如果我需要重構現有代碼只是為了使用更新的庫版本，所有的賭注都是關閉的。 （例如Axis 1x vs. 2x）然后我需要讓管理層參與決定分配資源。 在計划對遺留代碼進行重大修訂之前，這種更改通常會有所不同。

Answer 7

一些重要問題：

• 圖書館有多廣泛使用？ （如果它被廣泛使用，將更快地找到並消除錯誤）
• 它是如何積極發展的？
• 文件是否非常清楚？
• 是否有重大變化，次要變更或內部變更？
• 升級是否會破壞向后兼容性？ （你需要改變你的任何代碼嗎？）

除非根據上述標准升級看起來不好，否則最好使用它，如果您有任何問題，請恢復舊版本。