緊接上篇?TFS在項(xiàng)目中Devops落地進(jìn)程（上）

再接著說TFS相關(guān)之前先插入一個(gè)番外篇，雖然跟TFS關(guān)系不大但跟DevOps關(guān)系很大，覺得有必要在此亂入一下。

番外篇--監(jiān)控之Application Insights

我們之前并沒有任何監(jiān)控類產(chǎn)品（我指的是應(yīng)用程序級(jí)別的），發(fā)生任何異常都是往數(shù)據(jù)庫的表里insert個(gè)錯(cuò)誤日志，all系統(tǒng)共用同一張錯(cuò)誤表。

這其實(shí)意味著我們當(dāng)時(shí)的系統(tǒng)是：系統(tǒng)異常基本不關(guān)注（線上數(shù)據(jù)庫開發(fā)肯定沒法查對(duì)吧），關(guān)注的時(shí)候肯定都出事了，對(duì)自己負(fù)責(zé)的系統(tǒng)的運(yùn)行狀態(tài)基本不了解，什么性能之類東西純粹靠猜。

然后我就希望我們能有辦法獲取到我們系統(tǒng)的各種狀態(tài)，而此時(shí)在VS2015的時(shí)候整合在VS里的application insights引起了我的關(guān)注。

簡要介紹下application insights,是微軟基于azure所推出的一款SAAS性質(zhì)的APM(Application Performance Management,應(yīng)用程序性能管理)服務(wù)，本人不會(huì)詳細(xì)介紹這個(gè)，詳情可參閱官方文檔。

然后也感謝我大學(xué)年代曾經(jīng)當(dāng)過MSP（微軟校園菁英）并透過這個(gè)拿到過Visual Studio Enterprise的訂閱，然后里面附贈(zèng)的每個(gè)月150美元額度的Azure費(fèi)用，讓我有條件可以先試用Application Insights。

然后自己將自己負(fù)責(zé)的站點(diǎn)搭上Insights做了個(gè)小Demo展示了給老大看，然后老大也對(duì)此表示滿意。

(Application Insights的概覽圖)

在后續(xù)的一次PMO會(huì)上我將此拿出來進(jìn)行了演示，也獲得了CTO的認(rèn)可和支持，然后終于可以將Application Insights投入到線上使用（當(dāng)然此時(shí)用的是公司正式的賬號(hào)而不是我那個(gè)150刀每月的測(cè)試號(hào)了）。

但是有Insights投入初期其他小伙伴熱情度并不高，大家還是覺得記數(shù)據(jù)庫挺好的，直到后面發(fā)生了一件事…

事情是這樣的，那是一個(gè)要常規(guī)發(fā)布的夜晚，因?yàn)椴]有數(shù)據(jù)庫相關(guān)的修改，所以DBA已經(jīng)下班了（要加班到夜里發(fā)布，DBA只是正常下班），然后某站點(diǎn)發(fā)布上去的時(shí)候報(bào)錯(cuò)了，然后對(duì)應(yīng)的開發(fā)小伙伴不知道為什么，就知道出異常了。

然后此時(shí)DBA不在，無法查線上數(shù)據(jù)庫，然后就干著急，最后通過在代碼里讓異常本地寫txt臨時(shí)解決了發(fā)布上的問題，但這個(gè)問題完整暴露出記錄數(shù)據(jù)庫的不靠譜：萬一DBA不在呢？畢竟如果沒數(shù)據(jù)庫內(nèi)容的話總把DBA留下來的話其實(shí)也不合理，我們應(yīng)該要從更長遠(yuǎn)和更科學(xué)的方案解決這個(gè)問題。

至此后續(xù)我們所有項(xiàng)目加入Insights的進(jìn)程就加快了，因?yàn)镮nsights里我們可以自主的查看到性能/請(qǐng)求/異常等各種數(shù)據(jù)了。

另外有了Insights后我們開發(fā)自己第一次有了自己的程序運(yùn)行數(shù)據(jù)，有時(shí)候我們也會(huì)針對(duì)Insights里的數(shù)據(jù)做一些對(duì)應(yīng)的優(yōu)化。

