powershell

在上一篇([faq]Azure DevOps如何透過設定Service Connection連到非同帳號的Azure 訂閲 - GUI篇)介紹了如何透過GUI的方式在Azure建立出Service Principal用來在Azure DevOps設定Service Connections的時候用來作爲登入的驗證方式。

不過GUI雖然直覺，但是Azure如果有改版那麽很有可能資訊的位置會換，這個時候要在產生Service Principal又可能要找一下。

更好的方式其實可以透過用script的方式得到結果 - 這樣不管誰來做，得到的結果都會是一樣的 - 並且需要的資訊也可以一目瞭然，不用切來切去找不同訊息的位置。

這篇來看一下，如何透過powershell的方式，快速建立出Service Principal。

這段時間對於.NET開發者 (或者任何關注于微軟技術的開發者) 來説最大的新訊息莫過於Build 2019的大會内容了。

相信大會上面有很多Session是大家感興趣的，有些甚至希望下載下來能夠放到手機或者平板在網路不好的時候可以觀看。

不過每一個有興趣的Session都需要一個一個點下載實在太過於麻煩，更別説除了影片之外，還有可能有slide、字幕等等可以下載。

太麻煩了，懶惰是工程師的美德，這篇看看如何用Powershell自動下載所有的Session。

分支(branch)可以説是git的殺手鐧功能，透過建立分支就像使用多重影分身之術一樣，可能同時進行不同分支的開發，最後可以透過合并(merge)把所有的修改整合在一起。

不過開啓大量分支有一個缺點，那就是當合并成功之後，怎麽清理不需要的分支。

這篇就來看看怎麽快速清理掉這些無用的"分身"。

最近在製作上傳到Azure的VHD的時候就遇到，需要開一些特定的port。

作爲coder，懶是一種美德，因此當然想要透過使用powershell的方式把整個動作自動化。

Azure官方文件有些範例script可以參考，但是實際使用起來卻有個但書，就是只能在英文版的OS才有作用（畢竟是外國人寫的script），其他語系就gg了。

因爲這個原因，所以去找了一些資料，才發現原來要支援多語系的Windows沒有那麽直覺，因此這邊記錄一下以供未來參考。

在上一篇（[從.Net工程師的角度來看DevOps 22]免費的CI Server - AppVeyor介紹）了解到了如何把專案關聯到AppVeyor裡面，然後可以很簡單利用AppVeyor裡面內建的一些設定來build專案。

在這篇，我們將完全拋棄AppVeyor的內建機制，改成用我們建立出來的build script來執行。

有自己的build script不止在設定上變得更簡單，local跑的和CI Server跑的會一樣，並且如果要整合到另外一個CI Server也不會有什麼問題。

在上篇[iThome第8屆鐵人賽 20]靜態程式碼分析之程式碼風格 - Stylecop介紹完了如何整合stylecop之後，build階段也差不多到了一個階段。

在這個階段裡面，從最基本的編譯、到執行單元測試、到整合程式碼測試的涵蓋率最後整合Code Analysis和stylecop，整個build基本要做的都做了，因此我們要開始進入如何把這個建制整合到builder server來達到CI的效果

在這篇，將會談到：

1. 在一次重構和調整script - 以符合上build server執行的時候比較沒有問題
2. 對build server做個簡單的介紹

在上篇[iThome第8屆鐵人賽 20]靜態程式碼分析之程式碼風格 - Stylecop介紹完了如何整合stylecop之後，build階段也差不多到了一個階段。

在這個階段裡面，從最基本的編譯、到執行單元測試、到整合程式碼測試的涵蓋率最後整合Code Analysis和stylecop，整個build基本要做的都做了，因此我們要開始進入如何把這個建制整合到builder server來達到CI的效果

在這篇，將會談到：

1. 在一次重構和調整script - 以符合上build server執行的時候比較沒有問題
2. 對build server做個簡單的介紹

在了解完如何分析測試碼的涵蓋率(也代表測試品質)之後，我們將來看另外一種保持程式碼品質的方式，也就是透過靜態程式碼分析。

在.Net的世界里，從最早期的而外工具FxCop，到後來進化成為VS一部分的Code Analysis就是專門在做這個方面工作的工具。

