在上一篇([26]Package階段介紹)介紹完了Package階段主要做的兩個事情：打包的格式，以及用來區分差異的版號 (version)。
在接下來的幾篇將會介紹和版號有關的內容。
這篇會從最基本的開始，在.Net裡面是如為某一個library產生出來的dll打上版號?如何看到這個版號的資訊呢？
2018年2月11日 星期日
[從.Net工程師的角度來看DevOps][27]如何看.Net Dll版號和如何給.Net的Dll打上版號
2018年2月10日 星期六
[從.Net工程師的角度來看DevOps 26]Package階段介紹
在上一篇([25]在Visual Studio Team Services執行Build Script和CI Server總結)介紹完了VSTS的build建制之後，基本上build階段算是告一個段落了。
到目前為止，我們的build script不管是在CI Server那一端，還是在local端都能夠執行一樣的build script來產生出能夠執行的內容。
接下來就要進入另外一個階段，也就是怎麼把產生出的內容打包成為適合發佈用的階段，也就是：package。
這篇將會對於package階段的內容做個基本介紹。
2017年12月25日 星期一
[Data Science 到底是什麼從一個完全外行角度來看][07]更深入看看Hadoop裡面的YARN和HDFS
在上一篇（[06]建立Hadoop環境 -下篇）把hadoop pseudo-distributed mode整個建立了起來，在這個過程中有透過 jps看到啟動的時候有5個process：
- NameNode
- SecondaryNameNode
- ResourceManager
- NodeManager
- DataNode
這些process分別是yarn和HDFS執行起來的process，其中Master會有前 3個而slave有後 2個
這篇將會對於這幾個問題做一些介紹。
這篇提到的架構屬於Hadoop 2.x 版本的內容，Hadoop 3 之後有所變動。
2017年12月16日 星期六
[從.Net工程師的角度來看DevOps 25]在Visual Studio Team Services執行Build Script和CI Server總結
在上一篇（[從.Net工程師的角度來看DevOps 24]免費build私人Repo的CI Service - Visual Studio Team Service介紹）了解了如何用Visual Studio Team Services（VSTS）的內建Template來build範例專案；在設定的過程，其實沒辦法直接使用內建template，會需要調整一些參數。
這些調整的內容和AppVeyor要調整的非常不一樣，造成了如果要換CI Server會花一些時間在這些瑣碎的細節上面。
這篇將會看看，如果要把VSTS改成用build script來build專案，會需要做些什麼。
2017年12月13日 星期三
[從.Net工程師的角度來看DevOps 24]免費build私人Repo的CI Service - Visual Studio Team Service介紹
在上一篇（[從.Net工程師的角度來看DevOps 23]在AppVeyor執行Build Script - 整合build資訊到github）介紹完了如何用AppVeyor執行我們定義的build script，不過有時候我們有私人的repo也希望做CI，這個時候免費版本的AppVeyor就不夠了。
這邊將會介紹另外一個能夠build私人repo，由Microsoft提供的免費CI服務，Visual Studio Team Service（VSTS）。
這篇先看內建VSTS所提供的方式來建制範例專案，在下篇在改成執行我們的build script。
題外話，假設之前已經有VSTS帳號，想要移動Region到East Asia，可以參考這篇：[VSTS]如何調整Visual Studio Team Service的區域(Region)
[從.Net工程師的角度來看DevOps 23]在AppVeyor執行Build Script - 整合build資訊到github
在上一篇（[從.Net工程師的角度來看DevOps 22]免費的CI Server - AppVeyor介紹）了解到了如何把專案關聯到AppVeyor裡面，然後可以很簡單利用AppVeyor裡面內建的一些設定來build專案。
在這篇，我們將完全拋棄AppVeyor的內建機制，改成用我們建立出來的build script來執行。
有自己的build script不止在設定上變得更簡單，local跑的和CI Server跑的會一樣，並且如果要整合到另外一個CI Server也不會有什麼問題。
sample 程式在 github devops-psake sample/chapter23
2017年12月12日 星期二
[從.Net工程師的角度來看DevOps 22]免費的CI Server - AppVeyor介紹
圖片來源：https://pixabay.com/en/books-spine-colors-pastel-1099067/ 和 https://blog.xebialabs.com/2016/03/21/essential-devops-terms/
在上一篇([從.Net工程師的角度來看DevOps 21]Build階段的總結和重構 - Build Server介紹)對我們的build script在做了一次重構之後，這篇我們來看看一個佛心的CI Server：Appveyor。
CI Server不是什麼新的概念，一直以來有一些免費的CI Server可以使用，例如Travis CI - 不過多是Linux base的Server。 但是由於Windows版權的問題，.Net沒有什麼免費（至少從Open Source專案角度來看）的CI Server 可以用，直到AppVeyor的出現，和後來的Visual Studio Team Service。
在這篇，將會簡單介紹AppVeyor，並且如何把我們的專案準備好，在下一篇在介紹如何整合AppVeryor執行我們的build script。
2017年7月30日 星期日
[從.Net工程師的角度來看DevOps 21]Build階段的總結和重構 - Build Server介紹
在上篇[iThome第8屆鐵人賽 20]靜態程式碼分析之程式碼風格 - Stylecop介紹完了如何整合stylecop之後，build階段也差不多到了一個階段。
在這個階段裡面，從最基本的編譯、到執行單元測試、到整合程式碼測試的涵蓋率最後整合Code Analysis和stylecop，整個build基本要做的都做了，因此我們要開始進入如何把這個建制整合到builder server來達到CI的效果
在這篇，將會談到：
- 在一次重構和調整script - 以符合上build server執行的時候比較沒有問題
- 對build server做個簡單的介紹
sample 程式在 github devops-psake sample/chapter21
2017年1月15日 星期日
[iThome第8屆鐵人賽 20]靜態程式碼分析之程式碼風格 - Stylecop
在上篇介紹了如何透過使用Code Analysis來達到程式碼品質的分析。
在這一篇將會從另外一個層面介紹使用靜態程式碼分析來達到程式碼風格的一致性 - Stylecop。
sample 程式在 github devops-psake sample/chapter20
[iThome第8屆鐵人賽 19]靜態程式碼分析之Assembly品質分析 - Code Analysis(以前的FxCop)
在了解完如何分析測試碼的涵蓋率(也代表測試品質)之後，我們將來看另外一種保持程式碼品質的方式，也就是透過靜態程式碼分析。
在.Net的世界里，從最早期的而外工具FxCop，到後來進化成為VS一部分的Code Analysis就是專門在做這個方面工作的工具。
在這篇將會介紹如何使用Code Analysis，並且如何把它整并到我們的Build Script裡面。
廣義來說，靜態程式碼分析應該是針對源代碼(Source Code)作分析，實際上Code Analysis其實是對Assembly作分析，而Assembly也是IL，所以真的要叫做靜態程式碼分析應該也沒錯，只是 真的要嚴格說起來，Code Analysis應該不能夠稱之為靜態程式碼分析。不過以下我還是會稱之為靜態程式碼分析。(有點繞口)
sample 程式在 github devops-psake sample/chapter19
2017年1月14日 星期六
[iThome第8屆鐵人賽 18]OpenCover 結果 - html結果產生篇
在上篇了解到了測試涵蓋率的計算方式之後，已經可以了解xml報告的一些數字所代表的意思。
但是，xml畢竟不是那麼容易讀得懂，並且也不容易看出到底那些地方沒有測試到。
在這篇，將會介紹如何把xml結果產生出html結果，並且如何使用。
sample 程式在 github devops-psake sample/chapter18
[iThome第8屆鐵人賽 17]OpenCover 結果 - 涵蓋率介紹篇
在上篇把OpenCover整合到測試之後，每當執行測試後會產生出一個涵蓋率的結果報告出來。
這個涵蓋率的結果是一個xml的檔案，這個xml其實有非常豐富的資訊，但是沒有一些基礎概念會不理解是什麼意思。
因此，在這篇，將會對於涵蓋率相關的資訊做一個介紹和說明。
2017年1月2日 星期一
[iThome第8屆鐵人賽 16]OpenCover 整合篇
在上篇介紹了OpenCover的基本運作概念和為什麼要使用OpenCover，在這篇將會實際把OpenCover整合到Build Script裡面。
sample 程式在 github devops-psake sample/chapter16
2017年1月1日 星期日
[iThome第8屆鐵人賽 15]OpenCover 介紹篇
OpenCover是一個.Net Open Source的測試涵蓋率檢測的工具，透過這個Library，可以檢測出，對於整個程式的測試涵蓋率到底有多少 （當然，要注意一個迷失就是，不一定都要100 %的涵蓋率）。
這篇將會先對如何使用OpenCover做一個初步的介紹，在下篇才會把OpenCover實際整合到build script裡面。
2016年12月25日 星期日
[iThome第8屆鐵人賽 14]程式碼品質 - 介紹篇
我曾經聽過一個笑話，一個人到一家公司面試，面試官問他：「請問你如何保證/保持你的程式碼品質？」
這個年輕人回答：「我...我會在發現bug的時候把問題加班修好」。
其實這個有點悲哀，也說明了為什麼軟體工程師時常需要加班，因為當軟體越寫越複雜的時候，要保持程式的品質是需要一些事情，但是這些事情是什麼？有沒有可能進入到我們日常環境里？
這個就是接下來會介紹的部分，我們如何透過做CI把程式碼品質要做的事情整合進來。
[iThome第8屆鐵人賽 13]執行測試 4 - 重構
在之前幾篇已經介紹完了.Net常見的三種Test Framework（Xunit，Nunit 和 MSTest）整合方式之後，相信會發現到這三個task有很地方是重複邏輯。
這些重複邏輯我們都是用了copy 和 paste 的方式處理了，但是未來如果要維護這個build script，甚至要把它變成一個常用/通用的script，這種方式是非常不好
所以，就像任何好的工程師會做的事情一樣，我們也要重構我們的Script。
這篇將會介紹重構什麼，和如何重構。
sample 程式在 github devops-psake sample/chapter13
[iThome第8屆鐵人賽 12]執行測試 3 - MSTest
在介紹完Xunit和Nunit測試之後，這篇將要來看最後一個常見的測試Framework，Visual Studio內建的MSTest。
sample 程式在 github devops-psake sample/chapter12
[iThome第8屆鐵人賽 11]執行測試 2 - NUnit .Net
sample 程式在 github devops-psake sample/chapter11
2016年12月23日 星期五
[iThome第8屆鐵人賽 10]執行測試 1 - XUnit .Net
經過一段時間的介紹，相信對於使用psake來建制專案已經沒什麼問題了 - 我們就要開始進入建制的下個階段，也就是測試。
專案建制起來只是基本條件，但是單元測試是否有通過才是保證程式碼品質的一種方式，因此，不跑單元測試更本就不完整。
在接下來幾篇，將會介紹幾個常見的unit test的framework，先從xunit開始。
sample 程式在 github devops-psake sample/chapter10
2016年12月20日 星期二
[iThome第8屆鐵人賽 09]建制失敗的處理 - 為什麼失敗了但是build server還是認為成功
在進入下個階段之前（也就是開始執行Unit Test），有個部分一直沒有碰到，那就是當建制失敗的時候會發生什麼事情。
整個CI的概念就是盡早發現建制有問題好去做一些處理，但是如果出錯了都發現不到，不就等於沒有意義了？
這篇我們將會看看這方面的處理。
sample 程式在 github devops-psake sample/chapter9
訂閱：
文章
(
Atom
)