如上圖，這是一個(gè)通過城市Id獲取城市名稱的接口，原先調(diào)用量巨大（當(dāng)時(shí)設(shè)置了50%采樣率，所以實(shí)際調(diào)用量要比圖中翻一倍）但是其實(shí)這個(gè)接口返回的內(nèi)容可變性不高，然后讓前端加了緩存后從原來至少10K以上每小時(shí)調(diào)用量下降到現(xiàn)在100多的調(diào)用量，而這些都是因?yàn)槲覀冇辛薎nsights之后才能進(jìn)行的。

所以說：優(yōu)化不能靠猜，我們要用數(shù)據(jù)說話。

而Insights的Analysis功能/智能預(yù)警功能等特性也在實(shí)際中幫我們解決了不少問題。

然后Insights也是可以跟TFS進(jìn)行一定程度的整合的，其中主要包括自動(dòng)發(fā)布的時(shí)候打上注解和在TFS的面板里查看Insights的信息

版本注解，有了這個(gè)我們可以從監(jiān)控系統(tǒng)里知道什么時(shí)候上了預(yù)發(fā)布環(huán)境

可添加在TFS上的widget(新版本的，詳情可參看Application Insights: VSTS dashboard chart widget now available)

然后最近Insights里還有各種Preview的功能，比如新的Preview性能面板里能查看到95線/99線等，新的異常面板里還能給你分析出你異常的共同點(diǎn)之類的，Insights也一直在進(jìn)步著。

在定型監(jiān)控系統(tǒng)的時(shí)候我們?cè)?jīng)議論過聽云和是否自建服務(wù)端（當(dāng)時(shí)確定了監(jiān)控的SDK都是用Insights的，但是糾結(jié)于是否基于ELK自建服務(wù)端）

聽云：

老實(shí)說從默認(rèn)的圖表來說，聽云比Insights的圖表更全面，但聽云缺乏一個(gè)Insights里有的一個(gè)很重要功能，查詢分析Analysis：

在Insights的Analysis里，可以通過一個(gè)長的很像Sql的一種語句，可以快速查詢你想要的任何原始數(shù)據(jù)（精確到每一條）,此語句也能繪制圖表，這個(gè)絕對(duì)是對(duì)程序員Friendly的一個(gè)功能

比方說出了異常，可能從運(yùn)維層面更關(guān)注異常的趨勢(shì)，而開發(fā)層面更關(guān)注的是具體的每一個(gè)異常，和每一個(gè)異常對(duì)應(yīng)的每一個(gè)請(qǐng)求等，另外聽云因?yàn)槭欠?wù)器層面的監(jiān)控?zé)o法在代碼層面埋點(diǎn)，我們Insights里則埋了如果異常的話將錯(cuò)誤請(qǐng)求的Body記錄到Insights的Traces里，這樣就算是Post/Put之類的請(qǐng)求報(bào)錯(cuò)我們也能拿到原始請(qǐng)求報(bào)文。

自建服務(wù)端：

關(guān)于這個(gè)我覺得在我們現(xiàn)在連Redis啊隊(duì)列啊這些更緊急的東西都沒有落實(shí)的情況下在分出人力去搞這個(gè)，就擔(dān)心做出來后就是個(gè)永恒的1.0版本，覺得類似這種東西除非說有專職負(fù)責(zé)這個(gè)的人/團(tuán)隊(duì)不然不應(yīng)該自建，再說那個(gè)時(shí)候我們組已經(jīng)用Insights好一段時(shí)間了（有接近1年了吧）習(xí)慣了上面各種高級(jí)特性，而原始版的ELK則呵呵噠（一個(gè)自個(gè)買的原始毛胚房VS一個(gè)租來的豪華精裝房），當(dāng)然如果有專職人員專門投入到上面基于ELK做定制開發(fā)我相信也肯定能做的跟Insights那樣或者比Insights更好，但是，我們有更多更緊急的事不是么？

不過倒是有一點(diǎn)是因?yàn)橘M(fèi)用問題我們的Insights是使用了采樣率的（就是說并不是收集全部而是部分收集），但是我們希望異常不要被采樣，所以后面可能要基于ELK搞個(gè)Exceptionless來專門記錄異常。

?

另外Insights跟VS的整合也是棒棒噠，比如下面這樣，直接告訴我哪個(gè)方法發(fā)生了異常，直接反映在CodeLens里

?

