devops


[從.Net工程師的角度來看DevOps][27]如何看.Net Dll版號和如何給.Net的Dll打上版號

image
圖片來源:https://pixabay.com/en/books-spine-colors-pastel-1099067/ 和 https://blog.xebialabs.com/2016/03/21/essential-devops-terms/

在上一篇([26]Package階段介紹)介紹完了Package階段主要做的兩個事情:打包的格式,以及用來區分差異的版號 (version)

在接下來的幾篇將會介紹和版號有關的內容。

這篇會從最基本的開始,在.Net裡面是如為某一個library產生出來的dll打上版號?如何看到這個版號的資訊呢?


[從.Net工程師的角度來看DevOps 26]Package階段介紹

image
圖片來源:https://pixabay.com/en/books-spine-colors-pastel-1099067/ 和 https://blog.xebialabs.com/2016/03/21/essential-devops-terms/

在上一篇([25]在Visual Studio Team Services執行Build Script和CI Server總結)介紹完了VSTS的build建制之後,基本上build階段算是告一個段落了。

到目前為止,我們的build script不管是在CI Server那一端,還是在local端都能夠執行一樣的build script來產生出能夠執行的內容。

接下來就要進入另外一個階段,也就是怎麼把產生出的內容打包成為適合發佈用的階段,也就是:package

這篇將會對於package階段的內容做個基本介紹。


[Data Science 到底是什麼從一個完全外行角度來看][07]更深入看看Hadoop裡面的YARN和HDFS

image
圖片來源: https://pixabay.com/en/books-spine-colors-pastel-1099067/https://pixabay.com/en/math-blackboard-education-classroom-1547018/

在上一篇([06]建立Hadoop環境 -下篇)把hadoop pseudo-distributed mode整個建立了起來,在這個過程中有透過 jps看到啟動的時候有5個process:

  1. NameNode
  2. SecondaryNameNode
  3. ResourceManager
  4. NodeManager
  5. DataNode

這些process分別是yarn和HDFS執行起來的process,其中Master會有前 3個而slave有後 2個

這篇將會對於這幾個問題做一些介紹。

這篇提到的架構屬於Hadoop 2.x 版本的內容,Hadoop 3 之後有所變動。

[從.Net工程師的角度來看DevOps 25]在Visual Studio Team Services執行Build Script和CI Server總結

image
圖片來源:https://pixabay.com/en/books-spine-colors-pastel-1099067/ 和 https://blog.xebialabs.com/2016/03/21/essential-devops-terms/

