![[faq]Azure DevOps如何透過設定Service Connection連到非同帳號的Azure 訂閲 - powershell篇.jpg](/posts/2019/07/2019-07-11-faq-azure-devops-set-up-service-connection-to-azure-subscription-belong-to-another-account-using-powershell/b96232ab-5bcd-49a1-be4e-6f25d7262b06.jpg)
在上一篇([faq]Azure DevOps如何透過設定Service Connection連到非同帳號的Azure 訂閲 - GUI篇)介紹了如何透過GUI的方式在Azure建立出Service Principal用來在Azure DevOps設定Service Connections的時候用來作爲登入的驗證方式。
不過GUI雖然直覺，但是Azure如果有改版那麽很有可能資訊的位置會換，這個時候要在產生Service Principal又可能要找一下。
更好的方式其實可以透過用script的方式得到結果 - 這樣不管誰來做，得到的結果都會是一樣的 - 並且需要的資訊也可以一目瞭然，不用切來切去找不同訊息的位置。
這篇來看一下，如何透過powershell的方式，快速建立出Service Principal。
Azure DevOps裡面的Pipeline功能讓做軟體開發裡面的CI (Continuous Integration) 以及CD (Continuous Develiery) 非常的容易。
其中，在CD的時候把結果部署到Azure上面是很常見的一個需求。
在Azure DevOps裡面設定可以部署到那個Azure訂閲裡面是透過設定Service Connection，如果目前登入到Azure DevOps的帳號有權限操作Azure訂閲，那麽設定Service Connection非常的容易。
但是如果沒有呢？畢竟管理Azure DevOps和管理Azure很有可能是兩個不同的帳號。
這個時候怎麽辦呢？
這篇來看看如何透過在Azure建立App以及Service Principal，然後在Azure DevOps使用這些資訊建立出Service Connection能夠CD部署到Azure上面。
![[05][讓團隊彼此知道程式碼走向]如何强制走Pull Request以及設定符合規則才能合並分支.jpg](/posts/2019/06/2019-06-11-code-review-05-force-use-pull-request-and-set-rules-before-pull-request-can-be-complete/2fe0b23e-7ffa-4d3c-99e6-cacf5b54253b.jpg)
在上一篇([04][讓團隊彼此知道程式碼走向]整合的威力 - 整個Review的過程)介紹完了整個Code Review的過程，從最一開始的需求，到修改好之後，透過Pull Request做Code Review然後把修改合並回主線。
基本上所有的功能基本都會使用了，但是還有一個很大的問題：如果開發者不走Pull Request的話一切不都完了？
這一篇將來看一下，如何强制要求一定要走Pull Request，並且一些設定讓Pull Request一定要有符合某些條件才可以結束。
![[04][讓團隊彼此知道程式碼走向]整合的威力 - 整個Review的過程.jpg](/posts/2019/06/2019-06-08-code-review-04-integrate-together-flow-of-code-review-from-issue-to-complete-in-azure-devops/f3c2a321-d60a-4e4f-9568-fd025c4b1fe7.jpg)
在上一篇([03]Azure DevOps的Pull Request提供了什麽功能？)瞭解了整個Azure DevOps的Pull Request功能之後，接下來就是看看在實際上如果整個串起來是什麽感覺。
這篇將從做一開始的需求，到最後整個功能確認修改好並且合併回主要分支。
這一篇也希望可以看到Azure DevOps這種一整套整合好的工具的好處。
![[03][讓團隊彼此知道程式碼走向]Azure DevOps的Pull Request提供了什麽功能？.jpg](/posts/2019/05/2019-05-29-code-review-03-azure-devops-pull-request-functionality/20593d82-928b-44fd-9d76-c3531686ac3c.jpg)
在上一篇(何爲Pull Request並且如何建立 - 以Azure DevOps爲例)介紹了如何透過建立branch來把修改獨立出來，並且在修改完成之後透過建立Pull Request的方式建立出可以Code Review的一個請求。
這一篇將來看看Azure DevOps裡面的Pull Request包含了那些功能。
![[02][讓團隊彼此知道程式碼走向]何爲Pull Request並且如何建立 - 以Azure DevOps爲例.jpg](/posts/2019/05/2019-05-19-code-review-02-what-is-pull-request-and-how-to-create-it-in-azure-devops/cff4d33d-d173-45eb-9810-afad50964211.jpg)
在上一篇([01]淺談Code Review的好處及意義篇 - 讓團隊彼此知道程式碼走向)瞭解了什麽是Code Review以及爲什麽可能會想要做Code Review之後。
下一個問題就是，如果真的想開始實行該怎麽做呢？
這一篇來介紹一下Pull Request的概念，以及如何協助做Code Review。
![[Azure DevOps]如何設定Pull Request的預設文字模板(template).jpg](/posts/2019/03/2019-03-21-best-practice-how-to-setup-pull-request-template-in-azure-devops-with-set-default-branch/f449addd-d546-46fa-89e6-9fa7b5b8a510.jpg)
Pull Request是一個非常好的Code Review方式，也是當初Github讓git火紅起來的其中一個原因之一。
在建立Pull Request的時候，一般會有一段訊息可以輸入，這個訊息主要描述了這一次Pull Request的一個主要目的。
但是，當團隊合作開發的時候，很有可能A工程師會輸入一種格式的内容，而B工程師又是另外一種。或者有時候有些條件需要符合才應該發起Pull Request，但是工程師忘記了，造成Reviewer需要花時間最後才發現根本最基本的條件都沒達到。
有沒有什麽方式可以提醒工程師在Pull Request發起的訊息要打好，並且該檢查的東西都要檢查過了呢？
這一篇，來看看在Azure DevOps裡面，如何透過建立template(範本)達到這個需求。
.png "image")
Visual Studio Team Services (VSTS) 可以簡單理解成為雲端版的Team Foundation Server (TFS)，而且微軟很佛心的讓5人以下團隊免費使用。
在建立VSTS的時候，有個選項是VSTS的資料要放在哪個區域（Region）。早期的時候，只有在美國，現在的話在東亞（East Asia）也有辦法建立了。
不過如果是早期建立在美國的VSTS是否能夠移動到East Asia呢？這篇將會介紹如何透過寫VSTS的support ticket來達到這個轉換。
.png "image")
在上篇[iThome第8屆鐵人賽 20]靜態程式碼分析之程式碼風格 - Stylecop介紹完了如何整合stylecop之後，build階段也差不多到了一個階段。
在這個階段裡面，從最基本的編譯、到執行單元測試、到整合程式碼測試的涵蓋率最後整合Code Analysis和stylecop，整個build基本要做的都做了，因此我們要開始進入如何把這個建制整合到builder server來達到CI的效果
在這篇，將會談到：
.png "image")
在2017/06/24的時候非常有榮幸和大家在Study4的6月場次裡面介紹了git。
我對於大家聽完的感想其實非常有興趣，因此做了一個問卷請大家幫忙填寫。
大家都那麼認真幫我做了填寫，我當然也要認真的把大家的建議納入進去 - 因此這篇我將會對我看問卷的結果和自己時候思考到的問題總結一下，作為未來修正的參考。
_1477.png)
_1485.png)
_1486.png)