我曾經聽過一個笑話，一個人到一家公司面試，面試官問他：「請問你如何保證/保持你的程式碼品質？」
這個年輕人回答：「我...我會在發現bug的時候把問題加班修好」。
其實這個有點悲哀，也說明了為什麼軟體工程師時常需要加班，因為當軟體越寫越複雜的時候，要保持程式的品質是需要一些事情，但是這些事情是什麼？有沒有可能進入到我們日常環境里？
這個就是接下來會介紹的部分，我們如何透過做CI把程式碼品質要做的事情整合進來。
2016年12月25日 星期日
[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
2016年12月17日 星期六
[iThome第8屆鐵人賽 08]建制結果問題 - 方法2 透過MSBuild的Target
在上篇了解到如果什麼都沒調整的情況下，建制出來的內容會放在一起，根本無法區分哪些內容屬於哪些專案。
也提到了.Ner 4.5能夠使用GenerateProjectSpecificOutputFolder，但是假設是.Net 4.5以下呢？
這篇我們會沿著這個思路，看看為什麼Asp .Net Mvc專案有個_PublishedWebsite，並且我們是否能夠使用這個資訊來做些處理。
sample 程式在 github devops-psake sample/chapter8
訂閱：
文章
(
Atom
)