.NET Walker

在開始使用VSTS管理你的專案之前，你需要知道一個概念。首先VSTS基本上可以視為TFS(Team Foundation Server)的雲端版本，最遠古的時代，微軟是以TFS作為程式碼版控與軟體生命週期管理(ALM)的工具。 隨著雲端SaaS服務的盛行，TFS被改成了雲端版本，過去的名稱曾經是VSO(Visual Studio Online)，後來改名為VSTS(Visual Studio Team Services)。 因此，一個VSTS站台，其實可以視為一台TFS伺服器，因此，一個VSTS站台上，你可以建立與管理多個軟體專案，以往TFS的概念是以Collection為單位，而Collection底下再建立多個Project(這裡指的Project是Team Project，也就是一整個項目專案，而非Visual Studio裡面的某一個Project)。 好，所以重點在於… 你待會建立的VSTS站台，是一個雲端服務，你將會把所有的程式碼版控、工作項目(WorkItems)、Bugs清單…等資訊存放在微軟的雲端。 你建立的一個VSTS站台，上面可以建立無數多個專案，每一個專案當中可以有一個或多個Project Solutions(.sln)。 權限的控管是透過Microsoft Account，也就是過去你熟悉的Hotmail/Outlook帳號。 好，知道基本概念之後，我們就來建立第一個Team Project Site。 首先，請進入 https://www.visualstudio.com/ 網站，接著點選最下方的VSTS(Get Started for free): 接著，你應當會被導引到Microsoft Account登入畫面，登入完成後，會看到底下畫面，這邊就是讓您建立VSTS Team Site: 還記得前面提到過的? 一個Team Site可以有多個專案，因此，原則上一家公司或是一個團隊，其實只需要一個Team Site即可，毋須人人建立一個，當你建立好一個Team Site之後、開好專案之後，再把團隊成員加入即可。 上圖中(1)的位置就是讓您選擇您的Team Site的網址，形式是: https://xxx.visualstudio.com (您可以替換掉前面的xxx成為你公司或團隊名稱) (2)的部分可...

去年(2016)關於DevOps的討論很多，但內容大多相對抽象，對於從來沒有接觸過軟體開發生命週期管理(ALM)的技術人員來說，不是很容易掌握DevOps的精神。 不過，隨著工具的成熟以及敏捷開發概念的盛行，我們越來越能夠看到DdevOps在各行各業的具體實例與應用。同時，不管是專案或軟體產品，在各類的軟體開發的情境中，ALM/DevOps/Agile幾乎已經是近代軟體開發方式與專案管理的主流。 過去這幾年筆者有幸參與各種不同類型的開發團隊，包含軟體產品開發、也有客製化專案軟體開發，同時偶而也協助企業導入ALM/DevOps/Scrum。因此，這一系列的文章中，如果可以，我希望能夠把我們這幾年面對軟體開發方法，以及使用ALM/DevOps/Agile的一些經驗，有條理一點的整理出來，如果你有興趣，不妨嘗試慢慢的看看，如果實在已經不習慣看長篇文章，也可以挑有興趣的重點來讀。 我先定義一下我們的範圍: 採用的開發技術包含.NET傳統桌面應用程式和網站、iOS和Android開發，使用的DevOps/ALM工具主要是VSTS/TFS(版控包含Git和TFVC)，從需求、設計、開發、測試、CI、CD、線上監控、客戶反饋…大致上都有涉及。 開發團隊包含設計人員(Designer)、前端開發人員、後端開發人員，當然還有PM(PO)、客戶服務(或Sales) 底下是系列文: the DevOps journey (0) - 敏捷開發真和每個開發人員有關? the DevOps journey (1) - 敏捷開發不相信時程預測? the DevOps journey (2) - 如果時程難預估，不如追求透明度… the DevOps journey (3) - 『透明度』與『自動化』… the DevOps journey (4) - 建立VSTS站台與專案(2017年Q1版) the DevOps journey (5) - 在VSTS站台與專案中添加成員 the DevOps journey (6) - 安排與設定專案的迭代 the DevOps journey (7) – 你的source code還沒上版控嗎? the DevOps journey (8) – 使用TFVC程式碼版控 the DevOps journ...