第4篇--自行管理BuildAgent

原先整個(gè)TFS服務(wù)器的搭建和維護(hù)都在運(yùn)維那邊，那為什么要拿出這個(gè)來說呢？

首先我們現(xiàn)在正處于一個(gè)快速發(fā)展的年代，什么框架啊每月總能冒出幾個(gè)，技術(shù)各種日新月異，雖然絕大多數(shù)企業(yè)本著穩(wěn)定至上的原則不會(huì)說總是用最新，但這不是固步自封，不思進(jìn)取的借口，在一個(gè)“最新”變?yōu)椤狈€(wěn)定“之后總要試著跳出舒適區(qū)步入現(xiàn)代化進(jìn)程吧？

然后我們遇到的第一件事就是.Net版本升級(jí),我們計(jì)劃升級(jí)到.Net 4.6.2（原來是4.0到4.5.1不等），然后因?yàn)樽詣?dòng)打包的原因所以要求Build Agent也要升級(jí)，然后原先運(yùn)維部署配置的TFS是服務(wù)器+Build Agent放在同一個(gè)機(jī)器上的，搭載的是VS2015.

然后除了4.6.2之外的話我們有個(gè)別類庫項(xiàng)目使用上了.Net Core里全新的xproj格式來進(jìn)行多target framework的開發(fā)，這也要求服務(wù)器上要有.Net Core的Sdk。

在另外此時(shí)在討論到代碼質(zhì)量審核，然后我們初定使用Sonarqube，而這個(gè)也要求Build Agent服務(wù)器要有Java的功能。

基于上述原因外加后面我們技術(shù)部某神秘人物毛哥批了一批（2臺(tái)）服務(wù)器（也就一般工作電腦）資源給我，后面還有CTO批了一臺(tái)大服務(wù)器（真·服務(wù)器，當(dāng)時(shí)可是嘻嘻噠的內(nèi)心），然后我開始自己搭建Build Agent。

當(dāng)前我們組自行維護(hù)的4臺(tái)Build Agent，承載了包括持續(xù)集成，自動(dòng)打包，代碼分析，自動(dòng)測(cè)試等一系列任務(wù)

裝上了一堆現(xiàn)在要用或?qū)硐Ｍ胗玫墓δ?#xff0c;滿足當(dāng)前及其可預(yù)見的一段時(shí)間內(nèi)的需求

其實(shí)關(guān)于Build Agent主要覺得這個(gè)必須要能適應(yīng)開發(fā)組的步伐，首先我們.Net 4.5->.Net 4.6.2的時(shí)候，要求Build Agent要支持.Net 4.6.2或以上，之后我們有計(jì)劃要上.Net Core（此時(shí)已經(jīng)有基于.Net Core項(xiàng)目的Dll包了），而且之后.Net Core還有2.0版本（主要是NetStandard 2.0），所以我覺得這個(gè)Build Agent在我們組內(nèi)的話我們能更好適配我們的前進(jìn)步伐。

現(xiàn)在我們的Build Agent里裝的是Vs2017 17.3 + .Net 4.7 + .Net Core 2.0 + Docker 17.03.2-ee + CMake 3.9.1 + Python 3.6.2(x64) + JMeter 3.0 + F# 4.1 + Node.js 8.4(x64) + Java 1.8

估計(jì)小半年內(nèi)基本都能滿足需求。

?

第5篇--自動(dòng)代碼質(zhì)量檢查

接著上篇說，我們有了自己的Build Agent，然后自動(dòng)發(fā)布之類的基礎(chǔ)功能也有了，于是我們就有更高層次的自動(dòng)化追求了。

首先就是自動(dòng)化代碼質(zhì)量檢查，在此先聲明一點(diǎn)：任何自動(dòng)化代碼質(zhì)量檢查工具都不能代替人肉的Code Review，但能減少人肉Code Review的工作量。

然后在選型上我們選了Sonarqube，當(dāng)然你們會(huì)問為什么選Sonarqube，說來慚愧其實(shí)我之前并不了解相關(guān)產(chǎn)品，然后在TFS商店里看到了這貨然后才知道還能自動(dòng)化代碼檢查…然后就去研究這貨，發(fā)覺總體還可以（規(guī)則之類的啊，還有跨平臺(tái)等），在跟我們技術(shù)部神秘人物毛哥上報(bào)下技術(shù)選型獲得認(rèn)證后就拍板開始干。

