.NET Walker

你知道的，有些地方，進去很容易，脫離就有點困難。 我說的不是黑道堂口，也不是邪教異端，我說的是 Azure DevOps organization。 不只一次，我被問過這個問題：『當被加入一個Azure DevOps組織之後，要怎麼離開呀?』 沒錯，你尋遍整個portal，沒有離開的選項。也就是說，倘若該組織的admin不把你移除，你似乎永遠會屬於某個組織，這導致於，每次你登入的時候，左方選單裡面就有一大多你根本已經不會去用的組織站台： 這些站台多還不打緊，它還讓我無法建立新的組織： 這使得我下定決心，要脫離組織的綑綁。 尋找了一會兒，發現，原來還是可以脫離組織的，但這功能不在portal上，而是在 https://aex.dev.azure.com/ 這個頁面： 在這個畫面上會列出你的帳號參與了哪些組織。 原來，在這個畫面，只要展開你不是owner的組織，右下角就會有一個 Leave 聯結按紐，把它給點下去，出現了警告訊息： 但，這就是我要的呀。 點選 Leave 後，徹底脫離組該織的所有的掌控與專案了。

In 2021, the original expectation of the whole world was that life could return to normal through the launch of a vaccine, but this idea was once again interrupted by uncertain factors. Omicron allows the world to face a new wave of challenges, and at the same time, it also makes companies start to think about how to respond if they need to coexist with the virus for a long time. So, in 2022, we’ll have chances of seeing these things happening underneath. More remote collaborative operation modes will appear IT vendors have promoted online conferencing software for many years in the past. In these days of the epidemic, there has been subversive growth. After breaking through this barrier, more technologies and tools for remote cooperation will emerge. besides, 5G and the artificial intelligence will make the future “cooperation” full of imagination. In the past, most remote collaborations were people-to-people collaborations – co-finishing a project, co-authoring an article, co-de...

