Image for post
Image for post

之前用想透過Azure Synapse Analytics來做資料平台,不過,又發現Azure Data Explorer似乎也可以做類似想要的東西,於是也來實驗看看如果用Azure Data Explorer的效果會怎樣。但這前提是Azure Data Explorer就無法用一般的SQL語法去找尋資料,這可能對於習慣SQL人來說就會必須再額外學習一套語言,在Azure Data Explorer是使用KOL的語法作為搜尋資料

Azure Data Explorer是可以針對各種資料型態的資料去進行查詢與分析,這一點跟Azure Synapse Analytics又有幾分相似


Image for post
Image for post

某一天要新建新的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 打開


Image for post
Image for post

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能力


Image for post
Image for post

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

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

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

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


Image for post
Image for post

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

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


Image for post

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


Image for post
Image for post

今天要來談談如何備份在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


Image for post
Image for post

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

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


Image for post
Image for post

一直知道在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,這樣才可以開啟偵錯模式(如果本身就是開發模式就不需要),總之必須要讓你的系統處於能除厝模式


Image for post
Image for post

前一篇的[[玩具系列]快速建立一個Azure Bot Service 服務]可以用Bot Service建立好Bot服務,再來就是要看把這個Bot放到那一種IM軟體上,在公司可以使用Microsoft Teams,但是如果是要自己非公司外用,比較常用就是使用Line Bot,如何開發Line Bot呢?首先就是要建立Line Bot的Message API,所以,我們要去Line的開發網站https://developers.line.biz/,申請一組Line Message API 的Provider和Channel。

申請Line Message API

申請Line Message API方式的介面是會常改。但不外乎就是幾個步驟

  • Create a new provider

About

Edward Kuo

Enterprise IT Manager / Microsoft Regional Director / Microsoft MVP / DevOps Expert / Speaker, About me: https://profile.edwardkuo.dev/about/

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store