無壓力的軟件發佈之旅

無壓力的軟件發佈之旅

認真看完這段視頻，保證你在下一次大發布以前不會再有那麼大壓力。

最能衡量敏捷團隊成功的標準就是將可用的軟件發佈給客戶。可是，即便是有經驗的軟件團隊也會感到十分痛苦，由於這也是驗證已經完成的問題了；代碼沒有通過評審，代碼還沒來得及合併，或者合併代碼失敗。聽起來是否是很熟悉啊？

「CODING 企業版」做爲企業級軟件研發管理系統，助力團隊敏捷開發轉型升級。

在這個演示中，你將學習到下面幾點：

• 編碼最佳實踐，將提升你交付高質量產品的能力。瞭解爲何代碼評審對於交付質量是相當重要的，而且監視和修復失敗的構建能保證發佈更快捷。

• 經過在發佈中心創建清晰的圖表來表示發佈的進度和狀態，你會學習如何節省工做時間。

• 從構建、編碼到發佈的徹底自動化。經過從發佈中心直接發佈你的版原本簡化工做流程。

觀看 & 學習

提問和回答

咱們的主持人 Jason Wong 和 Megan Cook 從此次演講中選擇了他們最喜歡的問答。繼續閱讀以瞭解更多關於無壓力發佈的信息。

問題 1：成功使用發佈中心的 3 個最重要的非技術因素是什麼？

回答 1：（1）充滿信心地交付：團隊內外的利益相關者將可以知道在整個發佈週期的任什麼時候候都應該準備好什麼。
（2）更快地作出決策以節約時間：準備好交付，及時瞭解已經完成了哪些功能，以及還存在哪些有問題。在發佈中心中跟蹤檢查本次發佈版本的全部問題，這樣你就沒必要手動協調問題解決和調整代碼了。
（3）發佈的記錄：經過查看已發佈的版原本瞭解發佈什麼特性（什麼時候發佈），以及經過查看未發佈的版本，瞭解每一個即將發佈的版本的計劃。

「CODING 企業版」提供便捷的發佈管理，清晰每一次發佈交付物，方便運維團隊執行開發團隊的發佈計劃。

問題2：在 Atlassian 中，一般是誰來管理版本發佈？

回答2：Atlassian 中每一個團隊都有它本身的特定方法，但總的來講，咱們儘量的將過程自動化，以便以最少的開銷修復 bug。
團隊一般有一份待完成事項的列表，可是咱們儘可能將其最小化。像發佈中心這樣的工具在這個過程當中幫助確保咱們計劃發佈的是最高質量的，而且 Jira 軟件問題的狀態和它們的實際開發很是匹配。
一些較大的團隊對於 bug 管理者/發佈管理者會創建專人輪換制度。
對於較大的主版本和小版本，一般會有一個專門的人來負責發佈，而且全部的工做都是圍繞風險和時間期限展開的。這可能由團隊領導或開發經理負責，可是咱們試圖確保由團隊成員輪換負責，這樣每一個人都知道這個過程，並理解發布高質量軟件的要求。

對於發佈的計劃時間線，團隊領導將與產品經理和市場營銷人員進行協調，以肯定什麼時候準備好發佈，以及是否須要管理髮布範圍或時間。正是由這些人，決定了哪些功能將在哪些版本中發佈。

問題3：你如何作到一個分支/提交/合併請求/構建/部署關聯到一個問題（issue）？

回答3：

1. 分支——在分支名稱中包含指定問題的標記，也就是 issue 的 key 。
2. 提交——在提交消息中包含 issue key。
3. 合併請求——在源分支名稱中，或者提交消息，或合併請求標題中包含 issue key。
4. 構建——在提交消息中包含 issue key。
5. 部署——在提交消息中包含 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 編譯者：程景天。