某一天要新建新的Repos，發現建立起來完成後，預設的Branch從原本的Master變成Main，一開始以為是系統那邊壞掉，為什麼名字會被改變。最後看到兩篇文章，原來是因為Master這個敏感文字關係。

Regarding Git and Branch Naming — Software Freedom Conservancy (sfconservancy.org)

而目前整個Git生態也似乎開始要逐步將Master字眼改掉，雖然，在文化上這是好事，但是，在Azure DevOps應用上卻點麻煩，因為當所有之前設定都是以Master為主時候，突然換成main也是頗麻煩。不過，好在這部分在Azure DevOps新功能上，可以修改新建的Repos的預設Branch名稱，來解決此問題

要修改預設Branch名稱，就要到整個Azure DevOps組織設定中找到Repos的Seeting，將Default branch name for new repositories 打開

Azure Synapse 是Azure針對大型資料分析的一個新的服務。那個其他服務有甚麼不同，主要在於這項服務可以一次性針對各種不同類型資料進行分析。而這次想讓我會去嘗試原因在於如果我每次蒐集的資料都放在Blob，但是Blob本身並無一個好的工具可以讓我查詢Blob File內的檔案資料，變成每次要查詢Blob File內的資料都必須要下載檔案，然後去查看資料內容，這是相當費時又耗人力。如果，Azure Synapse Analytics能解決這部分或許是一個不錯選項，當然，Azure Synapse Analytics功能不只這些。可以先來看看Azure Synapse Analytics本身架構如何

一般可能認為Azure Synapse是原本Azure Data Warehoue的改名或是加強版，不過，Azure Synapse也加強了分析Big Data能力

什麼是Workhub，Workhub就是可以將組織內常用的服務集中在一個Portal的概念，讓這個Portal是被掛在Teams裡面，這樣只要當用戶使用Teams就可以同時在一個平台內使用其他服務，在早期我在認為Teams就因該走向這個方向。Teams本身就整合許多Office 365功能，如果都能在Teams內使用，其實，有時候也就不需要額外登入Sharepoint，畢竟這樣體驗是相當不好的。

而目前在Workhub能做的工作有以下這幾種

• 連接企業內的應用系統和資訊來源
• 連結Teams原有的功能
• 內建自動化流程的應用，也就是Power Automate
• 整合Power App

如下圖，幾乎可以將所有Office 365整合到一個Portal內，這邊用幾乎，主要是有些可能未來才會支援。這樣也等同於可以設計成為企業的EIP系統

當我們將SQL開發在DevOps過程中讓它也進入到版控，那樣就需要在每次Check In Code時候，能過作自動幫我們去Scan Code是否有符合T-SQL的開發規範或是有人撰寫影響效能的SQL語法。

我找了半天終於在MarketPlace找到一個現在是免費整合在Azure DevOps的套件

去年有幸在中原大學教導學生關於資料科學相關知識。然後就用Azure一些服務建構關於資料平台。為什麼需要資料平台?在IoT是世界中其實要蒐集結構化的資料並不是那樣容易，此外，很多人會很習慣資料讓資料能有結構化，方便做後續的資料分析。不過，在AI或是ML時代再加上需要大數據的世界，大家都希望能從大量數據中找出些甚麼或是AI化甚麼，但是，因為一開始蒐集資料就想要有邏輯性或是結構性或是主觀性的資料，這樣做法，往往都會犧牲掉一些我們自己認為不需要的資料或是不重要資料。有時候這樣反而忽略掉許多資訊或是跡象，進而失去獲取資料價值機會

今天要來談談如何備份在Azure DevOps Service上面的Repository。為什麼需要這樣做?既然都用雲端服務，為甚麼還需要把雲端服務的檔案備份呢?主要在有時基於所謂"資安"或是"ISO2XXXX"相關條文就需要做到這一點。當然，另一種就是對於所謂"雲端"抱持的存疑或是其他的不安全關係，必須做到這一點。我想如果今日是使用Azure DevOps Server可能就不會需要這樣子做吧。

不過，既然有這樣需求存在，要去備份Azure DevOps Service上面的Repository也不是不可能。要做到這樣方式也不難，不過，如果靠手工做這件事情，又相當的不先進。因此，我們來透過自動化方式外加使用Azure DevOps Service的Release排程來完成定時備份Azure DevOps Service的Repository

