一千萬個為什麽

搜索

創建一個單獨的技術和業務版本控制系統



我公司的一個常見問題是版本控制。我們遵循格式化的版本控制系統,它非常類似於語義版本控制(但不是由定義)。我們目前的版本不僅用於開發,還用於發行說明,廣告等市場/銷售。通常,版本控制應該是什麽樣的沖突。通過市場營銷,開發團隊將其定義為主要變更(非向後兼容的API變更)通常不被視為“主要”變更。其他時候,市場營銷將推動增加主流,因為他們是一個重要的客戶工作流程變化,但從發展的角度來看,變化是微不足道的(通常只是一個應用程序代碼補丁)。

我正在大力推動將我們的版本分成兩個不同的系統,一個業務版本和一個技術版本系統。這將允許兩個團隊定義他們自己的最適合他們需求的版本的規則。盡管反饋總體上是積極的,但在我們的跨團隊溝通和票務系統中,一些關註點會造成混淆。

有兩個版本控制系統的一些復雜性是什麽?分離有什麽好處?這對團隊和整個公司會產生什麽樣的影響?

轉載註明原文: 創建一個單獨的技術和業務版本控制系統

一共有 2 個回答:

在我看來,你的客戶應該口授版本。兩支球隊似乎都在走向相同的事情,但只是部分地理解客戶的影響。對於開發,當他們重新構建組件時,存在風險,因為這可能會破壞數據或使核心功能處於故障狀態 - 這應該通過主版本號更改來反映。

這對市場營銷沒有多大意義 - 一切看起來都一樣,為什麽客戶會註意到這種變化?沒有必要反映這是一個重大變化......除非你是一名開發人員,在這種情況下,你可能會為這些錯誤提供大量支持交互。

同樣,市場營銷部門正在著眼於用戶界面,他們假設在對GUI進行重大改革時,客戶可能會迷失或討厭新的用戶界面。這可能會導致幫助客戶瀏覽新用戶的重要支持交互,因此應該反映為客戶的主要版本號變更。那裏存在很多風險......除非你是開發者。那麽這純粹是化妝品。在後端,所有東西仍然是一樣的。

所以看起來你需要決定你覺得版本編號的目的是什麽。

  • 是否使用版本號向客戶發出風險信號?
  • 您使用的是什麽源碼控制系統
  • 開發是否甚至需要版本號 或提交ID是否足夠?
  • 開發計劃是否針對版本編號計劃功能以達到設定期限的目的?

根據答案,使用由市場營銷引導的單一版本號碼系統可能是理想的選擇 - 但市場營銷人員需要更好地理解發生變化的風險。如果需要將此作為設置更改集成期限的指示符,那麽兩個版本編號系統可能是合格的:

註意:git標簽對於你提到的任何版本編號方案都很好。

在我看來,如果文檔更改,軟件版本不應該更新,而軟件本身不會更改。

我不喜歡對技術文檔和軟件使用不同的版本,因為文檔與特定的軟件版本相關。不同的版本會導致混淆。

總之,可以使用相同的版本控制,但如果只更新文檔,則可以添加元數據,例如1.2.3-20171017。通過使用元數據,仍然可以看到文檔屬於軟件的版本x,並且還可以看到文檔已更新。