對我來說，從傳統Waterfall專案管理方式移轉到敏捷開發，兩個最主要的關鍵就是『透明度』與『自動化』，我們前面談過了 透明度 ，這一篇我要聊聊自動化。 我在課堂上曾說，如果你不確定要怎麼改善你的團隊，那設法提高整個專案(各項事情)的透明度，以及讓開發流程盡可能的自動化，幾乎可以確定對專案成果將帶來顯著的正面影響。 為何我們該在意『自動化』 有幾個顯而易見的理由: 回應真實世界所需的速度        面對瞬息萬變的市場，你幾乎不可能像過去一樣，累積所有的bugs每三個月或半年固定上版更新一次。如今，所有已知的bugs，在一周內更新完畢應該算是最差的狀況了。對一些線上服務或是網站，如果是跟交易金額有關的bugs，沒有人會接受已知的bugs被放任不管。        如今在技術上，我們絕對可以在程式設計師撰寫完程式碼(不管是修復bugs或是增加新功能)之後，自動進行伺服器端建置，建置完成後隨即進行非人工的自動化測試(用以確保這個更新不會改壞了其他原本是好的的功能)，如果自動化測試一切正常，則自動上版到測試機或是正式機。整個過程在技術上可以完全自動，並且在從開發人員Check-in code之後一小時內自動完成。 強迫品質提升        為了讓上述的自動化可以實現，你必須建置自動測試流程，把過去系統從開發到上版之間，所有原先倚賴人力進行的流程，改為由電腦自動進行。在這個調整的過程當中，你的專案品質自然而然會被迫自動提升。         因為你過去沒有自動化測試把關、過去沒有伺服器端自動建置、過去沒有上線後的錯誤警示…改為自動化之後這些全都要實現，如此一來，你的專案品質自然和過去以往不同檔次，將會有顯著的改善。 減少人為錯誤以及倚靠人力的SOP        過去，在一個沒有自動化的開發流程當中，單一程式設計師把改過的程式碼在自己的電腦上撰寫完成，經過自己初步的測試，他就認為這段程式碼 寫完了 。然而真的是嗎?    ...

前面 說了，在近代專案管理當中，大家已經慢慢能夠理解，死板的去stick to the plan，追求計畫導向的專案管理，在外在環境瞬息萬變的今天，這恐怕是不可行的。 但是，如果我們不去追求計畫實施(implementation)的準確度，不去要求執行計畫的每一個步驟一如開始的計畫一般，那我們該用什麼標準去定義何謂一個『好的軟體專案』呢? 對企業來說，如果PM不是依照著既定計畫、時程把成果交出來，那到底什麼可以被叫做『執行了一個好專案』? 在DevOps課堂中，對於這個問題，我的回答是: 我們與其去要求專案100%按照計畫進行，不如追求軟體專案的高「透明度」、以及開發流程與維運的「自動化」。 有注意到這一篇的標題嗎? 請把它記起來… 如果時程難預估，不如追求透明度 什麼是透明度? 底下有幾個問題…不管你是PM、Team Leader、還是專案團隊的成員，你都應該要自問自答一下… 你知道每位開發人員 今天 正在開發哪些功能項目嗎? 你能知道最近一次Check-in上去的Code，是改了哪些程式碼嗎? 這個修改是因為哪一項需求或Bugs呢?  專案的程式碼Check-in是否有觸發Build? Build是否成功?   CI Build的過程中執行的Unit Test是否都有通過? (還是你根本沒建立Unit Test? Check-in還不會觸發Unit Test?) 這個迭代每一個開發人員手上的工項(WorkItem)是否都與MVP(或潛在可交付產品增量)有關? 整體需求目前完成的比例是多少? 已經有多少完成的 item通過測試? 客戶實際驗收過的Item又有多少呢? 到今天為止，你還有多少已知的Bug尚未解決? 這個Sprint要達成的目標為何? 要交付出哪些成果(潛在可交付產品增量)? 當前進行的Sprint是否有任何風險? (導致無法交付出成果?) 已經上線的系統每天有多少人登入? 每天發生幾個Exception? 只要你確實參與在團隊當中，你自己一定很清楚，上面這些問題你能夠回答出來的比例有多少… 別急，我們再來看看幾張圖表: 上面這張圖表呈現出了專案中所有的需求數總共有多少、有多少比例的工作項目正在開發中、有多少需求已經開發完成等待測試、還有客戶已經驗收過(認定完成)的Item有多少。 上...

