發表文章

目前顯示的是 1月, 2022的文章

Azure DevOps In Action - 設計支援Docker/Container的Pipeline

圖片
近幾年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 DevOps in Action - 在CI Pipeline中發佈NuGet套件

圖片
我們在前面的章節曾經介紹過,軟體重用性提升一個很大的要素就是套件化。時至今日,不管你用哪一種軟體開發語言,大概都離不開各式各樣的套件庫。 因此,我們在前面談到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或需求,一直到交付到