在這篇將會介紹如何使用Code Analysis，並且如何把它整并到我們的Build Script裡面。

在上篇介紹了如何透過使用Code Analysis來達到程式碼品質的分析。

在這一篇將會從另外一個層面介紹使用靜態程式碼分析來達到程式碼風格的一致性 - Stylecop。

在上篇了解到了測試涵蓋率的計算方式之後，已經可以了解xml報告的一些數字所代表的意思。

但是，xml畢竟不是那麼容易讀得懂，並且也不容易看出到底那些地方沒有測試到。

在這篇，將會介紹如何把xml結果產生出html結果，並且如何使用。

在上篇介紹了OpenCover的基本運作概念和為什麼要使用OpenCover，在這篇將會實際把OpenCover整合到Build Script裡面。

在介紹完Xunit和Nunit測試之後，這篇將要來看最後一個常見的測試Framework，Visual Studio內建的MSTest。

在之前幾篇已經介紹完了.Net常見的三種Test Framework（Xunit，Nunit 和 MSTest）整合方式之後，相信會發現到這三個task有很地方是重複邏輯。

這些重複邏輯我們都是用了copy 和 paste 的方式處理了，但是未來如果要維護這個build script，甚至要把它變成一個常用/通用的script，這種方式是非常不好

所以，就像任何好的工程師會做的事情一樣，我們也要重構我們的Script。

這篇將會介紹重構什麼，和如何重構。

經過一段時間的介紹，相信對於使用psake來建制專案已經沒什麼問題了 - 我們就要開始進入建制的下個階段，也就是測試。

專案建制起來只是基本條件，但是單元測試是否有通過才是保證程式碼品質的一種方式，因此，不跑單元測試更本就不完整。

在接下來幾篇，將會介紹幾個常見的unit test的framework，先從xunit開始。

在進入下個階段之前（也就是開始執行Unit Test），有個部分一直沒有碰到，那就是當建制失敗的時候會發生什麼事情。

整個CI的概念就是盡早發現建制有問題好去做一些處理，但是如果出錯了都發現不到，不就等於沒有意義了？

這篇我們將會看看這方面的處理。

上篇我們提到了用psake來建制一個asp .net mvc的專案，並且修正了psake執行時候呈現的內容，在這篇，我們將進一步延伸來看一下，buid結束產生的內容是什麼和 加入另外兩種常見的.Net專案：

1. Console Project
   
2. Library Project

在上篇了解到如果什麼都沒調整的情況下，建制出來的內容會放在一起，根本無法區分哪些內容屬於哪些專案。

也提到了.Ner 4.5能夠使用GenerateProjectSpecificOutputFolder，但是假設是.Net 4.5以下呢？

這篇我們會沿著這個思路，看看為什麼Asp .Net Mvc專案有個_PublishedWebsite，並且我們是否能夠使用這個資訊來做些處理。

經過了幾天的理論介紹，我們開始要進入建制專案的部分。

我們會先拿一個Asp .net Mvc的網站作為第一個要建制的專案，所以我們會先建立出來，然後在使用MSBuild帶來的幫助，幫我們快速建立專案

（之後下面提到的code都可以從這邊看到內容：github repo，這篇會是tag sample/chapter6）

在上篇對於psake有些了解以後，我們開始把所學的東西用於如何搭配方便建制專案。

在這篇，我們會定義當專案建制的時候，我們的資料夾結構和先把那些資料夾環境準備好

在上一篇了解了如何建制一個專案之後，和我們之後要使用psake作為build tool，在這篇我們將會看到底怎麼開始使用psake，和建立出我們之後會一直使用的專案。

（之後下面提到的code都可以從這邊看到內容：github repo，這篇會是tag sample/chapter4）

在上篇了解到說什麼是DevOps之後，我們就開始探討第一個部分，也就是Continous Integration (CI)。

CI最基本的核心就是build專案 - 所以我們需要了解一下到底VS是如何build專案的，只有了解之後我們才能夠把它腳本化，也才有可能自動化。

因此，這篇將會介紹：

1. VS到底如何建制專案
   
2. 什麼是build tool
   
3. 為什麼接下來系列會選擇使用psake作為build tool