作法依序為下列幾個步驟

• 取得Azure DevOps 專案內的所有Repository 名稱
• 用Git Clone所有Repository
• 用Git Pull 定期同步所有Repository

首先，先設定幾個變數吧

$PATToken="PAT"
$base64AuthInfo= [System.Convert]::ToBase64String([System.Text.Encoding]::ASCII.GetBytes(":$($PATToken)"))
$AzureDevopsOrg="Organization Name"
$AzureDevOpsProject="Project Name"
$LocalfilePath="Backup File Path"

• $PATToken: 取得Azure DevOps的PAT Token，其中權限可以只開針對Repository部分就好
• $base64AuthInfo: 轉換成Base64編碼，等下呼叫Azure DevOps API會需要用到
• $AzureDevopsOrg: Azure DevOps 組織名稱。名稱為在於dev.azure.com/組織名
• $AzureDevOpsProject: Azure DevOps要備份的專案名稱
• $LocalfilePath: 要儲存的位置，這邊會設定在地端或是某台VM的儲存位置

然後，就是呼叫Azure DevOps Service API，取得該專案內所有的Repository

$ProjectUrlAPI = "https://dev.azure.com/$($AzureDevopsOrg)/$($AzureDevOpsProject)/_apis/git/repositories?api-version=6.1-preview.1"   $Repo = (Invoke-RestMethod -Uri $ProjectUrlAPI -Method Get -UseDefaultCredential -Headers @{Authorization=("Basic {0}" -f $base64AuthInfo)})

透過_apis/git/repositories?api-version=6.1-preview.1 這個API就可以抓到該專案下所有的Repos Name

$RepoName= $Repo.value.name

當有了所有Repos Name，接下來就好辦事了，只要透過Git 指令，就可以進行Clone或是Pull 等動作。

在這邊因為只有第一次或是遇到新的Repos才需要做Clone，其餘，只需要做Pull更新就好，不然每次都做Clone，不僅費時，還必須把原本的檔案給刪除，這樣不切實際

ForEach ($name in $RepoName){    $ReposUrl="https://anything:$($PATToken)@dev.azure.com/$($AzureDevopsOrg)/$($AzureDevOpsProject.Replace(" ","%20"))/_git/$($name.replace(" ","%20"))"    $FilePath="$($LocalfilePath)\$($name)"       
if(Test-Path $FilePath)    {     
   cd  $FilePath        
   git pull origin Develop       
   git pull origin master        
}    
else {       
   git clone $ReposUrl $FilePath -b master
    } 
 }

在這裡的Pull我會同步兩個Branch，而Clone我會先特別指定是要master Branch，畢竟，不一定每個Repos的預設Branch會是Master，我想先要備份在Master版本的Code就好。

不過，最後發現如果用Pull兩個branch，其實，是否一開始一定要指定Clone Branch似乎也不那樣重要了。

這些Powershell寫好後。就是來設定Azure DevOps Service上的Release功能`只要新建立一個Release Pipeline，然後，在Task中選擇Powershell

使用Express Route的Azure Private，讓我們可以透過地端VM使用RDP方式連線到雲端VM，這樣方式就不一定要透過VPN方式才可以連上雲端，畢竟這樣建立起來，等同於地端VM與雲端VM就會屬於一個Close的網路系統。

首先要這樣做的時候，必須要先確認Azure Private是否已經被開通了，如果沒有後面就不需要再設定

一直知道在Azure Web App可以與Visual Studio 整合，進行遠端偵錯，不過，通常的情境來說，都是可以在本地端就可以找到問題。很少需要透過這方式去找Bug，但是，今天遇到一個Case要本地端進行偵錯就相對困難，主要原因是在於環境上的限制。為什麼呢?在Azure Bot要整合Line Channel，但是一直不知道為什摩會發生Bot接收到Line Message後，就發生錯誤，而這環境是直接在Azure Bot與Line Channel直接建立，並非透過程式去整合。所以，要最快方式找到答案，就是直接開啟Remote Debug。

要進行Azure Web App Remote Debug，首先必須要將你佈署在Azure 環境上的App設定為Debug Mode，這樣才可以開啟偵錯模式(如果本身就是開發模式就不需要)，總之必須要讓你的系統處於能除厝模式