需求很簡單，我們希望在VSTS的程式碼Code Check In(Code pushed)、Build Success/Fail、或是Work item發生了改變時，透過Line發送通知給特定人員(專案成員、PM…etc.) 會有這個需求很單純，我們希望通知(notification)更加即時，每當任何團隊成員簽入程式碼，或伺服器端的建置(Build)完成有結果之後，相關人員都能夠立即得到通知。過去，我們是用email，隨著各種IM肆無忌憚的入侵我們的生活，現在用推送訊息來通知也是很合理的… 在台灣，你不可能不用Line，幾乎沒有人能跟朋友說自己沒有Line帳號，因此，在VSTS CI (Continuous Integration)當中整入Line通知也是理所當然的。 怎麼做呢? 首先你可以在VSTS的Team Project的管理畫面中，找到Service Hooks，這是一個好用的功能，他可以幫你在該專案特定事件發生時，連結到外部系統並觸發某個動作： 如果你按下上圖的新增鈕，會發現其實已經很多外部系統可以連結了，例如大家很熟悉的Slack、Trello…，很不幸的，我們要發訊息的Line不在裡面: 但不要緊，你會發現我們可以透過Web Hook觸發一個http post，我們只要在該http post裡面來發送Line訊息即可。因此，我們在上圖中的畫面選擇Web Hook，接著按下Next，會出現下圖中的畫面，在該畫面上你可以選定Trigger，也就是，當哪一個事件發生時，要觸發http post來發送通知: 你會看到，選項中有Code Checked in(支援git版控的專案則會出現code pushed)，以及Build completed、WorkItem Created/Updated/Deleted…等觸發事件，請選擇你要的。 然後按下Next，接下來出現的Action畫面，你只需要輸入 URL即可，也就是您選定的事件發生時，要以Http post通知哪一個URL? 你可以自行設計一個可接受http post的WebAPI，並在其中發送Line訊息。如果你還不知道該怎麼設計，我們特別幫你做了一個，讓你可以嘗嘗鮮玩一玩。(其實是我們團隊自己要用的啦…) 請先保留上面這個畫面，別關閉。然後開啟另一個瀏覽器，輸入底下網址: htt...

這一篇，我們來討論敏捷開發中怎麼看待時程預估，以及迭代開發的重要性… 到底專案時程能不能預測? 這是一個常常困擾初踏入敏捷開發領域的新手的問題。 你一定聽到過有人說(甚至，其實 上一篇 推薦的Martin Fowler的文章中也提到過)，敏捷開發不太相信可以進行準確的時程預測，我特別用『預測』這個字，而非預估。中文很有意思，這兩個字很接近，但有那麼一點點的不同。 前面 提到過，既然真實世界裡面的 需求根本不可能固定 ，開發人員的素質(每個人每天的產出)也不太可能統一，那我們幾乎已經宣告無法掌握軟體開發專案中，最重要的兩個變因，那這樣怎麼可能精準的預測出開發時程呢? Martin Fowler在早期的文章中，幾乎是直接告訴你，預測是不可能的。 但這件事情非常弔詭，大概所有開發人員都明白，在需求不確定的狀況下，要精準的預測專案時程、計算出人天數，是幾近不可能的事情。但 好笑 有趣的地方就在於，幾乎所有的軟體專案的業務或PM，都會要求你在專案起始前，在一切模糊的前提下，估出人天數以便於 報價 。 壓在合約裡面的驗收日期和報價耶!? 難到不需要更詳細的資訊以便於精細計算嗎? 這是繼 上一篇 提到的軟體開發迷思之後，另一個超級經典、行之有年、卻嚴重違反常識/常理的軟體開發迷思。同樣的問題又來了，難道從來沒有人覺得哪裡怪怪的嗎? 我相信有，但你會碰到各種壓力，告訴你整個業界都是這樣幹的，你區區一個程式設計師想改變這個慣例? 不可能。 因此，開發人員只能習慣性的在時程預估裡面保留一些buffer，業務/PM報價時再加一些Buffer，然後客戶的採購砍一些作為折扣，done，成交。後面就看彼此的運氣了… 不能預估，怎麼辦? 這篇文章一開始的 那張圖 很貼切，它描繪出了理想狀況與真實世界之間的差異， 上一篇 說過，兩個軟體專案的需求不可能完全一樣，因為 完全一樣 你就根本不需要新的專案，買個套裝軟體或直接copy一份即可。因此，我們知道每一個軟體專案都是新的開始，既然是新的開始， 沒做過的事情要預估時間，這本來就是一種賭博 。 這也是軟體開發和工程專案差異很大的地方，傳統的工程專案施工較容易預估人天，因為施工方法固定，需求固定，常常只是在可以控制變因的狀況下，重新做一次而已，但軟體開發不是，每一個專案都是一場新的冒險。 我常開玩笑的跟業務說，你真要我這樣報...

