1

據我所知,快照正在開發中,即1.0-SNAPSHOT是最終將發佈爲1.0的東西。Maven的CI/CD任何使用快照的概念是什麼?

但爲什麼我需要它?

這裏是流量:

  • 我開發庫,語義版本Major.Minor.Revision[.Build]模型。
  • Revision(或Build)由CI/CD管道自動增加PR被接受
  • 後和門構建成功運行的新版本發佈到公司的專用倉庫我明確地定義MajorMinor
  • 在依賴項目中,我指定了精確版本或浮動版本Major.+

在這裏有SNAPSHOT的地方嗎?

+0

許多優秀的問題都會根據專家的經驗產生一定程度的意見,但對這個問題的回答往往基於意見而非事實,參考或具體專業知識。 –

+0

@GUIDO是否意味着'SNAPSHOT'只是一種便利功能,並沒有關於它的最佳實踐? –

+1

@PavelVoronin這意味着即使使用'SNAPSHOT'可能會有好的或不好的做法。但他們可能主要是基於意見的。 – nullpointer

回答

2

這是一個很大的話題。讓我評論一下我們公司相關的一些觀點。

  • 我們構建包含具有大型依賴樹的jar的ear文件。在開發過程中,你經常需要在樹中深入修復。如果您使用SNAPSHOT版本,則每個人都會在下一個版本中自動繪製這些更改。如果你使用內部版本號,結果必須從下到上傳播,也就是說,如果你有一個依賴關係層次結構A-> B-> C並且你構建了一個新版本的C,那麼你需要一個新版本的B,然後一個A的新版本。或者,您可以在最高級別(本例中爲耳朵級別)上管理具有dependencyManagement的版本,以避免在jar C中修復bug修改後重建所有內容。

  • 我們的開發人員需要構建「 「在開發過程中向客戶展示他們。這些通常構建爲SNAPSHOT版本,而不是放入部署管道。 SNAPSHOT版本允許您從語義上區分這些版本和那些要提高生產力的版本。

  • 快照之間的區別和釋放的版本可以作爲一個快速的方法來猜測工件的質量(如果所有文物都有數XYZ,這是好的,哪些是不好的?)

  • 構建重現是一個重要的目標,但從與開發人員的討論中我知道,對此有不同的看法。一些開發人員認爲版本更新是「自動」發生的 - 他們說「最新版本總是正確的版本,我爲什麼要做所有這些手動更新?」

+0

有幾個關於'SNAPSHOT'的時刻對我來說並不清楚。我什麼時候更改版本以發佈?如果一切都是自動的,那麼「按下按鈕」應該開始部署,即發佈到具有正確版本的「maven-releases」。其次,當我開發我的項目時,我是否應該確實使用'SNAPSOTS'作爲依賴項?如果我這樣做,何時以及如何再次發佈版本? –

+1

這些都是我們正在考慮的問題。如果你想構建「潛在可行的東西」,我將開始部署管道並構建發佈版本。如果您的IDE中有項目A和項目B,並且A取決於B,那麼建立您在A中使用的B的本地SNAPSHOT版本會很有用,因爲您獲得了快速反饋。如果您在一個組中處理多個工件,則發佈SNAPSHOT版本可能會很有用,以便您組中的其他人員可以針對他們開發這些工具。實際上很難定義SNAPSHOT和release之間的確切邊界。 –