通過自己手頭有的服務(wù)器資源，搭建了個(gè)Sonarqube服務(wù)器，然后通過TFS的任務(wù)加上去

一個(gè)帶Sonarqube分析的編譯過程，作為C#程序員看上去好像一個(gè)using的結(jié)構(gòu)（開始->釋放)

某項(xiàng)目分析結(jié)果

好，然后代碼分析質(zhì)量有了，大家就能照著上面去“優(yōu)化”代碼了。

慢著，我寫了一段代碼，因?yàn)樗絾栴}我也不知道有沒有咖喱，然后一提交，然后上面就留下了一個(gè)永恒的污點(diǎn)（有歷史記錄的），這樣肯定很不爽，所以后面我們就糾結(jié)有沒辦法能夠讓代碼在進(jìn)入到Sonarqube系統(tǒng)之前先有個(gè)反饋。

然后此時(shí)微軟就發(fā)布了TFS2017，具體參考?TFS2017RTM Release Note

其中它引入了這么一個(gè)功能

在拉取請(qǐng)求的時(shí)候顯示Sonarqube的分析結(jié)果（直接定位到你代碼上），且該分析結(jié)果不記錄到Sonarqube服務(wù)器里

接著慫恿下老大出面讓運(yùn)維那邊幫忙升個(gè)級(jí)。

然后為了配合Sonarqube，那么每個(gè)項(xiàng)目在Pull Request的時(shí)候都要進(jìn)行編譯的過程（編譯了Sonarqube才能分析），因此也順帶加上了阻止合并不能編譯的代碼這個(gè)額外附加項(xiàng)。

同意一次Pull Request需要一個(gè)非本人外的其他人同意且要編譯成功

然后審核人也能看到Sonarqube分析的結(jié)果就不用每行仔細(xì)看也能大概知道個(gè)所以然。

當(dāng)然實(shí)踐過程中，看別人的代碼發(fā)現(xiàn)不少什么超過3重if嵌套啊，類超過1000行啊這些，他們總說由于某些原因?qū)嵲诓缓酶牡?#xff0c;那就只能忍了（你能怎么辦呢，特別是多重if的往往都是各種業(yè)務(wù)條件判斷復(fù)雜，然后自己也沒空深入去看他們的業(yè)務(wù)），但自己項(xiàng)目要求要嚴(yán)格點(diǎn)，要嚴(yán)格控制不能出現(xiàn)任何形式的咖喱。

另外在此吐槽一點(diǎn)：TFS不能直接在Dashboard里瀏覽Sonarqube的結(jié)果，要看Sonarqube結(jié)果還要跳到Soanrqube里去，這不符合All in one的TFS理念啊，就沒人想過弄個(gè)Widget什么的來解決解決這個(gè)問題？

?

第6章--自動(dòng)測(cè)試

自動(dòng)測(cè)試在這里想主要分2塊來說，單元測(cè)試和集成測(cè)試。

首先我覺得對(duì)于這2個(gè)概念盡管有很官方的說明但實(shí)踐中很多人都有自己的理解，我簡單說下我自己對(duì)上述2個(gè)詞的理解和定義

單元測(cè)試：在代碼內(nèi)部進(jìn)行的不依賴外部環(huán)境（網(wǎng)絡(luò)/數(shù)據(jù)庫等）進(jìn)行的對(duì)某個(gè)方法級(jí)的測(cè)試，特點(diǎn)是只能測(cè)試一小塊邏輯,能模擬數(shù)據(jù)且運(yùn)行較快（毫秒級(jí)），代碼執(zhí)行結(jié)果可預(yù)測(cè)。

集成測(cè)試：可能是代碼也可能是腳本依賴外部環(huán)境（網(wǎng)絡(luò)/數(shù)據(jù)庫等）進(jìn)行的針對(duì)某個(gè)流程上的測(cè)試，特點(diǎn)是要造數(shù)據(jù)且運(yùn)行較慢（至少是秒級(jí)），代碼執(zhí)行結(jié)果絕大多數(shù)情況下可預(yù)測(cè)（受外部因素影響不能100%可控）。

單元測(cè)試：

