跳到主要內容

發表文章

目前顯示的是 11月, 2019的文章

如何從Azure DevOps Pipeline寄信給指定對象 - Send email notification in an Azure DevOps pipeline

前言 當Pipeline要結束的時候, 通常大家都會希望系統可以自動寄信去通知相關人員, "程式已經Build好了"或是"程式已經上線了"等等 網路上可以找到的方法一般都是用Send Mail的Task去作這件事 這些方法都要設定SMTP, 而我自己試的結果是一直卡在權限以及安全性的問題使的Gmail總是拒絕我的請求 後來發現有個更簡單的方法, 就算不懂SMTP也可以的設定, 也可以做到相同的事情 就是使用Azure上的SendGrid來幫我們寄信 設定步驟如下 Step 1. 建立SendGrid 首先需要在Azure 建立一個SendGrid的資源 填入帳號密碼, 然後選擇付費方式, 基本方案是不用錢的 Step 2. 取得API Key 資源配置完成之後, 就可以點進去到以下的頁面 選擇Manage進入管理頁面後可以在Settings下方找到API Keys, 我們可以在這邊建立API Key然後再把API Key記下來 Step 3. 設定Pipeline 回到Azure DevOps頁面去設定Pipeline 在右邊的搜尋欄上敲"SendGrid" 就可以找到相關的Task並安裝, 安裝完之後就可以把他加進Pipeline 接下來就填一下API Key, 寄件對象, 內容之後就差不多了 點選上方存檔然後開始跑Pipeline

[簡易教學] 如何使用Azure Pipeline 建立CICD管線自動編譯程式碼以及部屬至Azure APP Service

前言 最近一兩年微軟開始大力的推廣自家的DevOps工具, 可以感覺的出他們很想要搶下這塊市場, 這對開發者來說其實是件好事情, 表示我們的選擇可以更多元了, 不需要再侷限於Gitlab, Jenkins 等等 Aure Pipeline 用起來的感覺是蠻好上手的, 兩三下就能將.Net程式編譯打包然後部屬到Azure的雲上跑 以前用Gitlab作CI/CD時, 比較麻煩的是如果要Build .Net Framework的程式, 就需要特別自架runner跑在windows的機器上當作build machine, 而這台build machine還需要設定跟安裝某些套件才能讓整個自動化的流程運作起來, 光弄這些code 都不用寫了 TT 那這也是我們團隊開始接觸Azure DevOps的原因, 以下就簡單的帶各位了解一下怎麼在Azure DevOps 上建立Pipeline跑CI/CD的流程 Step 1. 建立組織 一開始Azure DevOps會要求開發者建立一個組織 Step 2. 建立專案 在組織底下我們可以建立多個專案 Step 3. 建立 Pipeline 選擇Pipelines > Builds Step 4. 設定Pipeline 選擇Source Code的來源 : 這邊示範從Gitlab伺服器上抓Code下來編譯 填入遠端倉庫的位址, 帳密 然後" 下一步 " 選擇Pipeline的範本 : 待會我們會根據這個範本作些微的調整, 讓他可以正常編譯程式最終部屬到Azure App Service上 設定與調整Pipeline範本: 這邊比較重要的部分是Azure帳號裡的訂閱ID, 以及要部屬的目標App Service 的名稱 最後按上方的" Save & Queue " 接下來Pipeline就會跑起來做事 結果 如果一切順利的話, 可以看到類似以下的結果

[簡易教學] 五分鐘內學會使用Gitlab Pipeline作CI

前言 現在的Gitlab加入越來越多功能, 開發者除了可以用Gitlab作原始碼的遠端儲存庫之外, 也可以用它來作Continuously Integration(簡稱CI) 以下內容示範如何使用Gitlab Pipeline作CI 1. 開案 ( Create a Project on Gitlab ) 開案成功之後會得到儲存庫的位址, 以及設定git環境的相關指令 2. 設定工作目錄 使用以上的指令來設定git遠端儲存庫的位址 3. (Optional) 加入一些檔案 這裡以Node.js程式為例, 建立一個index.js檔案, 內容就讓它印Hello world就好 echo "console.log('Hello world')" > index.js 4. 加入腳本.gitlab-ci.yaml 我們必須加入腳本告訴gitlab去執行什麼工作 image: node:8.9-alpine stages: - buildMyApp buildApp: stage: buildMyApp script: - echo "start my job" - node index.js image : 由於CI是跑在Container內執行的, 若對runtime的環境有特別要求的話, 可以指定相應的docker image來起Container stages : 由於CI是分階段循序進行的, 我們必須把CI中的每個階段定義在這邊 buildApp : 定義任務的內容, 這邊要指定任務屬於哪一個階段 我們可以在script底下定義buildApp這個任務應該要執行什麼動作 (預期一開始先印出start my job, 然後執行Node.js 程式去印Hello world) 5. 上傳 $git add -A $git commit -m "add some file" $git push origin master 6. 最後來看結果 程式碼Push上去之後就可以進到底下頁...

[ 解決方法] LINQ to Entities does not recognize the method System.String Format

前言 相信.NET的開發者對Entity Framework(簡稱EF)絕對不陌生, 這是基於.NET的ORM框架, 除了可以讓開發者用存取物件的方式與資料庫溝通之外, 還可以搭配LINQ to Entity的技術, 更輕易地撰寫查詢邏輯, EF底層會自動將這些邏輯轉換為對應的SQL語法,然後執行在SQL Server上 雖然LINQ to Entity很方便, 但在使用上也必須小心, 不然有可能在編譯的時候都OK, 但Runtime時卻跳出以下的錯誤訊息 錯誤訊息 LINQ to Entities does not recognize the method System.String Format 錯誤的使用方式 這個問題出在於Select 的時侯呼叫了 string . Format   在這個情況下使用LINQ to Entities時, C#會告訴SQL Server去執行 string . Format , 但由於SQL Server上沒有相對應的指令, 所以才會出現這個錯誤訊息 解決方法 可以將Query分成兩段, 前半段最後呼叫 .AsEnumerable() 將資料讀到記憶體中, 後半段Query就能以LINQ to Objects的方式來操作資料, string . Format 也可以正常的被呼叫