2016 年 9 月
第 31 卷，第 9 期
本文章是由機器翻譯。
行動 DevOps - 本質來源： 存放庫在 DevOps 中的角色
由 Kraig Brockschmidt |2016 年 9 月
本系列的第一篇文章 「 從客戶的程式碼︰ 瀏覽行動運 」 (msdn.com/magazine/mt767694) 導入 Microsoft 運堆疊，讓您的行動應用程式和後端服務。它說明整個發行管線，所示的階段 [圖 1。發行管線，將簡單地說，是如何致力於原始程式碼儲存機制的程式碼取得轉換成可供客戶的應用程式和服務，並接著傳遞給客戶的裝置和客戶存取伺服器。發行管線，基本上，是直接的必要版本，會發生此問題的步驟清單。事實上，運練習開頭所明確說明的確切步驟和程序所涉及的版本。從該處就非常簡單，以累加方式自動化這些程序，使用 Microsoft 運堆疊內的工具。
.png "原始檔控制儲存機制是在發行管線的輸入")
[圖 1 的原始檔控制儲存機制是在發行管線的輸入
第一篇文章所述，您應該都能了解如何以手動方式執行每一個步驟中的發行管線。許多應用程式專案開始手動程序，例如手動組建，以盡早軟體測試人員取得意見。了解如何以手動方式執行的所有項目也提供後援以防有些部分自動化的發行管線細分。
不過，手動程序是昂貴調整、 容易發生人為疏失，經常繁瑣，並將每個步驟放的競用您的員工與所有其他工作的風險。自動化 — 讓電腦執行這些工作，提供更好調整、 可靠性、 可預測性與稽核，這表示較低的成本較高的品質。自動化還會釋放您真的需要注意人力的工作的員工。
在本文中我將探討非常重要的發行管線，其中一個可能已被佔用的授與︰ 原始檔控制。專案的原始程式碼中所述，為發行管線中，輸入 [圖 1, ，和大部分的開發人員立即接受管理的程式碼當然為原始檔控制系統中。但是，它可協助您進一步了解完整的 DevOps 如果您可以清楚看到該內容中扮演的重要角色的原始檔控制。
原始檔控制的原因
自動化發行管線的第一個步驟是管理某種形式的原始檔控制儲存機制中的程式碼。同樣地，原始程式碼是發行管線中，輸入，且下一個階段，建置功能會將該程式碼轉換成成品，然後進其餘的管線。若要特別自動化建置程序，藉由持續整合，Visual Studio Team Services (簡稱 Team Services) 之類的系統必須能夠偵測到該儲存機制進行變更時。這麼一來，不能管理您的來源程式碼只是在硬碟上某些任意資料夾中。
注意: 如果您還沒有可用的小組服務帳戶，建立一個在指示 bit.ly/29xK3Oo。仍然更好的請參閱 Visual Studio 開發人員 Essentials 程式 (bit.ly/29xKCYq)，這可讓您的小組服務帳戶，以及讓您輕鬆存取許多其他服務，$25 納入 12 個月的 Azure 信用額度。
我將說明如何建置和下一篇文章系列的連續整合。這裡我要特別著重在原始檔控制，開頭為簡短的檢閱的原始檔控制為什麼一開始，存在，而且一般它在整個 DevOps 中扮演的角色。我的理由是點出您可能永遠不會考量之前︰ 原始檔控制基本上是一種自動化。
此陳述式可能會令您吃驚，因為大部分的開發人員立即考慮原始檔控制指定。但不一定如此。有可能是您所處理的專案，在某個時間點的原始檔控制不在您的職涯，尤其是當您第一次。在這些專案中，您可能只是有資料夾包含所有程式碼，也就是您會取得 Visual Studio 中建立新的本機應用程式專案時本機硬碟機上。在這裡，您執行本機組建來產生可執行檔，並且滿足下列條件所需分佈，然後手動上傳至公用 Web 伺服器，或可能是在實體媒體上與其他人共用。
簡單地說，原始檔控制是沒有產生可供客戶的應用程式和後端服務所需的方式。但是，只有單一的本機複本您的程式碼會有一些問題和風險，其中都我想像直接遇過︰
- 如果您的硬碟當機，您可能會遺失所有項目。
- 一份原始碼不會維護任何變更歷程記錄，所以很難還原成先前的工作狀態的專案。
- 多人使用程式碼可以輕鬆地覆寫其他人的變更，或引入重大變更，而不需要知道的任何人。
很可能在某個程度的手動減輕這些風險。定期備份，比方說，協助防範程式碼遺失，並提供一定程度的歷程記錄。不過，整體專案備份 nongranular 性質使非常難以還原之專案的組件，同時讓其他變更保持不變。還有人團隊個人複製程式碼，以避免發生衝突，但就非常繁瑣將這些複本同時整合可運作的狀態。小組成員也可以通訊，以直接的電子郵件或其他訊息給其他人的重大變更，但這會變成累贅一致地執行。
當然，身為開發人員我們通常避免這種負擔我們可以視需要。相反地，我們會尋找創意方法來自動化這些工作，也就是完全何種原始檔控制是怎麼回事。
概括而言，原始檔控制表示︰
- 維護的伺服器上，所有的專案程式碼的共用儲存機制使用某種類型的自動備份的機制。
- 針對每個檔案，以便您可以看到任何指定的檔案的整個歷程記錄的變更記錄，以及已認可至儲存機制，為群組的多個檔案的變更。這可讓您方便關聯組建失敗，並測試迴歸具有特定的變更並還原個別檔案或任何先前的狀態，不只是上次備份的狀態的檔案群組。
- 將程式碼儲存在一個地方建置系統可以偵測到儲存機制的變更會自動觸發的組建，這表示執行即時的整合測試 （連續） 與這些變更。
- 管理覆寫，並要求開發人員在他們在努力，同時鎖定獨佔存取檔案或讓工具，可以自動合併變更及偵測衝突，由多個使用者，相衝突。
- 當特定檔案變更，或是在合併衝突需要手動解決，請自動通知傳送給開發人員。
簡單地說，原始檔控制會自動執行許多有關維護可信靠及可稽核的儲存機制專案的程式碼冗長乏味的程序。它是不可或缺的單一開發人員和小組，管理程式碼的專案，而且是自動的發行管線的基礎。
原始檔控制選項
普遍需要原始檔控制，因此是可想而知，許多不同的系統已經發展多年。在這裡，不過，我將討論您可以直接在小組內裝載兩個︰ Git 和 Team Foundation 版本控制 (TFVC)。裝載的儲存機制，表示它已直接儲存和管理小組的服務帳戶。Team Services 建置系統也可以從外部 Git、 GitHub 和子儲存機制，我將說明如何在下一篇文章系列中的繪製。
為專案選擇的原始檔控制系統實際上是偏好的看個人，開發小組和成本考量的經驗。GitHub，比方說，是免費的公用儲存機制，但也有其代價私用的 (請參閱 github.com/pricing)。公用 GitHub 儲存機制會根據預設，這就是為什麼開啟的所有人都能開啟原始碼專案通常裝載在 GitHub 上。許多的文件集，我的工作在 Microsoft，例如，儲存於該處，包括 Microsoft Azure 文件的整個集合 (github.com/Azure/azure-content)，以及 Visual Studio tools for Apache Cordova 文件 (github.com/Microsoft/cordova-docs)。我也使用各種不同的個別範例專案，如 Altostratus 範例 GitHub (github.com/kraigb/Altostratus) 會出現在 MSDN Magazine 最後一年 (bit.ly/29mKHiC)。同樣地，我選擇 GitHub MyDriving 專案 (github.com/Azure-Samples/MyDriving) 因為它原本是從一開始的開放原始碼。(如需 MyDriving 整體的詳細資訊，請參閱 aka.ms/iotsampleapp。)
相反地，team Services，則導向預設值，這表示，當您建立儲存機制時，只有您才能存取私用儲存機制 （Git 或 TFVC）。為了提供存取權給其他人，您必須特別將其加入做為小組成員 (請參閱 bit.ly/29QDHql)。優點是您可以主控無限制的私用儲存機制 Team Services 帳戶中免費，而且成本只有開始運作時，您有五個以上的使用者沒有 MSDN 訂用帳戶的 MSDN 訂閱者數目。基於這些理由，我使用個人專案的小組服務等應用程式已在應用程式存放區中，我想要與特定的個人共用程式碼。
Git 和 TFVC 的主要功能差異在於其各自的原始檔控制模型。完整比較，請參閱 「 選擇正確的版本控制，為您的專案 」 主題中的文件 (bit.ly/29oZKTZ)，但是讓我彙總。
中所述的 TFVC， [圖 2, ，會集中，這表示檔案位於單一、 中央、 唯讀的儲存機制，系統管理員是負責備份。若要執行使用 TFVC，您通常會維護從儲存機制 （稱為 「 工作區 」），您可以從中執行組建，並測試應用程式檔案的最新版本的本機唯讀複本。若要變更，您簽出一個或多個檔案，可讓您獨佔存取之前會檢查這些檔案回中 （也就，整合至儲存機制）。TFVC 再將變更合併至儲存機制。如果多位開發人員簽出相同的檔案同時 （這允許），TFVC 會偵測在簽入時合併衝突，並會通知開發人員，需要時手動解決。
.png "基本的 Team Foundation 版本控制的關聯性")
[圖 2 基本 Team Foundation 版本控制的關聯性
Git 分散式，這表示雖然主要儲存機制位於何處主機上，「 複製 」 （變更歷程記錄及其所有） 將整個存放庫、 在本機工作，然後認可完成的變更對複製程式碼中所示 [圖 3 (請參閱 git-scm.com 如 Git 工作流程的詳細資訊)。準備好將變更整合其他人的工作時，您送出 「 提取要求 」 從您複製到母片。在此模型中，每個複製品實際上是在儲存機制的備份。
.png "基本 Git 關聯性")
[圖 3 基本 Git 關聯性
請注意，Git，TFVC 使用某些相似的字詞，像 「 取出 」 來描述完全不同的處理程序，這可能會造成混淆。最好只使用每個本身並不會預期傳輸兩者之間的任何知識。
Git 的提取要求機制就能夠偵測時自動合併做的變更，並在需要時手動解決。當然，像 GitHub 公用儲存機制中不一定想人和每個人都能夠合併提取要求。通常，只有特定的個人會有合併提取要求者再做為整體儲存機制的完整性的閘道管理的權限。
比方說，看看 MyDriving 儲存機制，在頂端 github.com/Azure-Samples/MyDriving ，您會看到提取要求 (請參閱 [圖 4)。按一下顯示目前開啟正在等候仲裁有合併的權限的要求。您也可以在清單中的 [關閉] 索引標籤，即可查看提取要求的整個歷程記錄。
.png "在 GitHub 上 MyDriving 專案的提取要求清單")
[圖 4 提取要求清單在 GitHub 上 MyDriving 專案
TFVC 和 Git 支援所謂分支，這基本上是指建立另一個圖層之間的主要或中央儲存機制和其他複製人全面進攻或複製。這樣子群組的開發人員 （和測試人員） 執行大量工作，在該分支中而不會影響主要儲存機制。分支也會維護自己的變更歷程記錄和，在 Git，管理其自己的提取要求每個複製品。該小組便準備好整合與主要分支中的工作時，才他們提交提取要求至 master。如需詳細資訊，請參閱 「 使用分支隔離風險 TFVC 中的 」 (bit.ly/29ndlQz) 和 「 建立分支中的工作 」 (bit.ly/29VVmgY) 文件中。
通訊和稽核
在 TFVC 和 Git，並在原始檔控制系統通常 — 簽入、 提取要求等都有相關聯的註解機制。是如何變更您對每個人其他開發專案和小組可以討論這些變更的方式。這些系統通常也會提供通知和討論內容更廣泛的問題 （例如開啟的 bug） 工作項目，依此類推。
在 GitHub，比方說，您對您複製程式碼，包括與每個程式碼認可的註解後再作其他註解時提交提取要求。他們發現新的程式碼的潛在問題，尤其，負責檢查和合併該要求可以請保留註解或提取要求內的問題。如果您按一下周圍先前所述的 MyDriving 儲存機制中已關閉的提取要求清單中，您可以看到大量的範例。同樣地，若要查看更多討論首頁上的 [問題] 索引標籤上按一下。與通知，這些是透過在 [通知] 區段中的個人設定管理。
小組服務，其組件中，有一整個系統來追蹤工作項目、 bug 等等，您可以在 Team Services 文件的敏捷式軟體開發工具 > 一節中閱讀有關 (bit.ly/29tvKIE)。程式碼儲存機制內 (是否 Git 或 TFVC)，沒有普遍的註解控制項，如所示 [圖 5, ，可讓小組成員便箋上保留變更集 （變更的群組），個別檔案，依此類推。
.png "在 Visual Studio Team Services 中，顯示 [註解按鈕變更集的 UI")
[圖 5 Visual Studio 小組中的變更集的 UI 服務，顯示 [註解按鈕
這類的註解，以及哪些檔案，以進行哪些變更的特定詳細所有進入該儲存機制的歷程記錄，或變更記錄檔。擁有廣泛詳細歷程記錄誰做了哪些變更的時間，以及這些變更時發生的任何討論 — 是使用原始檔控制系統的最重要的優點之一。記錄可讓整個存放庫可稽核跨時間。如果無法預期的問題出現在發行管線，例如透過單位、 整合或 UI 測試、 揭露回復稍後很容易返回並查看導致該迴歸的特定檔案中的特定變更。
建立 「 簡單 」 的程序的來說其實非常重要一點整體的 DevOps。如前文所談到如何運做為應用程式和服務，其中 「 效能 」 包含客戶經驗和生產環境的成本效能連續驗證本系列的第一篇文章。發行管線可協助您減少成本中盡早有缺失探索的能力。同樣重要的是準確判斷從何處，確切的時間、 缺失確實存在，更快更好 ！ 事實上，就應該曾經花許多令人沮喪天嘗試追蹤在一些專案中，找出修正花 10 秒的所有 bug 的經驗。在這種情況下，幾乎所有的成本會來自只尋找 bug。
如果您或您的小組上的任何人使用原始檔控制，而非只 「 winging 它 「 保留一些簡單的網路共用上的程式碼的物件，這是非常重要的考量。要採用的原始檔控制系統的投資少量支付越專案中，特別是在結合自動化組建、 連續整合和自動化測試，您稍後在未來的發行項的存留期。連續整合表示每個程式碼變更會觸發自動建置和執行自動化的測試，因此該程式碼變更會導致任何一種失敗 （建置或測試），如果您知道它在幾分鐘內。
Team 專案和多個儲存機制
若要建置您的應用程式和服務小組或 Team Foundation Server (TFS) 內自動的發行管線，您開始使用了稱為 team 專案。Team 專案是您執行小組的服務，包括規劃、 追蹤、 透過小組室共同作業的工作項目中建立的所有項目、 持續整合、 測試管理、 發行管理和原始檔控制儲存機制的容器。我說 「 儲存機制 」 這裡 team 專案可以直接裝載多個儲存機制，因此小組建置系統也可以繪製從外部 Git、 GitHub 和 Subversion 存放庫。（同樣地，TFS 可以繪製從儲存機制裝載於 Team Services，反之亦然）。
請注意 team 專案不應該混淆與 Visual Studio 專案或方案;您可以有無數的 Visual Studio 方案，以及從任何其他的開發系統的任何其他程式碼 — 全部都在相同的 team 專案內。基於這個理由，我要考慮的 DevOps 寶藏方塊 team 專案，這有助於避免混淆來說，我和我提醒的 DevOps 電腦來管理 ！
若要建立 team 專案，登入 Team Services 入口網站並按一下 [新增]，在最新的專案和小組。新的命令會顯示的對話方塊，供您選取 Git 或 TFVC 為原始檔控制模型，為專案的預設儲存機制。這其實只是為了方便起見。如果您選擇稍後，您可以建立 Git 儲存機制的 TFVC 做為您很快。如果您選取 Git，您可以加入 TFVC 儲存機制稍後以及多個 Git 儲存機制。如果您想要使用類似 GitHub 外部主機，您根本不會使用預設的儲存機制，且這個選擇不相關。比方說，當 team 專案設定為 MyDriving，我選取 Git 做為預設儲存機制，但所有內容就有是預設讀我檔案，因為真實的專案完全在 GitHub 上裝載。
若要顯示單一 team 專案如何管理多個儲存機制，我會建立範例專案在我的小組服務帳戶] 和 [選取的 TFVC。中所示，一開始會出現這個專案的程式碼] 索引標籤 [圖 6。Team 專案，以及新的儲存機制和管理儲存機制的命令中，按一下外框的控制項顯示現有的儲存機制的清單。新的命令會顯示的對話方塊，其中您一次選取 Git 和 TFVC 之間。因為我一開始會建立含 TFVC 的 team 專案，所以無法建立另一個 TFVC 儲存機制 （只能有一個允許），如所示，我可以建立任意數目的其他 Git 儲存機制，但 [圖 7。
![針對新的專案使用 Team Foundation 版本控制的程式碼] 索引標籤](https://msdn.microsoft.com/zh-tw/mt763232.BrockSchmidt_Figure%206_hires(zh-tw,MSDN.10).png "針對新的專案使用 Team Foundation 版本控制的程式碼] 索引標籤")
[圖 6 使用 Team Foundation 版本控制的新專案的程式碼] 索引標籤
.png "包含多個 Git 儲存機制和 Team Foundation 版本控制儲存機制的 Team 專案")
[圖 7 A Team 專案中有多個 Git 儲存機制和 Team Foundation 版本控制儲存機制
管理儲存機制的命令會帶您前往 Team Services 控制台中，您可以看到所有的儲存機制 （和 Git 分支） 在一次;重新命名或刪除它們。和管理存取權限。所有使用者、 群組和權限的詳細資料 — 討論太多 — 請參閱 「 權限與 Team Services 中的群組 」 文件 (bit.ly/29nxvpd) 「 Git 儲存機制 」 和 「 TFVC 」 區段中。換句話說，您可以運用非常精細的控制每個小組成員的權限。當然，如果您使用的外部來源控制系統，例如 GitHub，您要改為管理站台上的權限。不過請注意，權限的小組專案的整體 — 和不儲存機制，透過該 UI 中顯示 [安全性] 索引標籤來管理。您也可以在先前所述的相同文件頁面中找到這些詳細資料 (bit.ly/29nxvpd)。
填入小組服務儲存機制中的具有程式碼
建立儲存機制之後，最大的問題是如何將您的程式碼中。小組服務會提供各種方法，如同 Visual Studio 中，因此若要關閉這篇文章讓我簡短地執行這些選項。
TVFC 儲存機制中，您可以先將檔案上傳至儲存機制，或建立新的檔案直接透過 Team Services 入口網站。第一次瀏覽程式碼中的索引標籤的 team 專案，然後按一下 [...] 旁的儲存機制和選取 [+ 新增檔案中所示 [圖 8。這會顯示對話方塊 （未顯示） 透過它您可以建立檔案和編輯它們直接在入口網站中，或建立要上傳的檔案清單。在後者的情況下也包括簽入註解。
.png "Visual Studio Team Services 命令，將檔案新增至 Team Foundation 版本控制儲存機制")
[圖 8 Visual Studio Team Services 命令，將檔案新增至 Team Foundation 版本控制儲存機制
若要將程式碼加入至 TFVC 儲存機制的其他方式是透過 Visual Studio 方案總管]。這是非常方便您採用本機方案，並傳送至原始檔控制的所有程式碼。只要以滑鼠右鍵按一下方案，並選取 [將方案加入至原始檔控制中所示 [圖 9。這會顯示的對話方塊，您可以從中選取適當的 team 專案小組的服務帳戶內的電腦上或是特定 TFS。若要連接到伺服器，您可能需要一開始執行，使用 Visual Studio 中的 [Team 總管] ([] 索引標籤底部的概述 [圖 9)。如需詳細資訊，請參閱 「 工作在小組的總管 」 中的主題 Visual Studio 說明文件 (bit.ly/29oGp5j)。
.png "將方案加入至 Visual Studio 中的原始檔控制")
[圖 9 將方案加入至 Visual Studio 中的原始檔控制
Git 儲存機制，小組將會自動提示您使用各種選項當您建立儲存機制，或瀏覽到該程式碼] 索引標籤上，你們夠本身的 UI。或者，您可以在 Visual Studio 中，建立本機 Git 儲存機制，並再將它發行到 Team Services 中的儲存機制。我將不會經過該程序，因為它剛好記載於本主題的 「 共用您的程式碼與 Git 與 Visual Studio 」 (bit.ly/29VDYJg)。簡單來說，不過，就是按一下右下角的 [Visual Studio [狀態] 列，並顯示 Team Explorer 的 [發行] 索引標籤中所示的 [發佈] 按鈕 圖 10。這裡您可以選取要使用的 Team Services 帳戶。重要的細節按一下小型的進階文字選取 team 專案所示。您也可以看到，相同的 UI 可讓您將程式碼發行至 GitHub 和其他外部儲存機制，以及簡單路徑。
.png "在 Visual Studio 中發佈 UI")
[圖 10 發行 Visual Studio 中的 UI
展望未來
使用就地原始檔控制儲存機制，您現在準備好要採取自動化發行管線藉由建立組建和連續整合的下一個步驟。這是我將討論在下一篇文章，您會看到如何在 Visual Studio Team Services 中的任何指定之組建定義可以繪製從任何原始檔控制機制，此處所討論的位置。此外，team 專案時，可以管理任何數目的這類的組建定義，可協調 team 專案，這表示建立從任何數目的儲存機制，情況下可能無法產生發行管線或管線的其餘部分所需的成品。
Kraig Brockschmidt 擔任 Microsoft 的資深內容開發人員，並著重於運用於行動應用程式。 他寫過的 「 使用 HTML、 CSS 和 JavaScript 程式設計 Windows 市集應用程式 」 （兩個版本） 上的部落格與 Microsoft Press kraigbrockschmidt.com。
感謝閱本篇文章的下列技術專家︰ Donovan Brown 和 Gordon Hogenson