#不想看廢話，直接按這裡跳到重點 這年頭大多數人已經沒有耐心，已經很難看完一整篇長篇大論，因為這樣，這幾年我們寫blog的時候，幾乎都零零碎碎，這使得許多學員面對知識的掌握，也變得片片斷斷。 如果可以，我希望能夠把我們這幾年面對軟體開發方法，以及ALM/DevOps的一些經驗，有條理一點的整理出來，如果你有興趣，不妨嘗試慢慢的看看，如果實在已經不習慣看長篇文章，也可以挑有興趣的重點來讀。 開始一段新的旅程 這一系列的標題中有個字眼『journey』，第一次看到這個字…是在一場研討會，我忘了是TechEd還是Build，印象中研討會的主題是Metro Style App(現在應該不多人還記得這個名字了吧?)，主講人用journey這個字眼來描述學習一種技術的過程，我覺得真TxD的太貼切了… 不知道你有沒有發現，最近五年，軟體開發的潮流根本就是一場journey，而且非常像是我最愛的影集Star Trek Voyager中的旅程。你該怎麼形容這段旅程呢? 圖乎其來? 充滿意外? 不僅如此，大夥摸著石頭過河…似乎根本沒人能告訴你往哪個方向才是對的，你也不知道怎麼走才會到終點…這差不多就是這部影集當中的旅程。 若用來描述最近五年軟體開發技術的發展，根本是整個貼切到不行，而且從Web、前端、行動裝置、開發方法、框架…幾乎都逃不過這場journey魔咒，所有的技術都是 在途(on the road) ，一點都沒有發展成熟的跡象… 當然，如果旅程總是只為了看到終點倒也世俗了些，旅程的過程中還是有很多意外的小驚喜，以及足以令人回味的點滴，不管是你早已遺忘的Metro Style Application，或是充斥各種消耗型框架的所謂前端開發技術，又或者是我們要討論的這個主題 – ALM/DevOps。 關於開發方法的重要性 身為一個以寫程式起家的開發人員，就一個軟體開發人員的生命週期來看，我算是到了很老的時候，才願意承認軟體專案/產品的開發過程中，最重要的可能不是開發技術，而是開發方法。 技術能力的強度，是進入軟體(專案/產品)開發領域的入場券，它就是一塊敲門磚，技術能力的強度，決定了你敲門的力道。然而一但當門打開，你開始了一個專案，進入了一個團隊，參與了一個產品的研發，技術能力對成果的影響力，可能就開始慢慢式微了。請注意， 個人技術能力可能會影響開發團隊產出的...