要讓代碼可以被單元測(cè)試，首先代碼先要是可測(cè)試的，要如何做到代碼可測(cè)試呢？答案很簡單，隨便街上抓一個(gè)偽計(jì)算機(jī)專業(yè)的都能給出你正確答案：解耦。

但是你要真的落實(shí)“解耦”到你的代碼里，又往往是一個(gè)異常艱巨的任務(wù)（Talk is cheat, show me the code)。

首先在我自己負(fù)責(zé)的項(xiàng)目里，完全使用依賴注入的形式重構(gòu)了，另外抽象出了各種各樣的接口，理論上要做到所有的”Service“都是可以”被替換”的。

嚴(yán)格限制對(duì)static和new這2個(gè)關(guān)鍵字的使用（絕大多數(shù)情況下static或者new都意味著不可測(cè)試，當(dāng)然static一個(gè)數(shù)據(jù)無關(guān)的方法比如Math.Min之類的或者new一個(gè)純數(shù)據(jù)類這些例外）

在自己一番折騰下，現(xiàn)在自己負(fù)責(zé)的項(xiàng)目單元測(cè)試覆蓋率70%+，也算是一個(gè)自己比較滿意的數(shù)字了（這個(gè)是Resharper收集的，它將單元測(cè)試項(xiàng)目本身也包含進(jìn)去了的）

在單元測(cè)試的加持下，自己想重構(gòu)代碼什么的都能放開手去重構(gòu)，有沒有影響老邏輯？測(cè)試跑一下就知道了。

而加新邏輯的時(shí)候也能知道會(huì)對(duì)原有流程造成怎么樣的影響。

總之有單元測(cè)試后，你會(huì)對(duì)你的代碼更加倍有信心。關(guān)于單元測(cè)試看看日后是否專門開一篇文章來說說，里面也有大學(xué)問。

上面說了那么多單元測(cè)試，那么它跟TFS有啥關(guān)系呢？測(cè)試寫完了是吧？你怎么能確保它一定是有在跑呢？這時(shí)就可以將單元測(cè)試的運(yùn)行整合在自動(dòng)編譯的流程里

整合到編譯流程里的單元測(cè)試，每次跑完后會(huì)報(bào)告結(jié)果，如果單元測(cè)試失敗那么會(huì)阻止pull request

在TFS主頁的Dashboard里展示單元測(cè)試結(jié)果

集成測(cè)試

我們的集成測(cè)試現(xiàn)在主要是QA那邊負(fù)責(zé)，QA那邊有基于Jmeter來進(jìn)行的測(cè)試，具體細(xì)節(jié)因?yàn)椴皇俏邑?fù)責(zé)所以我不是特別清楚，但是在Build Agent里裝好Jmeter后（QA配置好了各種他們要的插件的版本）然后在自動(dòng)發(fā)布的時(shí)候運(yùn)行下就好了

運(yùn)行QA他們指定的Jmeter，先從一個(gè)位置拷貝配置文件過來然后運(yùn)行命令行，沒錯(cuò)，從TFS角度去理解的話它只是去執(zhí)行個(gè)命令行而已

不過當(dāng)前QA他們弄的Jmeter是運(yùn)行后發(fā)一個(gè)結(jié)果郵件，如果能夠?qū)meter的測(cè)試結(jié)果轉(zhuǎn)變?yōu)門FS可接收的某種測(cè)試結(jié)果格式（什么JUnit或者Xunit之類的測(cè)試結(jié)果）展示到TFS上那就更好了（如果有會(huì)的人請(qǐng)賜教）

在集成測(cè)試方面我自己也有一套基于代碼的（當(dāng)然現(xiàn)在主流都是基于腳本了）

基于Specflow+xunit的方式我自己做了幾個(gè)我旗下項(xiàng)目主流程的測(cè)試用例（就是那種一出問題QA就郵件出來：”測(cè)試環(huán)境掛拉“的那種）

基于Specflow的BDD形式的描述文檔，盡可能弄的貼近業(yè)務(wù)層面

描述文檔背后對(duì)應(yīng)的是若干代碼

