認真看完這段視訊，保證你在下一次大發布之前不會再有那麼大壓力。
最能衡量敏捷團隊成功的標準就是將可用的軟體釋出給客戶。但是，即使是有經驗的軟體團隊也會感到十分痛苦，因為這也是驗證已經完成的問題了；程式碼沒有經過評審，程式碼還沒來得及合併，或者合併程式碼失敗。聽起來是不是很熟悉啊？
「CODING 企業版」作為企業級軟體研發管理系統，助力團隊敏捷開發轉型升級。
在這個演示中，你將學習到下面幾點：
-
編碼最佳實踐，將提高你交付高質量產品的能力。瞭解為什麼程式碼評審對於交付質量是至關重要的，並且監視和修復失敗的構建能保證釋出更快捷。
-
通過在釋出中心建立清晰的圖表來表示釋出的進度和狀態，你會學習如何節省工作時間。
-
從構建、編碼到釋出的完全自動化。通過從釋出中心直接釋出你的版本來簡化工作流程。
觀看 & 學習
提問和回答
我們的主持人 Jason Wong 和 Megan Cook 從這次演講中選擇了他們最喜歡的問答。繼續閱讀以瞭解更多關於無壓力釋出的資訊。
問題 1：成功使用釋出中心的 3 個最重要的非技術因素是什麼？
回答 1：（1）充滿信心地交付：團隊內外的利益相關者將能夠知道在整個釋出週期的任何時候都應該準備好什麼。 （2）更快地做出決策以節約時間：準備好交付，及時瞭解已經完成了哪些功能，以及還存在哪些有問題。在釋出中心中跟蹤檢查本次釋出版本的所有問題，這樣你就不必手動協調問題解決和調整程式碼了。 （3）釋出的記錄：通過檢視已釋出的版本來了解發布什麼特性（何時釋出），以及通過檢視未釋出的版本，瞭解每個即將釋出的版本的計劃。
「CODING 企業版」提供便捷的釋出管理，清晰每一次釋出交付物，方便運維團隊執行開發團隊的釋出計劃。
問題2：在 Atlassian 中，通常是誰來管理版本釋出？
回答2：Atlassian 中每個團隊都有它自己的特定方法，但總的來說，我們儘可能的將過程自動化，以便以最少的開銷修復 bug。 團隊通常有一份待完成事項的列表，但是我們儘量將其最小化。像釋出中心這樣的工具在這個過程中幫助確保我們計劃釋出的是最高質量的，並且 Jira 軟體問題的狀態和它們的實際開發非常匹配。 一些較大的團隊對於 bug 管理者/釋出管理者會建立專人輪換制度。 對於較大的主版本和小版本，通常會有一個專門的人來負責釋出，並且所有的工作都是圍繞風險和時間期限展開的。這可能由團隊領導或開發經理負責，但是我們試圖確保由團隊成員輪換負責，這樣每個人都知道這個過程，並理解發布高質量軟體的要求。
對於釋出的計劃時間線，團隊領導將與產品經理和市場營銷人員進行協調，以確定何時準備好釋出，以及是否需要管理髮布範圍或時間。正是由這些人，決定了哪些功能將在哪些版本中釋出。
問題3：你如何做到一個分支/提交/合併請求/構建/部署關聯到一個問題（issue）？
回答3：
- 分支——在分支名稱中包含指定問題的標記，也就是 issue 的 key 。
- 提交——在提交訊息中包含 issue key。
- 合併請求——在源分支名稱中，或者提交訊息，或合併請求標題中包含 issue key。
- 構建——在提交訊息中包含 issue key。
- 部署——在提交訊息中包含 issue key。
問題4：當你在隔離的多個分支上使用相同的程式碼時，你有什麼經驗來處理這些衝突？
回答4：我們的經驗是，這很少是一個問題。大多數情況下不存在程式碼重複，只是偶爾會發生衝突。 通常會有兩個問題：
- 長期執行的特性分支與其他正在進行的開發隔離。
- 大規模的重構任務，在完成、測試並準備釋出之前，需要隔離。
對於前者，一種做法是頻繁地進行開發和整合，但是將特性本身保留在特徵標誌後面，這樣只有我們自己的測試程式或少數幾個客戶能看到正在進行的更改。這確保了相互衝突的程式碼不斷地整合，最小化衝突的可能性，並在大特性更新到主幹開發分支時最小化風險和影響。
如果做不到這樣，或者在進行大型重構的情況下，我們確保開發分支儘可能多地整合到特性分支中（通過將基線/開發分支的變更合併到特性分支中）。這確保了所有正在進行的開發都是在長時間執行的特性分支上完成的，並且儘可能經常地進行測試。如果存在任何合併衝突，那麼就更容易讓做更改的人來幫助解決合併衝突，或者至少保持他們影響範圍最小化，這樣解決起來就更容易點。
最好的解決方案是將任何工作分解成塊，以便儘可能頻繁地合併到穩定或開發分支中。這就減少了在特性分支中對相同檔案進行更改的機會。
問題5：你建議用什麼樣的策略來管理正在進行的開發分支、熱修復分支和部署到不同環境的分支（測試環境/定版環境/生產環境）等並行分支？
回答5：在我們的網站上有許多分支策略，著重看下比較工作流部分。
在以前的一些討論中可以找到更多的細節，正確使用 Git 和持續的部署工作流程在 SaaS 團隊的 Git 工作流中有更深入的介紹。 簡而言之，有兩種主要的工作流：可下載產品的產品釋出工作流和線上服務的 SAAS 工作流（ SAAS 團隊的 Git 工作流）。
「CODING 企業版」作為企業級軟體研發管理系統，任務看板功能實現了 Epic \ user stories \ Sprint 等敏捷概念落地。
對於可下載的產品，大多數團隊使用的是 Gitflow 工作流的變體，其中主線用於正在進行的開發，而之前的每一個小版本都有自己的分支，其中 bugfix 分支建立瞭然後再合併回來，在需要的時候，就構建一個 Bug 修復版本。之前的每個釋出分支都將所有的變更合併到後續版本中，並確保所有的 Bug 修復都包含在所有後續版本中。
問題6：釋出中心是否能很好地與看板和頻繁釋出協同工作？
回答6：是的，它工作得很好。看板上的釋出按鈕可以用來建立一個新版本，其中包含了該版本的所有問題。一旦建立了這個版本，就可以使用釋出中心檢查任何警告，或者獲得版本的概述。 即使沒有看板圖，你也可以在任何時候建立一個版本，並在這些問題已經完成的情況下新增問題。然後，釋出中心可以用來檢查任何警告，以確保釋出已經準備妥當。
問題7：釋出中心是否可以顯示來自多個 Jira 軟體專案的問題資訊，或者是釋出中心專案和修復版本？
回答7：釋出中心是一個版本的詳細檢視。由於版本目前是針對特定專案的，所以釋出中心也是針對特定專案的。
問題8：你能讓釋出中心的警告自動釋出到一個 Hipchat 聊天室裡嗎？
回答8：到今天為止，釋出中心警告和 Hipchat 之間沒有整合，我們目前還沒有任何計劃去整合。我們一直在思考釋出中心可以通過不同的方式加強與 Hipchat 的團隊協作，並希望從我們的客戶那裡聽到更多關於他們如何使用這種整合或與其他產品的整合的更多資訊。
問題9：“釋出”按鈕後面關聯的是什麼？是用來部署生產伺服器的指令碼嗎，比如 Bamboo 中的 Job ？
回答9：“釋出”按鈕有一些與之相關的功能：
-
它可以設定釋出日期，並將版本的狀態更改為“已釋出”。如果在版本中有任何開放的問題，它也會提供將這些問題轉移到另一個版本的選項。這些都可以在沒有 Bamboo 的情況下使用。
-
當 Bamboo 與 Jira 軟體整合時，釋出按鈕可以用來啟動一個新的構建，可以用 Bamboo 來配置，以採取必要的步驟來發布你的版本（例如，部署到生產環境的指令碼）。
-
釋出按鈕也可用於啟動已執行的 Bamboo 構建的手動定版釋出。你可以擁有一個自動執行的構建，但是有一個可選的階段，只有手動觸發，才能實際執行部署/放行。（這個階段相當於選項2中的整個構建，但是可以通過人工操作來觸發構建。）
問題10：是否有將釋出中心與 GitHub/GitHub 企業版整合的計劃？ 回答10：釋出中心已經與 GitHub 和GitHub 企業版合作。你所要做的就是將 Jira 軟體例項連線到你的 GitHub 帳號，使用 DVCS 賬戶在 Jira 軟體的附加管理員選單中可以找到。然後你就可以開始跟蹤所有版本的進展，包含了釋出中心中所有相關開發資訊。
「CODING 企業版」提供便捷的釋出管理，清晰每一次釋出交付物，方便運維團隊執行開發團隊的釋出計劃。
本文中文翻譯自原文：Journey to a stress-free release 編譯者：程景天。