這一篇介紹 Bootstrap File Input 這個套件，之所以會被歸類到asp.net Web開發框架系列，是因為整個套件和我們採用asp.net走SPA架構(不管是用WebForms或WebAPI)都非常的速配。 檔案上傳範例 首先我們有一個範例位於 Github ，如果你想要測試，下載這個範例後，基本上已經擁有所有你需要的檔案。請使用Visual Studio運行index.html這個檔案(對，沒錯，是pure html5)，執行起來的畫面像是底下這樣: 這個套件精彩的地方是上傳預覽畫面，你會看到上圖中，它除了支援中文、多檔上傳、非同步上傳，還支援圖片預覽、Mp3檔案甚至可以撥放，會不會太誇張了點? 是的，人家就是支援…更不用說UI的部分很有誠意的原生支援正體中文(包含zh-TW的多國語言js)這也是我們使用此套件的原因之一。 如何使用 整個套件的使用可以完全採用AJAX方式(當然也支援傳統的submit/postback)，搭配我們的SPA架構非常之合拍，也因此，你在運行該範例的時候，會發現只需要執行index.html即可(當然伺服器端接收檔案的部分還是需要Server Code，這我們後面介紹ReceieveFile.aspx的時候再說明)。 如果你看index.html，會發現程式碼如下: 我們先看55行的部分，這是定義一個Input標記，其中的multiple意味著支援多檔上傳，data-show-preview="true"則是支援顯示預覽視窗。當然這些設定都可以在後面透過js來更動。 而66行javaScript所呼叫到32行的setupFileUploadBox()，就是進行相關的設定，其中language: 'zh-TW' 指定了多語UI採用中文(請留意這也是我們在19行引用了locales/zh-TW.js的原因)，而後面幾個參數應該不需要太多解釋，showUpload是顯示上傳按鈕，uploadAsync說明了採用非同步上傳，maxFileCount指定了檔案上傳上限。 比較重要的是uploadUrl，這個參數指定了非同步檔案上傳的接收位置，由於這個範例採用WebForms，因此我們指定ReceieveFile.aspx，這部分我們待會後面介紹。(我覺得熟悉WebAPI的開發人...

先說個幾天前發生的小故事， 最底下 是整理好的年度文章摘要。 可能很多年輕人已經開始不知道，每年的農曆十二月，被稱作臘月。而每逢臘月，則不免讓我聯想到 俠客行 裡面的『賞善罰惡臘八粥』(如果對這主題有興趣，為了不破壞你的閱讀樂趣，請自行參閱 金庸 的 俠客行 )，我猜這個世代大多數的人，應該完全沒有喝過什麼臘八粥，估計對 李白 的 俠客行 ，可能也陌生的很。 回首2016丙申年，發生了不少事。 因此，在年底不免想找找久未聯繫的三五好友，大家聚聚。 由於大夥都是資訊領域的技術同好，彼此也都在業界耕耘多年(都老了?)，但聊起過去種種，卻彷彿就像昨天才發生的事情。然而事實上，這幾年業界幾乎所有的技術都換了一輪，火紅的話題也都翻過了好幾遍。相較之下，我們幾個老朋友們聊到的技術也好、故事也罷，即便還稱不上是歷史，肯定也都已經是往事了。 席間，朋友說到：『技術更迭好像已經是這世代資訊人員的宿命，金庸的俠客行，是1965年出版的，至今已經流傳超過50年，而李白的俠客行，則是1200年前的作品，1200年耶! 這是什麼時間概念? 古人說的『立功、立言、立德』，稱為三不朽，這年代哪還有什麼可以不朽，昨天剛炒熱的技術今天就過時了，更別說寫過的書，才沒幾年就得淘汰，而且越來越快…』另一位朋友笑著說：『你們出的書還可以活個幾年，要絕版了圖書館不小心還能找到，好歹一時也能出個名，像我手上開發出的系統，設計過的架構，估計只要我離職，立馬就會被改的面目全非，要不然就是被直接換掉，根本是屍骨無存』。 這讓我想到 俠客行 中的一段：『 縱死俠骨香，不慚世上英。誰能書閣下，白首太玄經。 』 時代真的很不同了， 如今技術變化太快，潮起潮落可能轉眼間。技術人員手上做的這一切，早晚終究都會過去，也不一定會有人紀念… 不過，不管如何，明天太陽依舊會升起，過去的又何必留戀? 每天都是新的，能夠專注在『現在』，才是幸福的事。 我跟朋友們說，我最近第二次看Spencer『禮物』一書的心得：『還記得你人生當中最快樂的一段時間嗎? 那段時間，往往不是我們過的最舒適的時候，也並非是擁有最多掌聲、財富...的時候。 大多數人記憶中最快樂的時光，常常是我們專注在某件事物上、專注在當下的那一段時刻。像是...小時候在公園裡和同伴玩耍不肯回家，深夜時獨自一人寫程式始終不想熄燈，站在講台上底下的人狂舉牌子告訴你超時...

LineBot傳送訊息的形式，除了單純的文字、貼圖、圖片之外，還有一個比較特別的形式，稱之為 Template Message ，這種形式的訊息本質上是一個選單，長得像是底下這樣: 上面這個是三種Template Message中的一種形式，稱為Buttons Template Message，另外兩種形式是Confirm Template Message(下圖左)與Carousel Template Message(下圖右): Confirm Template Message好理解，基本上它就是一個確認(confirm)對話框，可以讓用戶選擇Yes/No之類的回答。而Carousel Template Message其實就是多個Buttons Template Message，橫著擺可以左右scroll。 我們先從Buttons Template Message開始看起。 關於Buttons Template Message 我們剛才說過，Buttons Template Message這種形式的訊息本質上是一個選單，包含著一張圖片(下圖1)、一個標題(下圖2)、以及一些文字(下圖3)，並且可以設置1-4個選項(下圖4-6，範例中我們只設置了3個): 當你的Bot送出這個訊息給用戶，用戶可以點選底下的選項(上圖4-6的文字)，這些選項被稱為Action，這Action也有三種不同的類型，分別是: MessageAction : 幫用戶說一段指定的文字訊息 UriAction : 直接在Line裡面開啟指定的網頁 PostbackAction : 觸發一個可以你的WebHook收到參數的postback 其中UriAction最容易理解，用戶點選該Action，Line就會直接開啟某個網頁。 而MessageAction可以用來幹嘛? 它可以讓你幫用戶說特定的話，實務上應用時，你可以透過這個機制先設計好一些固定的指令，讓WebHook看到這個指令就能進行相對應的工作(其功能等同於用戶在對話框中說了這個指令)。 而postback則是不出現任何訊息，直接把特定參數傳給WebHook，WebHook就可以進行特定工作。 讓LineBot發送Buttons Template Message 我們看底下這段程式碼，它的功能就是讓LineBot...