.NET Walker

近幾年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或需求，一直到交付到...