在上一篇([從.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專案,會需要做些什麼。


[從.Net工程師的角度來看DevOps 23]在AppVeyor執行Build Script - 整合build資訊到github

image
圖片來源:https://pixabay.com/en/books-spine-colors-pastel-1099067/ 和 https://blog.xebialabs.com/2016/03/21/essential-devops-terms/

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

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

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


[從.Net工程師的角度來看DevOps 24]免費build私人Repo的CI Service - Visual Studio Team Service介紹

image
圖片來源:https://pixabay.com/en/books-spine-colors-pastel-1099067/ 和 https://blog.xebialabs.com/2016/03/21/essential-devops-terms/

在上一篇([從.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 22]免費的CI Server - AppVeyor介紹

image
圖片來源: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。


[從.Net工程師的角度來看DevOps 21]Build階段的總結和重構 - Build Server介紹

image圖片來源:https://pixabay.com/en/books-spine-colors-pastel-1099067/ 和 https://blog.xebialabs.com/2016/03/21/essential-devops-terms/

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

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

在這篇,將會談到:

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

[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應該不能夠稱之為靜態程式碼分析。不過以下我還是會稱之為靜態程式碼分析。(有點繞口)

[iThome第8屆鐵人賽 20]靜態程式碼分析之程式碼風格 - Stylecop

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

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


[iThome第8屆鐵人賽 17]OpenCover 結果 - 涵蓋率介紹篇

在上篇把OpenCover整合到測試之後,每當執行測試後會產生出一個涵蓋率的結果報告出來。

這個涵蓋率的結果是一個xml的檔案,這個xml其實有非常豐富的資訊,但是沒有一些基礎概念會不理解是什麼意思。

因此,在這篇,將會對於涵蓋率相關的資訊做一個介紹和說明。


[iThome第8屆鐵人賽 18]OpenCover 結果 - html結果產生篇

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

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

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


[iThome第8屆鐵人賽 16]OpenCover 整合篇

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


[iThome第8屆鐵人賽 15]OpenCover 介紹篇

OpenCover是一個.Net Open Source的測試涵蓋率檢測的工具,透過這個Library,可以檢測出,對於整個程式的測試涵蓋率到底有多少 (當然,要注意一個迷失就是,不一定都要100 %的涵蓋率)。

這篇將會先對如何使用OpenCover做一個初步的介紹,在下篇才會把OpenCover實際整合到build script裡面。


[iThome第8屆鐵人賽 14]程式碼品質 - 介紹篇

我曾經聽過一個笑話,一個人到一家公司面試,面試官問他:「請問你如何保證/保持你的程式碼品質?」

這個年輕人回答:「我...我會在發現bug的時候把問題加班修好」。

其實這個有點悲哀,也說明了為什麼軟體工程師時常需要加班,因為當軟體越寫越複雜的時候,要保持程式的品質是需要一些事情,但是這些事情是什麼?有沒有可能進入到我們日常環境里?

這個就是接下來會介紹的部分,我們如何透過做CI把程式碼品質要做的事情整合進來。


[iThome第8屆鐵人賽 13]執行測試 4 - 重構

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

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

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

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


[iThome第8屆鐵人賽 12]執行測試 3 - MSTest

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


[iThome第8屆鐵人賽 11]執行測試 2 - NUnit .Net

在上篇介紹完如何整合Xunit做測試之後,在這篇我們將會看看在.Net世界裡面另外一個常用的測試Framework,NUnit。

[iThome第8屆鐵人賽 10]執行測試 1 - XUnit .Net

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

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

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


[iThome第8屆鐵人賽 09]建制失敗的處理 - 為什麼失敗了但是build server還是認為成功

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

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

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

sample 程式在 github devops-psake sample/chapter9

[iThome第8屆鐵人賽 07]建制結果問題 - 說明 和 處理方法 1

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

  1. Console Project
  2. Library Project


sample 程式在 github devops-psake sample/chapter7

[iThome第8屆鐵人賽 08]建制結果問題 - 方法2 透過MSBuild的Target

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

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

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

sample 程式在 github devops-psake sample/chapter8


[iThome第8屆鐵人賽 06]開始建制一個Asp .Net Mvc專案

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

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

這次的建制我們都是focus在.net Framework的部分,或許.net core會有所不同,但是概念是一樣。

(之後下面提到的code都可以從這邊看到內容:github repo,這篇會是tag sample/chapter6)


[iThome第8屆鐵人賽 05]準備建制專案環境的Task

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

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


[iThome第8屆鐵人賽 04]開始了解如何使用psake

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

(之後下面提到的code都可以從這邊看到內容:github repo,這篇會是tag sample/chapter4


[iThome第8屆鐵人賽 03]CI - VS是如何建制(Build) .Net專案

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

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

因此,這篇將會介紹:

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


[iThome第8屆鐵人賽 01]開篇 - 為什麼要寫這個主題

又到了新的一屆鐵人賽,針對這次是否要參賽其實非常的糾結:一方面因為工作的關係,額外的時間越來越少,但是一方面又想把寫日誌的習慣找回來,在這種糾結的心情中,最後,還是想寫戰勝了不想寫。

這已經是第三次參加鐵人賽了,對我來說,每一年的主題都比上一年的更加困難,今年選擇的主題更是我這兩年想做但是一直沒有做的部分,也就是如何在日常生活中把DevOps引進來,並且提升日常工作效率。

同去年一樣,今年很多東西會是邊執行並且邊研究和邊記錄,希望大家能夠在這個系列學習到東西。