近幾年Docker/Container技術相當被業界重視，而微軟的 .net 開發技術也適時的支援了容器化的功能。為了實現容器化， .net 開發技術必須支援跨平台，特別是 asp.net ，這也造就了 .net core的誕生。 因此，現在您不管用何種開發工具，也可以產出能運行在Linux環境上的asp.net應用程式，這同時也表示，asp.net理所當然的也可以支援Linux Container了。 Docker file 要讓asp.net專案產出支援Docker的image非常簡單，你可以在建立asp.net專案的時候，勾選『啟用Docker』，『Docker OS』選擇Linux： 或者，你也可以在一開始沒有啟用Docker支援的專案中，點選滑鼠右鍵，選擇加入→Docker支援： Visual Studio會幫你在專案中建立一個類似底下這樣的Docker File: FROM mcr.microsoft.com/dotnet/core/aspnet:3.1-buster-slim AS base WORKDIR /app EXPOSE 80 EXPOSE 443 FROM mcr.microsoft.com/dotnet/core/sdk:3.1-buster AS build WORKDIR /src COPY ["webapp01.csproj", ""] RUN dotnet restore "./webapp01.csproj" COPY . . WORKDIR "/src/." RUN dotnet build "webapp01.csproj" -c Release -o /app/build FROM build AS publish RUN dotnet publish "webapp01.csproj" -c Release -o /app/publish FROM base AS final WORKDIR /app COPY --from=publish /app/publish . ENTRYPOINT ["dotnet", "webapp01.dll...

我們在前面的章節曾經介紹過，軟體重用性提升一個很大的要素就是套件化。時至今日，不管你用哪一種軟體開發語言，大概都離不開各式各樣的套件庫。 因此，我們在前面談到Azure Repos的章節中，曾經約略介紹過如何建立套件，也介紹過利用Azure DevOps的Artifacts功能來建立的私有(Private)套件庫： 你大概已經知道，我們可以將組件(.dll)封裝成具有版號的套件，以便於分享給團隊甚至網際網路上所有開發人員來使用。只是先前，我們封裝好的套件(.unpkg)都是以手動方式上傳到 nuget.org ，我們接著來看看，如何自動化完成這件事情。 設計自動發佈套件的Pipeline 一個自動化建置出NuGet套件並且上傳的CI Pipeline並不難設計，就建立 .net core的套件而言，你可以直接使用 ASP.NET Core的範本來修改即可： 接著將範本中的Publish改為(Pack)： 因為套件本身不是網頁，因此沒必要『Publish』出什麼，倒是需要產生出 .unpkg檔案，因此我們需要執行dotnet的Pack command。 然而光Pack還不夠，你還得上傳到 nuget.org ，這部分則可以透過 NuGet push task(下圖B)來完成： 上圖中的NuGet push task，其實是在運行NuGet的push command(上圖D)，該task會在預設(上圖E)的位置嘗試尋找我們先前透過 Pack Nuget命令所建置出的 .nupkg 檔案，然後將其上傳發送到指定的套件庫。 因此，我們需要進行上傳位置的設定。 第一次連線時你必須點選(上圖F)右方的『+New』按鈕，接著會出現底下畫面： 在出現的畫面中，我們必須輸入ApiKey(上圖C)以便於具有連線到NuGet的權限，後續可以讓Pipeline把套件檔案上傳到Nuget。 一般來說，公開的NuGet套件庫位於: https://api.nuget.org/v3/index.json 如同先前介紹過的，你只需要有Microsoft Account即可登入並且上傳套件。請先用你的Microsoft Account登入nuget.org ： 登入後你會發現右上角的頭像圖示選單中，就有一個API Keys選項，透過該選項，你就可以取得一組...

上面這張圖，是我在講 Azure DevOps 的時候，時常跟學員分享的Pipeline，裡面粗略的談到了CI/CD Pipeline及其前段(版控)與後段(持續監控)所涉及的相關技術，可以讓對於DevOps完全沒概念的學員得以稍微一窺究竟。 但每當我繼續問學員：『你現在知道有這些內容了，那…CI/CD的目的到底是什麼? 實現CI/CD對於企業來說究竟有何好處呢? 』學員突然被問到，有時一下子會無法立刻反應過來。 我繼續說到：『倘若，CI Pipeline的主要目的是為了實現持續整合，而實現持續整合的主要目的則是為了持續交付。那…為何需要頻繁交付呢?』 過去一年，你一定有上網預約疫苗的經驗，如果沒有，你大概也有上網登記五倍券還是某種OO券的經驗，再沒有，你疫情期間總有過上網購物吧。 倘若，你上網登記或購物時，網站突然有問題，或是購物車的金額計算不太正確，你通知了網站營運單位，他們也告知您會立刻著手處理，這時候的你，會希望網站多久可以更新或修復? 一小時? 一天? 還是一兩個月? 同學幾乎都跟我說：『立刻，不然我就換一家網站購物囉~』。 是啊，立刻。 既然我們都這麼要求其他人，那我們自己所建立起來的網站呢? 能不能經得起這樣的要求? 當我們的網站有問題，或是客戶提出新的需求時，我們能夠多快的將新功能或修正交付到用戶手上? 而且你知道的，緊急狀況下，往往兵荒馬亂，即便你知道程式碼在某個地方可能有錯，但這段程式碼最初不是你寫的，你敢立刻改嗎? 你怎麼知道不會改了這邊，就壞了另一邊? 你怎麼知道這個修正會不會引起其他額外的副作用? 有些時候，程式碼明明在你的電腦上是好的，但整合了團隊中其他人開發的程式碼之後，佈署到測試機上，就是無法運行，怎麼回事呢!? 就算開發人員真的把所有問題都在測試機上改好了，是不是還要經過QA的人工測試把關才能交付給客戶呢? 但測試需要時間啊，如何才能實現『立刻』將成品交付給客戶? 上面這些，都是CI/CD想幫助你解決的問題。 持續交付，聽來很容易。也確實，因為技術的進步，現在要快速的把更新後的成品佈署到正式機上讓用戶使用，也許真的也不難。但你有把握在『快速』的同時，還能保有高品質與安全性嗎? 你有勇氣讓開發人員把程式碼修改完之後，透過Pipeline『全自動』的直接上版到正式機上嗎? 從你收到bugs或需求，一直到交付到...

昨天，在 .net conf 2021，明明講的主題是框架設計的延續 - 套件設計，但其中六七個demo當中，大家看起來最有反應和效果的反而是底下這個語音轉文字的CLI Demo。 影片: 這是一個透過CLI呼叫的語音辨識的服務，挺有趣吧，我只是把它變成command line tools, 也就是CLI工具，這個demo只是一個我想做的語音助理的一半，後半段沒demo出來的是一個語音助理的雛型，也就是透過語言來控制電腦。(還需要整合LUIS以及掛上特定 intent 的 actions) 若想要用語音來控制電腦，第一步當然是辨識語音，你可能沒想到過，現在即便 command line, console app也可以辨識語音(Speech to Text)。 拜 azure cognitive 所賜，如今這已經是簡單到不行的技術。主要的程式碼只有底下這幾行: async static Task FromMic(SpeechConfig speechConfig) { using var audioConfig = AudioConfig.FromDefaultMicrophoneInput(); using var recognizer = new SpeechRecognizer(speechConfig, "zh-tw", audioConfig); Console.WriteLine("嗨~ 請透過語音下達指令..."); var result = await recognizer.RecognizeOnceAsync(); Console.WriteLine($"語音命令 = '{result.Text}' "); } 我把整套 CLI tools的source code放 github上了: https://github.com/isdaviddong/demo-listenup-VoiceCommand 當然你得自己換掉 Namespace 與 Azure Cognitive Services 的key。 如果要申請 Azure Cognitive Services 的 語音轉文字服務，可以參考: https://portal.azure.com...

在預設的 Azure DevOps Pipeline範本當中，針對 .net core的專案，你可以透過 dotnet task來運行單元測試，使用的指令是 dotnet test。底下是Yaml code, 這是一個很標準的做法： steps: - task: DotNetCoreCLI@2 displayName: Test inputs: command: test projects: '$(Parameters.TestProjects)' arguments: '--configuration $(BuildConfiguration)' 但使用預設的dotnet rest，並不會產生code coverage報表，雖然我們並沒有想追求很高的unit test code coverage，但出一下報表對我們來說還是很具有參考價值的。 如果你也想要檢視code coverage報表，可以做底下調整。 step 1: 修改 dotnet test task steps: - task: DotNetCoreCLI@2 displayName: Test inputs: command: test projects: '$(Parameters.TestProjects)' arguments: '--configuration $(BuildConfiguration) --collect:"XPlat Code Coverage" -- DataCollectionRunSettings.DataCollectors.DataCollector.Configuration.Format=cobertura' 你會發現在參數的地方，我們加上了 --collect 等敍述，主要是告知 dotnet task運行test的時候，要蒐集相關資訊。 step 2: 增加Publish code coverage results task steps: - task: PublishCodeCoverageResults@1 displayName: 'Publish code coverage...

DevOpsDays 2021的會場，有個活動叫專家面對面好像(具體叫啥我忘了)，主要是讓與會者能夠和現場講師有更多互動。當天分享結束後，主辦單位請我去那坐一下(我當然也從善如流的照做了)，正當我回答完幾位學員的問題，準備離開的時候，有一位年紀比我稍長的先生坐了下來，有條不紊的介紹完自己的團隊與專案後，開口問了幾個問題。 其中，有一個很關鍵，大概是這樣的內容：『如果團隊手上非常多插單的情況，導致每個迭代都無法正常進行，這樣適合 run scrum嗎?』根據多年的經驗，這個問題肯定只是表象，背後一定有著其他沒說出來的狀況。 我想了想，反問他：『你們的迭代設定多長?』 『一周或兩周，每個團隊有點不同』他回答。 我疑惑的問：『所以用戶的需求等不及一周的時間? 非得立刻插單不可?』『因為都是一些非常嚴重bug，不立刻處理不行』他說 『那你們真正該面對的不是插單的問題，而是整個專案已經快失控了，這樣等於每天都在救火啊?』我看著他。 他有點不好意思的說：『的確是這樣的。』 『那我的建議會是…』我認真的回答他道：『你們應該停止任何新功能的開發，先把所有的bugs解決，然後找出系統架構上或開發上的核心問題，到底~是什麼原因導致系統bugs層出不窮? 先著手解決它，別讓團隊陷在持續救火的處境裡…』 如果團隊每天都必須救火，那不管你 run 什麼方法都是對專案沒有幫助的，敏捷或scrum的導入不會立刻改變團隊的體質，如果大家的習慣不改變，團隊面對的困境還是會持續僵在那裏。 『但是，如果不開發新功能，這樣專案就不會有進度了啊?』他似乎有些擔憂這個。 如果你不停止開發新功能，去面對團隊本該處理的核心問題，這樣你看到新功能的進度，也只是個假象，終有一天，層出不窮的bugs會在專案的後期吃掉你所有的進展，最終，你會無法交出任何一個功能給客戶。 『恩，我知道』他面有難色地回答。說完謝謝之後，就皺著眉頭離開了。 我知道他心裡的考量和難處。 回到根本，敏捷其實很簡單–就是務實的面對問題，努力交付出用戶真正可以用的軟體。但，在這世上，總是有很多事情，特別是技術面以外的事情，並非那麼的務實。有時候我們的思慮，可能還包含了人情、績效、政治…等等各種其他方面的考量。這時候，問題就被我們搞複雜了。 就如同我在DevOpsDays中說的，敏捷一直都很簡單，但讓一切複雜的，是人。如果...

在上Azure DevOps課程的時候，學員問了一個很好的問題。 如果我們採用 Feature Branch，那你會走一個底下這樣的團隊合作流程： 上圖中有一個很重要的部分是，在PR之後所觸發的自動化佈署。 也就是，在feature branch分支被commit/push準備合併到主線前，我們會透過PR進行code review和discussion，過程中當然應該要先針對分支進行build才對呀。如果 build fail 了，那或許根本沒啥好討論了，整個PR直接給個comment然後reject掉就得了。 所以，分支(特別是feature branch)在走PR合併回主線前，針對分支的auto build非常重要，但，這要如何實現? 在Azure DevOps中，是透過 branch policy來實現的: 你只需要設定特定分支(例如master)的branch policy，把開關打開，設定任何從只分支建立出的分支(像是feature branch)，PR後都會觸發個定的build pipeline就行了。 如此一來，圖中PR就會自動觸發該分支的build，這樣，我們的repo owner或是reviewer就可以在code review之前，看看build是否成功: 當然，在build pipeline中，我們也可以先做像是 SonarCloud / Checkmarx 之類的程式碼掃描，如此一來，整個團隊的開發協同運作流程，就更加迷人了。 相關課程： 敏捷開發專案管理與Azure DevOps實戰 https://www.studyhost.tw/NewCourses/ALM

#一起看廣告 昨天晚上，做了個夢。 我夢到在駕駛座上睡著了，然後被後座的其他乘客叫醒，乘客急急忙忙地跟我說：『ㄟㄟ，David，你睡著了啦!! 車還在開耶…』 我回答：『對耶，啊…有自動駕駛啦…』 然後我就繼續睡了… 早上起床突然想到，跟老婆說。 她說：『好啦，收到，我知道你有多想買自動駕駛的車了…』 古人說：『日有所思，夜有所夢。』可能真的是因為，這陣子看了好多汽車廣告。 最近看到 Ford 的廣告拍得很好，分別是林依晨的 New Focus (很值得看) 還有先前張鈞甯的 KUGA: (超好看) 後來又補一個: 上面這兩個廣告我都超推，不看你會後悔。但某天，我看著看著，卻讓我回憶起十多年前的這一支廣告。總覺得 Ford 的車怎麼樣我不知道(沒開過)，但廣告總是拍得很有意境： +壓力-身段×堅強÷任性 換算之後，你是否還記得真實的自己? 當初看上面這則廣告時，自己還是個帶著無限衝勁，剛站穩在職場上的少年。 但，這十幾年(也才十幾年)，很多事情都改變了。環境變了，世界也變了。傲氣收斂成淡淡的執著，衝動則被多慮的思緒給撫平了。 年輕人總是想『做自己』(相信我，這並非時下青年的特色，每一個世代都是)。但，到了最近這個年紀，才發現，原來做自己之前，還得先找到自己。很顯然的，年輕時不顧後果地去凸顯自己的任性，並不是做自己。 當你找到並認識自己是誰，明白自己的能力和限制，還能無畏著外界的眼光，放下纏累自己的包袱，不跟他人比較、不被世俗的成功定義，還有勇氣和餘力踏上自己想走的路。持續走下去…這樣，才是做自己。 『做自己』要的不單單只是一股衝勁，而是認真的認識並面對自己的個性和缺點、堅持著持續超越和挑戰自己的毅力。