目前我自己這套集成測(cè)試僅放在Demo環(huán)境（第一個(gè)測(cè)試環(huán)境）使用，主要是一旦發(fā)覺個(gè)風(fēng)吹草動(dòng)，立馬還原代碼…(逃…

?

關(guān)于集成測(cè)試按道理此處應(yīng)有以Selenium為代表的UI自動(dòng)化測(cè)試，不過我自己主要負(fù)責(zé)的是接口，然后讓折騰UI的那位同事目前也只是處于演示級(jí)階段還沒正式投入使用，此處就不獻(xiàn)丑了。

當(dāng)然TFS上還有管理手工測(cè)試等各種功能，不過由于QA組是基于Jira來管理任務(wù)所以并沒使用。

?

第7章--引入NetCore的打包

盡管我們當(dāng)前在經(jīng)過一番折騰后全組項(xiàng)目目前已經(jīng)統(tǒng)一到.Net 4.6.2，但短時(shí)間內(nèi)也不會(huì)用上NetCore，但背后一直為了NetCore的遷移在默默準(zhǔn)備著。

主要是考慮到在NetCore 2.0后出了個(gè)NetStandard2.0，它跟NetCore 2.0以及.Net Framework 4.6.1是兼容的。

那么我們現(xiàn)在項(xiàng)目代碼的目標(biāo)都是兼容Netstandard2.0（底層類庫)，但之后真要遷移的時(shí)候就改個(gè)TargetFramework以及表現(xiàn)層稍微改下就好了（嗯，很豐滿的理想）。

說這篇呢主要是分享一個(gè)，我們現(xiàn)在TFS是2017Update2，在這個(gè)版本下你用常規(guī)方法是無法引用任何Netstandard2.0的包的（不信你們?cè)囋?#xff09;

其本質(zhì)是因?yàn)門FS2017Update2自帶的Nuget還原工具是4.0版，而4.0是不支持NetStandard2.0，要4.3才可以，那難道我們?cè)诂F(xiàn)有的TFS下（2018又沒Release）就拿NetStandard沒轍了？

然后就找到了這篇文章Using the latest NuGet in your build

在這篇文章指引下，將它?那堆Powershell腳本?粘貼上去執(zhí)行,下面參數(shù)寫個(gè)4.3.0

然后使用自定義的nuget

然后就迎來了勝利的曙光

?

第8章--我們基于TFS的小折騰

任務(wù)管理

雖然我司一直是基于Jira做任務(wù)管理的，不過因?yàn)镴ira并不能直接跟TFS上的代碼進(jìn)行關(guān)聯(lián)，所以我私自上是喜歡在TFS里建對(duì)應(yīng)任務(wù)然后關(guān)聯(lián)上去

還能跟代碼里結(jié)合起來

在TFS里也能做可視化的關(guān)聯(lián)查詢

自動(dòng)備份分支

這是最近折騰出來的小玩意

在Release里加上這個(gè)步驟（這是個(gè)插件提供的，插件詳情請(qǐng)點(diǎn)此處）

然后在執(zhí)行到對(duì)應(yīng)發(fā)布步驟的時(shí)候就會(huì)自動(dòng)將當(dāng)前發(fā)布的代碼拉一個(gè)分支出來，全自動(dòng)的喲。

?

第9章—VNext

上面的大概就是我們現(xiàn)在折騰TFS的成果，但我們的道路遠(yuǎn)沒結(jié)束，或者說，現(xiàn)在又處在某種程度上的開始。

首先，Docker這個(gè)大趨勢(shì)肯定之后或多或少都要涉足進(jìn)去的（不過覺得先將諸如服務(wù)發(fā)現(xiàn)之類的前置條件先搞定在做這個(gè)）

還有撇了下隔壁TFS2018的Release Note,這回引入了Wiki功能，回頭可能可以直接在TFS上直接寫上各種知識(shí)庫文章了

還有想整個(gè)OWASP ZAP然后跟TFS流程整合下來個(gè)自動(dòng)滲透測(cè)試分析什么的，讓我們自動(dòng)化更上一層樓(if有空弄的話)。

大概就是扯那么多了。

原文地址：http://www.cnblogs.com/leolaw/p/7847062.html

---

.NET社區(qū)新聞，深度好文，歡迎訪問公眾號(hào)文章匯總 http://www.csharpkit.com

總結(jié)

以上是生活随笔為你收集整理的TFS在项目中DevOps落地进程（下）的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。