Azure DevOps in Action - 從VS2019連結Azure DevOps Repo

Azure DevOps是微軟自家的雲端服務，那使用號稱地表最強的微軟開發工具Visual Studio 2019連上Azure DevOps自然沒什麼問題。

開啟Visual Studio 2019，輸入你的帳號，在Team Explorer頁簽的位置 (下圖1)，點選管理連線(下圖2,3,4)，即可連結到Azure DevOps的Repos，不管你是用哪一個版本的Visual Studio(免費或付費的)都行：

連結時會出現底下畫面：

在(上圖1)的地方，請選擇正確的帳號，該帳號必須是你要連接的Azure DevOps專案的Owner或Member(總之必須是團隊成員)，Visual Studio會列出所有你有權限存取的專案。

然後，請點選你要連接的專案(上圖3)，將其展開，會看到該專案底下所有Repos，如果是Git Repos會以紅色Git符號呈現(上圖4)，如果是TFVC Repos(上圖5，未來我不建議在新的專案中使用)版控，則會是灰色符號呈現。

點選好你要連接的Repos之後，請在路徑(上圖6)的地方輸入該專案你想要Clone到本機的哪個路徑，設定完成後按下『複製』鈕即可。

成功Clone專案之後，你會看到類似底下這樣的畫面：

由於一開始剛初始化的專案中，並沒有.sln, .*proj之類的專案檔，因此會先以上圖這樣的資料夾檢視模式來顯示，你會看到剛才我們建立好的README.md和.gitignore檔案都已經在其中(上圖1)。

這時，你可以點選(上圖2)的Team Explorer，會切換到底下畫面：

你可以在這個畫面中，透過『新增…』連結(上圖1)，來建立一個新的專案(或方案)，當你的專案建立好之後，可以透過『同步』(上圖2)功能，將用戶端的檔案同步到Azure DevOps雲端的Git Repo中。

例如，底下我們隨意建了一個.net專案(project)：

這是一個基本的console專案，建立好之後，你可以看到，在方案總管中，有新建立的程式碼(上圖1)，而上圖右下角的地方，你會看到目前有哪些尚未Commit的檔案(上圖2)，以及當前連結的repo(上圖3)和目前正在使用的分支(Branch, 上圖4)。

你可以透過點選上圖2,3,4這些圖示，來進行相關的操作。例如可以點選上圖2進行Commit，當您點選之後，會出現底下畫面：

你可以在上圖B的地方填寫Comment，然後選擇Commit：

上面是中文版的翻譯，認可是Commit，推送是Push，同步是Sync(他會先拉再推，這樣可以避免衝突)，我們可以試著選擇『全部認可並同步』，結果會把所有程式碼同步到Azure DevOps雲端的Git Repos：

你會發現在原本站台的Repos中，出現了我們剛才簽入的檔案。如此這般，基本上，所有操作跟一般的Git版控使用原則完全相同。

當我們在本機的開發環境，修改了某一段程式碼之後，你會看到Visual Studio的畫面有些許變動：

你應該不難發現，那隻被改過的程式碼檔案的前面，多了一個紅色小勾勾(上圖A)，同時右下角出現了尚未Committed檔案的數量(上圖B)，這是提醒你，你的程式碼尚未簽入。

而未Committed檔案數量左邊的『↑0』，則是已經committed卻尚未推上雲端repo的change數量(目前是零)。

有時候我們不會每commit幾個檔案，就立刻push/sync到雲端的repo，而是多幾次commit之後，才一口氣sync到雲端，特別是離線開發的時候。

好了，如果你平時有在使用版控，這些應該相當熟悉。若過去你完全沒有使用任何版本控制軟體的經驗，我建議你可以針對這個主題，在坊間找1-2本有關的書籍參考，畢竟目前版控已經是軟體開發的基本功。

當你讓團隊中所有開發人員都連上同一個Azure DevOps的Git Repo之後，即便是團隊成員在遠端，大夥兒一起開發軟體也不是問題。更重要的是，所有團隊中的開發人員，大夥有一個一致的基準點，只要頻繁地(每天數次最好，最差也得一兩天一次)把個人開發環境的程式碼與伺服器端的Git Repos同步，如此一來，即便是多人合作，程式碼也不會發生衝突。(當然最好是不要同時兩個人改同一支程式碼，如果真有必要，可以考慮利用partial class把同一個類別切成兩個檔案。)

而未來的幾篇文章中，我們馬上會進入到CI(continuous integration)/自動建置(Auto Build)，也就是說，當團隊中有任何開發人員，把寫完的功能(程式碼)簽入系統，並成功推入程式碼儲存庫(Repo)之後，Azure DevOps會自動觸發一個自動化的CI流程，把雲端上(Azure DevOps Repo)內的程式碼拉出來，自動在雲端上進行Build的動作(甚至Build完可以自動佈署，如果你願意的話)，一周(甚至一天)數次。

如此一來，即便開發團隊中有多位開發人員(就算根本是在遠端而非在同一個辦公室一起工作)，我們也可以頻繁的整合，提早發現程式碼中可能的潛在問題與衝突。

而非像是過去，直到準備把系統交付給客戶的時候，大家才把各自手上的模組拿出來整合，結果跟本兜不起來，更罔論想要正確的執行了。

如今，對於許多新創團隊或是企業而言，CI(continuous integration, 持續整合)、頻繁交付..這些個概念已經跟喝水一樣自然。但誰能想像，也不過才10幾年前，沒有CI工具的時候，軟體開發完全不是現在這麼一回事。每當開發團隊要把所有成員分別開發的程式碼，合併在一起執行的時候，屢屢都像是作戰一樣，每個人的程式碼跟一大串攪成一坨的粽子線一般、模組衝突的一堆、套件不合的一堆、版本錯亂的一堆…剪不斷理還亂。當年，每次要進行整合都是噩夢一場。

對了，我們也可以透過Visual Studio建立或管理分支(Branch)：

點選上圖中A的部分，你會看到管理分支、新增分支的選單，你可以在用戶端新增分支，然後同步到雲端。也可以透過管理分支切換到其他團隊成員所建立的分支上開發或檢視。

分支是Git版控中相當重要的機制，你使用Git，幾乎沒有任何理由不使用分支，因此開發人員對於分支要有一定的基本概念(我們後面會找機會更多的介紹)。

---------------------------
相關課程：http://www.studyhost.tw/NewCourses/ALM
節錄自『Azure DevOps in Action』