一千萬個為什麽

搜索

單擊部署的範圍



因此,軟件公司的目標之一就是點擊一次部署。我認為這是開發團隊的主要責任。是否應該保留給另一個對話。我的問題是我們公司有多個單獨的工件組成一個版本。開發人員是否應該一次點擊部署所有這些工件,還是應該單獨部署每個工件?

轉載註明原文: 單擊部署的範圍

一共有 2 個回答:

答案是:這取決於。

在我回答之前,我需要提供幾個術語的定義以防止含糊不清。

1) Deploy 定義為在環境中更改可執行文件的行為。這可能意味著新源被復制,並且某個進程重新啟動。或者將一個新版本的Docker容器放入一個管弦樂器中 - 並不重要。

2)發布定義為為系統的用戶提供新功能的動作 。

請註意,雖然在大多數組織中 releasedeploy 一起發生,但它們絕對不一定是。

每次發布的更改(通常)都需要部署新代碼。但並非每個代碼的部署都意味著新的更改被發布以供使用。

讓我們先看看最好的情況。如果您沒有任何需要推送的按鈕,就可以進行部署。每次發送到您的版本控制系統的更改都會自動進行正確性測試並自動部署到您的系統。

現在您的問題可以選擇幾個不同的問題:

  • 我是否有辦法發布新功能並且是這種手動方式? (按鈕)
  • 當該按鈕被按下時,我是否同時釋放所有可用(多個)功能?
  • 我的功能版本需要在系統的多個分離部分中進行更改嗎

由於發布新功能需要一些業務批準。例如,新功能的用戶體驗和正確性必須實際為您的客戶帶來價值。有一個“黑暗”版本是有道理的,只有一些友好的客戶才能看到並提供反饋。然後,當這些客戶對他們獲得的價值感到滿意時,您的企業可以決定使這種新功能通用(GA)。

如果此功能在發布時破壞系統,則可以關閉首先釋放的開關。所有這些都不需要將任何新代碼(或舊代碼)部署到系統中,因為代碼已經存在。

當您認為 deploy版本是分開的時,它會決定將所有內容部署在一起或分別更簡單。


制造業和豐田生產系統特別告訴我們,小批量生產比批量生產物料更有利。 TPS甚至可以追求單件流程,其中每個工作項目單獨交付給下一個工作中心,而不是批量交付。

敏捷方法從TPS中得到了啟發,並描述了小批量生產的好處。這些將被描述為一個“沖刺”,並在最後部署可交付的產品,並努力盡可能縮短沖刺時間。這樣可以進行簡短的實驗,並在盡可能快地獲得有關所做更改值的反饋意見。

Continuous Delivery更進一步說,任何完成的代碼都應該在自動測試後立即部署到您的系統中。當某人決定這麽做時,任何時候都可能發布一個版本。實驗可以作為開發周期的一部分進行驗證。將開發人員的“完成”定義從“我完成了我的代碼寫入”轉向“我從客戶那裏收到了他們收到的價值的反饋”。反饋周期越短 - 分鐘,秒等...越好。配料是對短期反饋的威懾。

通過定義一個按鈕,將事物分在一起,意味著問題的風險更高。從TPS,敏捷和CD學習意味著單件產品遠遠優於其他產品,並且具有很多優勢。


“取決於”的答案是正確的,因為我上面寫的所有內容都高度取決於組織的成熟度。您擁有的自動化程度。您擁有的通信量。還有其他許多因素。

Separating release from deployment requires continuous integration and deployment. As well as a system that enable to select which features to release. For example https://github.com/intuit/wasabi or https://www.infoq.com/presentations/etsy-deploy

所有這些工件應該立即部署。否則,它不是真正的“一鍵式”。