首先感謝微軟技術團隊提供支援,協同解決
當大家開始習慣使用Microsoft Teams
時候,就會開始把習慣透過群組方式分享檔案給團隊成員, Office 365雖然有提供每個帳號1TB的Onedrive空間,但是,對於公用的空間卻是有限制的,其計算方式1TB+Account個數x0.5G
,換句話說如果公司人數1000人,共用的空間大小則是1.5G
。而這1.5G
會被SharePoint和Microsoft Teams所儲存的檔案大小給瓜分。所以,感覺很多,但其實也不太夠用。
此外,Microsoft Teams是一個很獨特的工具,因為前端看見是Teams,但其實背後隱藏技術卻是被架構在SharePoint、Skype for Buinsess…等Office 365內的服務之上,所以,Microsoft Teams的檔案管理背後其實是被SharePoint管理,所以,當我們建立一個新的群組,等於是在Office 365上面建立一個SharePoint Web Site,只是在SharePoint Admin管理介面中看不到這些群組
這時候,就必須Teams的管理上真的還不夠人性化,在SharePoint Admin看不到,且在Office 365後台也沒有相關資訊,對於管理者來說真的不夠方便,不過,目前最差狀況就是還可以透過PowerShell
管理,至少是還是有解決方式
既然要透過PowerShell
管理,就必須先安裝相關管理模組,才能與Office 365連線溝通,首先必須下載SharePoint Online 管理命令介面
,下載套件網址
https://www.microsoft.com/zh-tw/download/details.aspx?id=35588
這邊使用的PowerShell
語法,基本上就是管理Office 365用的語法,如前面所說,Teams群組其實背後是SharePoint,所以,語法上等同於查詢SharePoint使用檔案空間狀況,下面逐步撰寫相關查詢語法
|
|
2.連線到SharePoint Admin Portal
Get-UnifiedGroup
主要是列出所有群組列表,可以再放其他參數了解該群組的細節
3.列出群組使用的檔案大小
群組的SharePoint網址格式都會是https://BBB.sharepoint.com/sites/Name
限制群組空間大小,是採用MB
計算,空間計量設定有兩個地方,一個是警示容量大小,一個是可用容量大小,警示容量顧名思義就是當使用到警示容量會有提示功用,所以,設定容量限制時候,可用容量不可以小於警示容量,不然會出現錯誤,如果要自行設定容量大小,必須先在SharePoint的設定功能去變更網站集合儲存空間管理
,必須改為手動
1.變更警示容量大小
2.變更容量大小
使用上面兩行指令就可以變更容量大小了,如果想知道每個群組的設定值,也可以使用下面方式
以上方式是目前唯一可以去管理Teams方式,希望之後可以把這些指令併入到原本O365平台內管理,此外,這邊另一個不好地方,就是用戶如果自行建立群組,是會被設定預設大小,所以,管理者必須定期掃描哪些是新建立群組,那些群組還沒有被限制空間大小,不然,哪邊某一個群組放上大量檔案,把共用空間用光,就會讓其他群組無法上傳檔案了
1.管理網站集合的儲存限制
2.https://technet.microsoft.com/zh-tw/library/mt238272(v=exchg.160).aspx
在資安逐步被重視的年代,企業會導入更多資安相關工具,除了本身伺服器或網路層的工具外,近年也針對程式碼進行安全性的掃瞄,目前其中市面上比較熱門的工具之一就是HPE Fortify,他本身可掃描的程式碼種類很多。在開發者端,可以透過Visual Studio的Plug in方式,安裝在Visual Studio,如果你又有Fortify Center的登入權限,便可以從Center將資安團隊設定好的規則下載下來,透過企業訂好的資安政策去掃描自己的程式碼,完畢之後,可以選擇把報告上傳到Center或是在本地自己觀看,掃描後的結果,不過,這邊我建議是上傳到Center中,可讀性會比較高,報表內容比較好看得懂
既然要走DevOps
,當然除了在開發工具安裝外,也會希望在CI
時候,也可以把資訊安全檢測的這一段給自動化,目前,VSTS可以透過外掛套件將Fortify整合進來,其套件名稱為Micro Focus Fortify,在 點我 來下載安裝
這邊為什麼要多安裝Fortify這步驟,因為,雖然說套件可以幫忙做到自動化,但是它底層其實是必須先有Fortify核心,然後再透過PowerShell指令驅動它,然後進行程式碼的靜態掃描。今天如果是透過地端VSTS Agent來建置,建議是手動先把它安裝好,雖然,這個Plug in有提供Fortify Static Code Analyzer Installation
,其中有些設定必須要有Admin權限,所以為了省掉這中間的麻煩,還是先手動安裝好
安裝HPE Fortify SCA其實不難,主要在於必須設定裡面的資訊。
找到HPE_Security_Fortify_SCA_and_Apps_17.10_windows_x64.exe
進行安裝,有買這產品的人,因該都會有這一個檔案,不過,這一個版本目前不支援掃描ASP.NET Core,必須等到HPE_Security_Fortify_SCA_and_Apps_17.20_windows_x64.exe
才可以針對ASP.NET Core掃描。另外,會自動幫你安裝IDE的Plug in,不過,目前似乎不支援Visual Studio 2017版本,2017必須額外安裝Plug in。
安裝過程到了一半,會請你輸入Software Security Center的URL,就看自己企業內部架設的Software Security Center網址填入進去就可以,SSC網址會類似這樣: https://XXX.XX.XX.XX/SSC,到這邊看似已經完成,不過,會建議先用Command方式測試是否可以上傳fpr檔案,如果,無法上傳檔案,就必須找出哪邊出問題,不然,到時候VSTS也沒有辦法自動化完成上傳檔案,當然,如果不需要上傳檔案到SSC,就可以不用管它
如果遇到憑證問題,必須執行下面指令,必須先跟SSC管理員取得.cer
檔案,並匯入到環境中,才不會發生憑證問題,造成無法連線
如果單機上測試都沒有問題,接下來就可以進行自動化部分,另外,在fortify中有一個fortify.license
的SCA檔案,也要一併放到可以被VSTS Agent讀到的位置,因為在設定後續的Fortify Task會使用到這個檔案
在fortify安裝資料夾中找到fortifyclient.bat
,用這個測試上傳fpr是否有問題
安裝完畢Micro Focus Fortify套件後,可以看到這些相關的TASK
要掃描程式碼,選Fortify Static Code Analyzer Assessment
這個來用就可以,主要設定可以分三大塊
主要設定SCA License檔案位置,和每次產生fpr檔案的命名規則
這邊設定是要編譯程式的類型,在17.1版只有分.NET
& ‘Java’版本兩種,且還不能編譯.NET Core,不過,據說下一個版本會擴充更多可編譯的類型,然後,在選擇專案位置,這邊有一個比較奇怪地方,就是如果上面有一個TASK已經做過Build,在這裡把Run Build
取消,就會發生失敗狀況,所以,這邊還是必須把Run Build
打勾,才可以順利進行下去。在17.1版如果是.NET程式,還是仰賴MSBuild
進行,所以,編譯那一台機器上必須可以執行MSBuild
掃描類型可以分成Cloud和Local,在企業端大部分都是選擇Local
Scan,就可以開始進行掃描的動作,這部分會執行時間相當長,所以,建議可以用定時執行Definitons方式
當掃描完畢之後,就會產生.fpr
檔案,這時候就必須上傳到SSC Server。此時必須先設定SSC的End Point位置,設定主機屬性如下
Application Name
和Version
必須和SSC上面註冊是一致的才可以,換句話說,必須在SSC註冊一個Application和它的版本完成以上步驟,就可以自動化的SCAN,同時上傳掃描後的檔案了
]]>活動時間: 1/06/2018 9:00:00 AM
活動地點: 台大管理學院1號館/台北市大安區基隆路四段144巷 No. 52
邀請了高達 15 位講師,分享他們的專業知識和經驗,在一整天的議程中,您將可以盡情地享受 IT Infrastructure、Dev、Agile、DevOps、Azure、Database、AI…等相關的議題,無論您是初學者、轉換跑道者還是資深的技術人員,這裡皆有適合您的議程。共同學習,提出問題與講師交流,藉此精進您的開發技能。
技能範圍從容器開發、DevOps到MR都有,重量級講師盡出,不來太可惜了
]]>在先前一篇的[用VSTS建立.Net Core的Package],建立屬於.Net Core的Nuget Package,其中在Path to csproj or nuspec file(s) to pack
是沒有辦法放.nuspec
檔案的,但是,原本在.nuspec
有一個標籤可以把外部dll包進Package
不過,目前VSTS上面那個Dotnet Task無法讀取.nuspec
檔案,就導致無法把外部參考的dll一起打包,而在介面上也找不到可以加入的地方。其實,在頁簽上面設定,都會被記錄到csproj
檔案中
在csproj
有下面tag包住的資訊就跟在Package頁簽上面看到是相同的資訊
既然這樣,那樣也是因該可以在這邊加入我想要的打包外部dll設定才對,畢竟,在這裏面的屬性其實是對應到.nuspec
的標籤的,找了半天,最後可以下面語法加入到csproj
中
第一行_PackageFiles
是說在專案資料夾中,你把外部的dll放在那個地方,需要去那邊抓到這個dll,第三行PackagePath
是把dll放到package內那個地方,就.Net Core來說目前必須放到netstandard2.0
資料夾內,所以,就必須設定把dll搬移到這邊
這樣設定好之後,再重新跑一次CI,就可以完美的把外部dll也打包進去了,雖然可以解決目前這問題,最好方法還是可以正常讀取.nuspec
檔案
Application Insights可以讓我們去設定監控某些指標,當這些指標有發生異常時候,就會發送Alert通知,讓我們隨時知道發生的狀況或是是否有異常發生
我們通常會設定是屬於Exception類的訊息,且這對於開發或是維運人員來說才可以立即進行處理,同時也是屬於DevOps環節的一塊,不過,透過Mail方式收到資訊內容就會像下圖這樣呈現方式,就這樣內容來說只知道有發生問題,但是無法知道問題點是甚麼,是否要做立即性的的處理,且若想要知道更細節的資訊,還必須回到Azure內查詢,才可以知道是到底是發生甚麼錯誤
若是使用手機去查看時候,更就會感到不方便。先前有實作一篇Azure Application Insights發Alert訊息到Slack,可以透過Logice App利用Application Insights的Webhook作為發送管道,雖然,可以放入比”Mail”還多的資訊,但明顯還是不夠,這時候就可以利用Logice App屬於Application insights的功能,這目前還在Preview版本,透過這個的Application insights Task就可以在訂定更多細節的資訊
在這次設計上,只需要三個步驟就可以讓Application Insights蒐集到Exception送到Microsoft Teams Channel,算是很簡單了
Recurrence主要是設定間隔一段時間確認Application Insights內的資料,可以依照需求決定時間點
在Logice App的Application Insights Task共有兩種Application insights Query
& Application insights for Visualize
因為Logice App會與Application Insights做資料串接,所以,我們必須讓Logic App可以與Application Insights溝通,因此,要設定Connection Info
建立API金鑰
,就可以得到設定完以上資訊,就可以讀取到Application Insights資料,之後,就採用Application insights Query
這個Task,要使用語法可以先在Application Insights Analytics去跑跑看自己寫的語法是否可以運作,下面為這次實作的語法,主要是抓取資訊類型是屬於exception
的
|
|
上面查詢語法的每個欄位,之後都可以當作傳送的資訊欄位
設定好取得Application Insights資料後,再來就是設定綁定到Microsoft Teams,在Task中找到Microsoft Teams
要將資訊POST到Teams的Channel,所以選擇Post Message
前面有提到,透過Application Insights Query的資料欄位,都可以作為傳遞訊息的欄位,所以,可以看見Parameter都是剛剛查詢出來的欄位,然後,就可以在Message組合自己想要收到的資訊,因為是Application Insights Query查詢到的資料,所以,可以完整呈現出Application Insights蒐集的資訊
另外,在發送資料時候,Logic App會用迴圈方式一筆一筆將資料推送到Teams
整個流程如下
Logic App功能越來越強大,整合越來越Microsoft SaaS的服務,對於企業來說可以省掉整合的成本與時間,但是,採用排程方式並不是最好的,最好的方式還是用觸發會比較好,又因為觸發沒有辦法找到詳細資訊,所以,目前怎樣運用就自行評估,不過,也許後續有可以透過參數方式丟給Application Insights Query,這樣就可以透過觸發方式去運作
]]>我們知道使用VSTS中的Packages Manager可以建立企業或是私有的Nuget Server,在一般.Net Framework下,可以用下面幾個步驟建立Nuget的Package,其中使用到的是MSBuild
做編譯,再用Nuget指令打包成Package
不過,今天若是也這樣對.Net Core
專案進行封裝,雖然會成功,但是,當在.Net Core
專案下載來用時候,就會出現你使用了.Net Framework,不能使用在.Net Core專案中,請使用XXXXX字樣,主要原因是在編譯時候,單純使用MSbuild的Task,會被使用.Net Framework進行編譯封裝所造成的問題,網路上有人說可以採用/t:package
方式克服,不過,既然使用了.Net Core
,就改用.Net Core
方式做CI & CD吧
首先啟用的專案類型是.Net Core Libray
之前在.Net Framework
時期專案,因為封裝成Nuget Package,必須透過.nuspec
檔案把元件資訊填入,這樣別人才可以知道這個元件用途以及相關資訊,在.Net Core專案底下,已經可以省略這個檔案了,因為,要把這些需要填入資訊已經納入專案檔中了,在專案按右鍵找到屬性設定
針對整個專案設定部分,會多出一個Package
頁簽,會發現填入的資訊跟.nuspec
檔案內容是大同小異,只是這邊已經被限定好欄位了,上面有兩個需要打勾的,基本上是不需要去勾選
在Build設定中,基本的完整流程如下:
在Nuget Task,要注意的就是它的Task Version,記得一定要選到最新版本,若是有Nuget.config
檔案,也記得要放上去
donet Task這裡如果只是單純Build .Net Core專案倒是不需要注意Task版本,但是,如果要封裝Package,記得選到最新版本,目前版本最新是2 Preview
,因為在最新版本才會有Pack
的指令,這裡的Path to project
專案路徑,不能用選的,必須要用手敲入,記得不能打錯路徑,不然會失敗
重頭戲是在這邊,搞定這個搞超久,再提一次,記得選到最新版本,不然會找不到Pack
指令
此外,這邊有一個小坑,就是在Path to csproj or nuspec file(s) to pack
提到可以使用.nuspec
檔案作為Package的資訊檔案,但是,當我指定.nuspec
檔案時候,就會出現不支援.nuspec
檔案格式是沒問題的,所以,就指定.csproj
,前面有提到,在.Net Core已經可以把封裝資訊放入專案檔,用處就是在這裡要被使用的。此外,我喜歡用Buil Number來作為Package版本號,也在Automatic package versioning
中選用使用環境變數
作為版號,而環境變數就是使用Build.BuildNumber
另一個要提醒的是這邊先不要把Do Not Build
打勾,話說前面不是已經有Build過嗎?因該不需要再Build,這裡的Build主要是要做封裝用,所以還是必須要Build一次。
到這裡基本上就大功告成,後面兩個Task,主要是把封裝檔案上傳到發布區域,等待後面的發行
到這裡只需要用一個Task就可以進行發佈到團隊的Packages中
只要選擇Nuget Publish,把相關資訊田入就可以,唯一要注意是要選擇4.0版本的Nuget指令
以上就能完成在VSTS針對.Net Core的CI / CD 了,有一些眉眉角角必須多踏過,不然還真的跑不出來,所以,不管是.Net Framework或是.Net Core都可以自動化封裝成Nuget Package
]]>在使用VSTS Agent 2.115版本時候,在企業內部使用是沒甚麼問題,不過,最近升級到2.123版後,地端與雲端就失聯,就無法進行連線,到_diag
資料查看Log,發現會卡在最後連線驗證地端權限時候,一直發生Timeout
然後Agent就發生Exception,導致怎樣都無法與雲端溝通,如果再倒回2.115版又可以連線,真是太神奇
仔細研究一下,因為企業內部必須透過Proxy
才能連線,在舊版的Agent,因為會自動去吃在IE內的Proxy設定值,所以,沒有問題,但是,到新版的Agent,似乎就不是這樣,它在對外連線,基本上就不走Proxy,直接對外連線,就會導致無法連線,就發生了TimeOut,要解決這個辦法,就是在Agent目錄下新增一個.proxy
的檔案,用Powershell執行下列指令
|
|
這樣Agent在執行時候,就會透過Proxy連線到外面,如果,你的Proxy需要設定帳號密碼,就必須在環境變數中加入下面資訊
|
|
就可以解決了
]]>Microsoft Teams一個值得高興的更新,就是Microsoft Teams可以支援外部訪客加入Teams團隊中了,原先,要使用Teams的成員,必須具備O365帳號且還必須同一個組織或是公司下的O365帳號才可以一起使用Teams,現在這些非原本在同個組織下的O365帳號或,都會被當作訪客登入到Teams,首先,先來看用訪客身分登入後,訪客會具備那些權限
不過,雖然可以邀請訪客登入,但是,這邊有一個前提就是邀請者本身必須是O365管理員或是該群組的管理員,可以邀請訪客登入。不然,無法邀請訪客的加入。現在只是讓帳號本身是其他O365才可以,未來據說可以連Windows live ID也可以用
Microsoft Teams預設沒有開放給訪客使用,如果要啟動這功能,必須到Office 365管理者平台去設定Microsoft Teams的功能
在Teams設定中找到Settings by user/license type,找到選項是來賓
,從這邊可以看出來,這設定預設是無法被授權給外來訪客的,所以,我們必須要開啟它
一旦打開之後,就可以指定的群組中,加入你想要邀請的人的Email,不過,目前這邊設定有一點奇怪,就是先設定好要被邀請方的Mail,就會送邀請信給被邀請方,但是,有時候會消失,必須等被邀請方認證過後,再去加一次才會成功
這時候我們可以在被邀請方的Email看到作為訪客字樣,被邀請方就可以用這Email當作帳號登入Teams了,當然,在O365的使用者管理中,就可以看到這組Mail被歸納到來賓使用者
了
訪客部分,不要以為對方把你邀請加入Teams後,就可以直接打開Teams,輸入Email就可以登入唷。這樣會收到你沒有權限登入的畫面,必須先到你收到邀請的那封Email中,點擊裡面的連結
就會開啟Teams網頁版,第一次登入時候,會要求你建立你的登入密碼。這些手續完成後,才可以進入到Microsoft Teams。另外,作為訪客身分登入是無法改動自己暱稱的。
現階段測試不知道是哪邊權限整合上問題,基本上無論使用Desktop程式登入或是透過https://teams.microsoft.com
網站登入都會收到下面訊息
但是透過邀請信的link就可以登入,我想邀請信中連結中的變數因該是會把資訊帶入到登入認證中,但是,目前Desktop程式這部分似乎還有問題,沒有辦法很順利登入
]]>把前端的一些靜態檔案像是css
、js
…之類的放到Azure Storage,然後,讓網站去參照Storage路徑下載靜態檔案,基本上這樣並無太大問題,不過,做多國語系時候,使用到i18n
這個套件,裡面會利用translation.json
檔案做多國語系,誰知道這樣使用下卻發生了這個錯誤訊息
CORS not enabled or no matching rule found for this request
通常遇到這問題,我們會去web.config
去設定CORS的屬性,來避開這錯誤,不過,針對這個檔案似乎無效,它依然出現這樣錯誤資訊
因此,發現在Storage有一個設定,叫做CORS
,看名字就知道顧名思義,因該是針對CORS進行處理,進入這個設定功能後,我們只要設定好CORS規範,基本上就可以解決CORS問題(基本上因該是連Web.config都可以不用設定)
設定這規範其實很簡單的,它是針對每個Host Name去做設定,只要按下Add,就可以看到旁邊設定畫面
看到這畫面要怎樣設定呢,其實最簡單方法就是利用F12
取得原本失敗檔案的Header資訊,分別填入就可以,參考資訊如下圖藍色框的欄位
透過以上對應關係,只要把資訊放入就可以,若是要更進階一點,針對Allowed Header & Exposed Headers,若是要包括更多的資訊,可以用星號省略後面的資訊,只要符合前面字樣就可以,設定會像是這樣x-requested*
,只要是x-requested
開頭的,都是符合這規則。
這樣設定完畢後,就輕鬆解決CORS問題了
]]>在前一篇的[在VSTS中建立npm套件管理平台]介紹說可以在VSTS內建立NPM
套件平台,因為,VSTS建立的NPM套件管理平台是屬於私人的,所以,會有註冊憑證的動作,不過,這樣做下去之後,卻發生一個問題,如果今日我們是要從原本NPM官網下載套件,就會發生這樣錯誤
其實這錯誤就是因為在.npmrc設定檔中註冊是VSTS NPM套件路徑,而原本NPM平台上套件又不在VSTS,導致會發生失敗,如果不是上面錯誤,也會發生找不到Package路徑問題。要解決這問題,可以去開啟VSTS Package中的Upstream sources
功能,下圖這個要把它Enable起來
它的原理其實就是安裝時候,會先到VSTS Package裡面去找是否有符合你要安裝的Package,如果沒有,就會自動往npmjs.com
再去找
這樣就可以安裝好在npmjs.com
上面的套件了,這時候,會發現在VSTS的NPM套件平台上可以看到團隊套件有來自npmjs.com
的都會被Cache在這上面
如果擔心找不到自己建立的Source,可以透過filter去搜尋this feed
,就可以找到自記建立的套件列表
一般想要在個人電腦或是Windows Server 2016玩Docker,前者可以安裝Docker for Windows,後者啟用Window Server的Container,這樣就可以開始使用Docker指令,不過,今日只是想在某台電腦透過Docker -H
去執行Remote具有Container的機器,是否還需要完整安裝上述所提的功能才能使用Docker Command呢?
答案是可以不需要在電腦上安裝Docker for Windows或是啟用Container,就可以執行Docker了,只需要安裝Docker CLI就可以。Docker CLI網路上版本還不少,但我目前使用Chocolatey Package Manager來安裝Docker CLI,感覺上還不錯,且安裝又方便簡單
1.首先用PowerShell來安裝Chocolatey,PowerShell需要用Admin執行
2.安裝好Chocolatey,就透過它幫我們安裝docker CLI吧,通常這個步驟也是使用Powershell執行,不過,我發現執行後會卡住,改用Command Line就沒問題,如果有問題可以改用cmd
試試看
因為目的是想要透過本身的機器去操作遠端的Docker,所以,前提必須記得去改遠端Docker的daemon.json
檔案,要加入下面這行
這行目的主要是說我們可以透過Port2375
進行連線,當然雙邊的防火牆記得要開啟Port2375
3.完畢後就下達重啟動指令就可以
這樣就可以讓這台機器具有Docker指令了
]]>在之前有介紹透過VSTS的Packages
可以自建團隊的Nuget套件管理平台,在Packages
中不只是可以建立Nuget套件的管理平台,如果,今日是前端人員或是非.NET人員,想要用npm
指令來裝前端套件,VSTS是否可以做npm
套件的管理平台呢?答案是可以,VSTS的Packages同時支援Nuget和npm套件管理,就讓我們來建立一個npm packages管理平台吧。
在VSTS的Feed本身就同時支援Nuget和npm,換句話說可以在同一個Feed URL同時存在兩種套件管理,不過,並不建議這樣混合使用,畢竟這樣使用會造成套件本身管理的混亂。還是建議把兩種不同屬性的Package分別建立不同的Feed。要建立Feed只需要選擇建立就可以,很簡單的
只需要填入Feed名稱就可以建立成功,建立成功後去點選Connect to Feed,可以看到裡面有Nuget和npm兩種設定方式
透過VSTS自動化建置npm package的流程比建置Nuget package簡單許多了,今日若是要透過VSTS自動化建置,上圖中的設定可以暫時不需要管它,後續如果是在Clinet進行,則必須要做一些相關設定才有辦法,先來說講最簡單的,使用VSTS建置npm package。
因為npm主要是封裝前端的元件,基本上都不太需要做到編譯的動作,當然如果今天是用SCSS
需要編譯成CSS
才給人家用,這樣就需要增加編譯動作,不然,只要將整個專案進行封裝就可以。在封裝的前提必須在專案檔加入package.json
檔案,這檔案主要是針對Package做說明,與Package.config
有異曲同工之妙
關於package.json
說明
The most important things in your package.json are the name and version fields. Those are actually required, and your package won’t install without them. The name and version together form an identifier that is assumed to be completely unique. Changes to the package should come along with changes to the version.
關於package.json
格式,可以透過npm init
建立
有了這檔案,只需要去VSTS進行設定就可以,因為,沒有Build的動作,基本上在VSTS Build就等於Release了。所以,這邊只需要添加一個npm
Task即可
建立好Task後,就是把相關設定設定完畢就可以
install
,publish
和Custom
,這邊選擇publish
package.json
在Root就不用填寫,不然就選擇該檔案所在的資料夾Registry I Select here
,一但選用這個,下面的target
就可以選擇在你VSTS上面的Feed URL了以上屬性設定完成後,就可以讓她自動化去封裝了,同時也會自動化佈署到我們自己的Feed內,建置完成後就可以看到Feed那邊多出了npm package了
另外,如果每次要佈署時候,沒有去更改package.json
中的version號碼,會發生佈署失敗,主要原因是它不會去覆蓋原本舊版本,必須要進版才可以,不然會發生錯誤,如果不想這樣麻煩,也可以使用Version Assemblies
套件做自動化進版
既然我們已經可以用npm封裝好了,再來就是要能去使用它,因為,VSTS上的是屬於私人或是團隊的,並不像npm
網站一樣是被公開可以用。所以,這邊我們需要增加一些設定才可以抓取VSTS上的npm,不然直接下npm install xxxx
是沒有用的,主要是要把VSTS Auth驗證資訊會透過.npmrc
內資訊被設定在專案中
.npmrc : npm gets its config settings from the command line, environment variables, and npmrc files.
預設你可能沒有vsts-npm-auth
套件,所以,需透過npm安裝這個套件
然後,在專案手動加入空白的.npmrc
檔案,目前還不知道怎樣自動加入此檔案,有了這個檔案後,根據本文上面第二張圖,有一段Add this feed to your project .npmrc,把裡面的資訊registry=XXX
放入.npmrc檔案中。到了這一步完成後,就可以執行下面語法
成功後會得到下面訊息
Getting new credentials for source:https://XXXXXXregistry/, scope:vso.packaging_write vso.drop_write
如果在Visual Studio中想要安裝VSTS上面的npm的套件,可以用package manager console工具或是安裝*Flatten Packages`工具,協助我們安裝npm套件,如果使用Visual Studio Code就更簡單了
]]>Application Insights越做越強大,基本上程式內部怎樣運作,Application Insights都可以蒐集到相關資訊,不過,有時候這樣會帶來一種困惱就是在某些情境下的資訊,並不想被蒐集到Application Insights內進行分析,因為有可能造成分析錯誤或是統計資訊的誤差,舉例來說,目前發現如果在IIS中針對Web Site設定Preload
功能,在Application Insights就會多一筆Request,帶出來的資訊是localhost/XXX
,這樣資訊對目前數據分析並不重要,但是,又會被多記一筆Request的Count。
因此,像這種資訊就會希望不要被記錄到Application Insights中,目前,在Application Insights的Portal中似乎不能設定過濾訊息,所以,就必須從程式面著手
從程式面就是需要自己訂定Filter功能,首先自己建立一個叫做TelemetryFilter
的Class,並繼承ITelemetryProcessor
,從官方解釋ITelemetryProcessor
為
讓您更直接地控制包含在遙測串流中或排除於遙測串流外的內容
所以,透過它可以獲取要送到Application Insights的檢測資訊,進而做一些篩檢或是變更等動作,繼承ITelemetryProcessor
會變成如下
在這個Process中,針對遙測資訊進行處理,以剛剛案例來說,希望排除到http://localhost/XXX
資訊。就可以在這處理器這樣寫
把Item轉型為Request Type,並抓取資料中的Url
進行過濾。如果,有符合過濾條件的,就拋棄掉這個訊息不做上報的動作,如果不是,則透過Process
處理收集的資訊項目。完整的寫法如下
有這樣方式,想要過濾甚麼就可自己去定義了
開發完畢後,還必須把過濾器註冊,這樣才有辦法當Application Insights啟動後,自動掛載這個過濾器。要註冊過濾器,只要在ApplicationInsights.config
中設定就可以
這樣就可以一個簡單的Application Insights資訊過濾器就可以運作,簡單說,這個就是AP & Application Insights訊息的中繼站,所有資訊都會先到這邊再往Azure送,換句話說要在這邊做置換資訊動作也是可以的
]]>2015年有幸到中國參加此大會評審,發現雖然名為五金產品比賽,當時不乏有些不錯的IoT產品出線,不過那時候只限於中國內作品參賽,這次也可以有台灣作品參賽,工業設計高手可以去挑戰看看
“五金杯”中國五金產品工業設計大賽自2006年創辦以來已成功舉辦11屆,大賽在各主辦單位和協作單位的支持下,歷屆參賽作品的數量和質量都在不斷的進步。大賽以創新和務實的特點和國內外知名的專家評委陣容,吸引了全國幾十所高校、幾十家設計公司以及眾多獨立設計師的參與和支持。為了繼續提高五金產品創新設計能力,展現產品創新的新思路、新概念、新主張
]]>微軟在Mobile的解決方案,原先是建構Hockey App上面,不過,從今年五月開始就慢慢轉移到Mobile Center
上面,無論是Build
還是Test
,甚至到發布,都可以透過Mobile Center幫忙完成,先前的一篇文章[VSTS 整合Visual Studio Mobile Center ]中有介紹把VSTS的Repositories與Mobile Center結合,現在Mobile Center
的SDK除了原本的收集Crash Report和Analytics外,還可以讓你的APP自動檢查Mobile Center上面是否有新的版本,如果有新版本則是跳出下載提示,讓使用者可以直接更新App
在先前的Mobile Center有新版本發布時候,只能透過Mail通知用戶,還必須讓用戶點擊Mail中的連結後,再登入Portal去下載新版的App,整個體驗就很不好,也不夠直覺
在自己App加入In-app update功能前,有幾個前提必須先知道,不然,就算把Code加入,也不會有動作
Release
,不然不會有做用CFBundleShortVersionString
和CFBundleVersion
版本號更新加入Mobile Center的Distribution SDK到程式中,以下使用的範例為Xamarin.Form
,找到Microsoft.Azure.Mobile.Distribute
並安裝
安裝好之後,可以在Mobile Center要發布App的Get Started
或是Setting
地方找到App Secret
準備好以上條件後,先到App.Xml.cs
的OnStart()
加入啟動In-app update,在這邊可以發現,同時有加入typeof(Analytics)
& typeof(Crashes)
和typeof(Distribute)
,表示同時啟用收集Crash
& 資料分析
和In-app update
功能,因為這三個功能都是共用同一個App Secret
|
|
裡面有一行是Distribute.ReleaseAvailable
,這是自訂當有APP版本更新時候,會跳出的提示訊息,基本上,如果不做,預設因該還是會有提示方塊,不過,測試一陣子似乎還是不會出現提示訊息,導致沒有辦法更新APP,因此,如果是自訂一個提示訊息就可以進行App更新。
|
|
改好這邊後,還必須到Xamarin.app.ios的AppDelegate.cs
加入app啟動時候就檢查版本功能,不管程式怎樣寫檢查更新的程式一定不能在LoadApplication(new App())
之前,不過呢,又經過一番測試後,發現把這一行放在Xamarin.Forms.Forms.Init()
之後是最穩的
|
|
另外,還必須到info.plist
加入一個屬性,不過,因為在iOS中,測試App和Release的App是無法共用同一個Bundle Identifier
,就如之前所說,Mobile Center中的Build Task是Mobile Center做好的,我們並無法在裡面做其他更改設定,這也導致無法在自動化時候去更新Bundle Identifier Name,所以,必須額外做一個Release用的plist檔案,讓在Release Build時候,置換原本的info.plist
。因此,加入一個叫做InfoRelease.plist
的檔案,並在這檔案中加入CFBundleURLTypes,這邊須至換掉裡面的{App secret}
,其值是跟ConfigurationManager.AppSettings["MobileCenterAppSecret"]}
相同的
到這一步,基本上就已經讓App有了In-app update功能,剩下就是要把InfoRelease.plist置換成info.plist。
做到這一點,就只能在專案檔中加入以下設定,先在Xamarin.App.ios的專案檔找到Info.plist
關鍵字,基本上未修改前是這樣
修改後為這樣
這樣就可以在Release時候,將Release階段需要的資訊轉換成Info.plist給iOS App用了
確定功能沒問題話,在第一次安裝App後,會跳出一個網頁畫面,內容會有一段是Enable in-app Update
,有這一段話,基本這個App就具有自動更新的機制了
當Windows Server 2016開始有支援Containers後,認為只要把Windows Server 2016內的Container服務啟動後,就可以立馬來使用Docker這項技術,殊不知這是錯誤的,因為,這樣做法只是讓Windows Server 2016有了Container功能,但是,要讓它可以用Docker,還必須額外安裝Docker
模組才可以有辦法開始使用Docker的技術,而在Windows Server 2016支援的Containers有分成Windows Server Containers和Hyper-V Containers,下面採用的是Windows Server Containers。
建議在安裝Docker之前,要把Windows Server 2016所有更新檔都必須要更新,才不會有問題,然後,用Admin權限啟動PowerShell
,而第一個必須先安裝Docker-Microsoft PackageManagement
套件,有了這個套件,才能去安裝Docker的Package
安裝Docker-Microsoft PackageManagement
安裝Docker Package
都安裝完畢後,必須重新啟動電腦,讓Docker服務啟動,若是後續想要更新Docker,只要輸入更新指令就可以
以上三步驟就可以在Windows Server 2016用Docker功能,若不確定是否可以用,只要輸入docker info
能查看Docker相關訊息就沒問題了
Docker-Compose是讓你可以快速佈署或是啟動Container的設定檔,如果是透過VS.Code
去編輯Docker-Compose的yml檔案,必須先在VS.Code內安裝相關Docker-Compose套件,才可以開始編輯,但按照先前作法,已經可以在Windows Server 2016使用Docker,不過,卻沒有Docker-Compose指令,因為,必須額外安裝Docker-Compose套件,才有辦法使用Docker-Compose指令,安裝套件位置[https://github.com/docker/compose/releases],下載的檔案名稱是會是這樣docker-compose-Windows-x86_64.exe
,也可以直接用PowserShell的指令安裝套件
不過,若公司防火牆關係無法安裝化,就是必須先把檔案下載下來,並且,透過上面指令取代掉原本URL位置改成docker-compose-Windows-x86_64.exe
檔案的路徑,就可以安裝了,或是更改檔名為docker-compose
後放自訂一個目錄中,只是必須設定系統的Path指定到這個目錄中
我們會從Docker Store下載自己所需要的image建立Container,不過,從Store下載來的image只是原始的Source,有時候並不能符合我們實際需求,所以,還會額外把設定加入進去,但是,若是每次從Image建立Container,都還要重複設定一次,也很費工。如果這時候想要每次都直接用自己加工過的image,而不是原始的Source,必須花一點小方法來製作屬於自己的image,在原本Docker指令中,是有支援Export功能,但是,在Windows Server 2016 Containers目前沒有辦法用這個指令。所以,我們必須利用Commit方式進行。
以SQL Server Container為例,我們可以先把Containers建立起來後,並放入自己系統的DB
這時候建立的DB Container就不會是原始的Source,且每次啟動DB Container也不想要再還原一次DB到新的Container,這時候要把這個Container變成自己的image,以後只要啟動自己的image就可以
第一就是要先停掉Container,這個Container已經加入自己的DB
停掉Container後,用Commit方式建立新的image,這步驟通常會一點點時間
如下圖,這樣在image List中,就多出剛剛建立的客製化image source了
如果想要把這image搬到其他地方使用呢?一種就是放入registry中,若現實不允許,就只能自己把image匯出檔案囉
通常這一步又要花費更久時間,反之要把檔案匯入,則使用docker load
,就可以建立一個自己情境的docker image
上面執行Docker方式,都是在Windows Server中下達Docker指令,但是,如果要透過另一台VM或是機器去呼叫遠端的VM的Container,必須先做幾個設定,首先,要更改遠端機器的daemon.json
檔案,加入下面參數,並重啟Docker(Restart-Service docker)
須注意就是遠端機器的防火牆必須要開啟2375
Port,然後執行docker -H Remote IP:2375 info
,就可以確認是否有通了,到了這部表示遠端機器已經開放Port讓你可以遠距執行Docker指令,接下來就是執行.yml
檔案去建立Container,這次案例是建立好一個要啟動SQL Container,在yaml
的描述檔的內容如下:
通常要執行這個yaml
檔案會是放在要執行Container機器上,而這次是要透過自己電腦去啟動遠端的Container,所以,必須把yaml
檔案放在自己電腦端,然後透過下面指令執行它
就可以讓啟動遠端的Container了
https://blog.yowko.com/2017/05/docker-command-in-windows.html
https://philipzheng.gitbooks.io/docker_practice/content/introduction/what.html
就目前微軟以雲端服務為優先情況,VSTS的功能是越來越強大,再加上本身VSTS也可以與地端整合,所以,使用VSTS來做為版控工具是一個不錯選擇,不過,很多人知道好處,但畢竟是雲端服務又會很擔心,如果在公司外部讓公司有心人進入後,把所有程式碼都拿走就慘了,安全性的管理一直想用VSTS的一個。
其實只要透過Azure Conditional Access就可以解決這問題。畢竟,在整個微軟雲端服務中,無論是Office 365或是VSTS都是在Azure上面的一個SaaS服務,換句話說其帳號是在Azure AD中被管理,透過下圖可以知道就可以知道
因此,就來看看Conditional Access機制可以幫忙做到那些事情
使用VSTS時候,記得要讓Azure與VSTS綁定,可以到Team Services accounts
看是否有被綁定進來,此外,還必須注意就是Azure AD的Subscription
與VSTS被指定的Subscription
是否有相同,如果是沒有多個Subscription
基本就不會有問題,不然會發生怎樣設定都無法成功,因為被設定在不同的Subscription
上面,如果是從Team Services accounts
建立的VSTS問題是最少的
前置作業都確定差不多,就可以去Azure AD的Conditional Access功能
一進去就可以看到Conditional Access說明
這裡可以設定多個規則,我們來設定一組規則試試看,按下新增規則,可以看到有下面幾點可以設定
分成工作指派和存取控制,前者是設定相對應的條件,後者是規範在前者條件下是否可以有存取權限,看似似乎不太難設定
有哪些人員要被規範,原則上都是全部人員,可以設定要包括人員或是排除那些人員不被限制
這裡則是設定有被Azure AD管理的服務,就這組測試用的案例來說,只有VSTS有被Azure AD管理,只會出現VSTS,當然如果想要所有雲端應用程式都套用,就直接選定全部吧
像是正式環境,又有使用O365,所以,這邊列表的APP又多了Office 365,且基本上有用到微軟雲端服務的產品,都會被歸納進來,如Hockeyapp
在條件設定可以設定分別有
其中位置設定,若是公司網路,可以把公司網路範圍區域設定為白名單,這邊必須採用CIDR
標示法,如果不知道要怎樣標示,也可以透過工具www.ipaddressguide.com/cidr幫忙
這邊情境我們設定如下
上面條件設定完成後,就是設定若是符合這些條件,需要進行那些動作,可以設定鎖定或是有條件的進入,先來設定全部封鎖存取
設定完成後,就可以多一個條件原則,這時候我們再去VSTS測試看看
用網頁登入後,就會出現這提示,表示你現在可能不在公司或是已經你現在網路位置是不被允許登入的,當然用Visual Studio也沒辦法連入了
如果這時候想要某些IP可以連入情況,就去排除選項把信任IP放入就可以,除了IP還可以設定被授予裝置,只是這部分需要與Intune整合就是
透過這樣條件組合,就可以在增強VSTS使用上的安全性,也可以符合每家企業對於安全性的不同定義。
https://docs.microsoft.com/en-us/azure/active-directory/active-directory-conditional-access
]]>自從VSTS有了Packages的功能,可以讓我們自建團隊私有的Nuget後,就習慣把大量可以Re-Use套件放上去,可以讓整個團隊共同使用這些套件。不過,如果給自己團隊是沒有甚麼問題,今天要跨團隊使用呢?就是給在不同專案成員也用你開發的Package,在同一個VSTS URL下,只要去設定Feed權限也就可以,如下圖,在BestFeed
下設定給予要讀取此Package的人員那些權限
但是,如果今天是不同VSTS呢,例如 BBB.visualstud.com
要去讀取 AAA.visualstud.com
Packages內的套件,又或是其他版控平台要來讀取AAA.visualstud.com
Packages內的套件。當然第一前提依舊必須本身你有在AAA.visualstud.com內有帳號,如果沒有帳號一切就別談囉
以為有帳號就可以嗎?如果在Visual Studio內是沒問題,是可以正常把套件裝起來,不過,這時候你會發現必須先輸入AAA.visualstud.com
帳號密碼,一旦做了自動化建置,並不會跳出這樣需求視窗,這時候就會發生找不到這個在AAA.visualstud.com
內套件問題,想當然而就會build失敗了。要解決這問題採用一個最簡單方式,就是把驗證資訊設定在Nuget.config
中
假設原本的Nuget.config
是這樣設定
這時候需要加入<packageSourceCredentials>
屬性,剛剛提到需要可以驗證通過除了帳號還需要密碼,但密碼不是使用這組帳號的密碼,而是必須產生一組PAT密碼,要建立PAT密碼可以參考這篇文章[打通自動化雲端部署到地端-安裝VSTS Agent
]
有了PAT密碼就把帳號與密碼資訊放入Nuget.config
中,在<packageSourceCredentials>
內要加一組跟PackageSources的Key Name一樣名稱的tag
並添加Username
和ClearTextPassword
,前者就是登入到AAA.visualstud.com
,後者就是PAT
密碼。完成後,在自動化建置中就可以去抓去對方的Package了
先前在VSTS使用Story Board時候,又用Teams,想說是否可以不要兩邊切換看和討論Story,早期作法就只是把VSTS Story的Link address抓下來,利用Teams的Tab內的Web Site功能建立,不過,這個月更新,整合度就更好了,只需要透過幾個步驟,就可以把兩邊給串起來,且比我之前用link來做好多了
到Teams的Tab功能列表中,找到VSTS的Function,並點選啟動它
點選Function後,就可以開始設定,目前Teams帳號與VSTS帳號並沒有統一,所以,這邊會要你輸入VSTS的登入帳號
登入之後,就可以選訂要連結的VSTS位置,如果你有多個,就只能選擇一個來做綁定
就Teams是以團隊為主,所以,套用到VSTS時候,也必須選定團隊專案和團隊名稱,如果今日有一個團隊是跨多個專案,就必須設定多次了,沒有辦法在一次就可以全部看到的
在Backlog level中,只能選定Features
,Stories
和Epics
三種,設定好之後就按確定,就可以囉
設定完成後,就可以在Teams的Tab上面就會出VSTS Story,也可以透過Teams聊天功能去討論Story了
今天把某台的DB Server中的資料庫還原到另一台DB Server時候,發生這樣的訊息
Cannot execute as the database principal because the principal “dbo” does not exist, this type of principal cannot be impersonated, or you do not have permission
想說平常做備份還原都沒有遇到這問題,怎這次會遇到這樣問題,查了一下還原DB Log,並未發現甚麼錯誤,那樣到底是哪邊出問題
原來是DB Owner不見了,會發生這問題我猜想因該是因為不同台的DB Server內的帳號是不一致,導致還原DB到這台主機時候,找不到原先DB Owner,這時候只要重新給一個DB Owner帳號就可以囉
Json
做為資料傳遞格式傳遞是越來越普遍,就連把SQL也支援JSON資料傳入做Insert
資料用。不過,雖然JSON資料普遍使用,但是,有一個比較大缺點,就是要產生JSON格式的資料並不容易,尤其要多筆資料時候,往往不是缺了[
就是少了甚麼,造成格式錯誤。
尤其最近是把Json資料當作參數傳入SQL中,每每要組合這些資料,就快被搞死,因此,找到一個套件叫做Office with Excel to JSON
,可以讓你把資料透過EXCEL設計好,然後轉成JSON字串,這樣就方便多。
使用這個套件必須是EXCEL 2016或是O365上的EXCEL版本才可以,Office with Excel to JSON
下載點:
https://store.office.com/addinstemplateinstallpage.aspx?rs=en-ZA&assetid=WA104380263
會彈出這個視窗,但是點下去就對
在Excel上要啟用編輯,就可以啟用這個增益集
啟用後的畫面如下
在這邊可以透過上傳EXCEL檔案產生Json,也可以直接在EXCEL表格上設計好數據,然後去產生Json
資料,例如我們設計下面這樣數據格式
然後,在剛剛增益集上直接選擇Row
,然後,按下Go
,下面就會把資料Convert為Json囉
這樣是不是很方便呢?不然,每次要搞定這些資料就讓人頭痛了
]]>要在VSTS建置一個Xamarin開發出來的App,只要在Build Process將相關要建置的Task設定好基本上就可以產生出一個APP,若是要建置出iOS用的APP,就必須要在建置的Agent下一番功夫,例如使用Local agent或是第三方的Agent像是MacinCloud幫忙建置Xamarin專案,用Local agent則還是必須準備一台MAC在上面安裝Build Agent,似乎也不是很方便,第三方服務在付費方式上會有些”麻煩”。
去年就在關注Visual Studio Mobile Center發展(雖然現在依舊是Preview),當時它只能綁定Github或是其他開源的版控平台上面的程式,對於愛用VSTS的人來會是一個遺憾,不過,在2017 Build大會前一個月,Mobile Center宣布可以綁定VSTS上Repositories,讓建置直接透過Mobile Center做建置APP,讓整個CI又更方便了,因此,來把VSTS + Mobile Center串起來吧
使用Mobile Center前,須注意下面幾點事項,這樣才會會讓整個Build
流程順暢一點
Mobile Center Analytics
和 Mobile Center Crashes
Xamarin
套件到最新版本.sln
同一層話說在前頭,因為在VSTS中習慣自己在Build時候,去組合自己想要的Task
流程和設定,但是,若是使用Mobile Center時候,這一部分是完全被省掉,講好聽一點就是省掉設定的麻煩,不好聽就是沒有控制權,若是中間有甚麼意外或是非標準化流程,我們自己也無法做更改。所以,目前建議還是依照自己情境來決定,是否要透過Mobile Center座建置這件事情
進入Mobile Center時候,選擇Add New app
,建立一個新的App,這部分感覺有點類似VSTS的Repositories,一開始會要你設定要產生哪一個平台的App,和你開發App用的語言,這裡就選擇iOS
和Xamarin
,所以說,如果你要產生不同平台的App,就要建立多個APP,這部分還算合理,畢竟不是所有人都是用Xamarin開發,可以跨平台的
建立完成之後,就會進入下面的管理介面
一進入後,會請你在Xamarin Project安裝相關套件,官網說是找到Mobile Center Analytics
和Mobile Center Crashes
這兩個套件,不過,實際上卻是找到是這兩名稱的套件
找到後安裝起來,說明文件上面有分Xamarin
和Xamarin.Form
兩種設定SDK用法,不過,雖然本身是使用Xamarin.Form
開發,但是,還是可以使用Xamarin
方式在Xamarin.ios中加入SDK,而這樣做法只是針對單一平台加入SDK,相關程式碼加入之後,就是開始設定Mobile Center的Build,因為要讓Mobile Center和VSTS的Repositories結合,所以,這裡當然只能選VSTS囉
一般來說會希望你Mobile Center的帳號與登入VSTS帳號的登入帳號是相同,這樣會比較單純,如果是這樣情境,會看到下面資訊,Mobile Center會要VSTS授權給它讀取VSTS的Repositories
綁定之後,就可以看到VSTS所有的Repositories,此時,只要選定你要的Build的Repositorie進行綁定就可以,而且一旦綁定後,就可以看到Repositorie內所有的Branch,在Mobile Center設定Definition方式是選定你要Build的Branch,然後,再做下一步的設定
這邊設定我只能說,真是走極簡風格阿,跟VSTS比較起來,Mobile Center所需要的設定基本都是可辨識的
如果要設定Device Build
就必須上傳該App的Provisioning Profile
和.P12 File
,當然這是要建置iOS APP的憑證,若是沒有上傳這些憑證,只能使用Simulator build
建置APP,而使用此模式,就不能發布到手機上使用
設定好之後或是每次修改設定後,只要一儲存,它就會開始Build了,除非這邊選擇手動觸發,另外,若是選定自動Build,當Code被Check in到VSTS後,也會開始自動建置。這介面上則是列出每次Build的狀況,以及要手動觸發建置的按鈕
每個狀態內,會顯示詳細的build資訊,還有每次Build的時間,不過,這邊有一點就是關於Build時間,Mobile Center背後其實是會啟動一個VM去做建置,所以,如果今天碰到是資源比較缺乏的,就會向下圖一樣,發生非常長的建置時間
當建置完成時候,會出現Download
按鈕,若是建置失敗,只能建置過程的Log
如果建置失敗是不會有Distribute
功能的
建置成功則在下載地方,還可以下載三種類型分別是build
、symbols
和logs
的檔案,其中,Build裡面就是編譯好的ipa
檔案
另外,從下載的Log還可以看得出來,Mobile Center在簡單的背後它設定了那些Task流程,如果想要知道Mobile Center背後怎樣建置你的APP,可以直接看log就可以清楚了解
當你Build好之後,到Distribute
就看到你剛剛Build的APP,還有建置版本號,也可以在這邊下載APP使用
Mobile Center把Build程序簡單化,也讓微軟開發人員不一定要有MAC才可以建置iOS APP,不過,不知道是不是還在Preview,所以,很多機制都尚未完善,要真正導入到企業上用可能還有一段路要走,就拿現在還在運行的HockeyApp來說(未來可能就消失),個人覺得不足地方有幾點:
這一波病毒我想最累因該是企業內部MIS人員,有些朋友公司又有遇到遭情,整個節日就泡湯,這次大部分都是微軟作業系統(聽說MAC也會有)遭殃,但不可避免就是,已經不只是從原本被動模式中毒,就算放著連上網也會中毒,雖然,微軟早在之前就有發布更新,我相信很多人也是沒更新的 XD
根據微軟的安全報告指出,這個勒索軟體是屬於WannaCryptor病毒的其中一隻變種。為了協助Windows用戶共同面對這個大規模
的惡意勒索病毒的威脅,MSRC已公布相關的建議措施,請參閱連結,MSRC blog - Customer Guidance for WannaCrypt Attacks
關於修復RansomWin32WannaCrypt勒索病毒,可以透過微軟提供方式來進行
但這次罕見的微軟會替Phase Out產品也做修補
沒中毒也別太高興,還是快點修補吧,畢竟,變種的已經又來了
]]>常用Application Insighs的人,可以了解Application Insighs能監控的資訊有多強大,不過,在這些資訊中往往會Miss掉一個訊息,就是現在運行的系統版本所得到資訊,跟之前的資訊是否是同一個版本呢?雖然,我們可以在Application Insights內用客製化屬性標記系統版本,但是,不過在統計圖表中卻無法得知這份資訊。在資料的判讀上就會出現問題
因此,為了解決這問題,其實Application Insights是可以主動紀錄每次發布的時間點,並標記在圖表上,尤其對於DevOps
的團隊來說是很重要(責怪人亂發錯誤版本 =.=),可以確認問題點發生原因
要能做到這點,必須使用Application Insights Enterprice版本,主要是必須使用到Application Insights API的功能,如果定價策略設定好之後,就到API 存取
地方,先找到Application Insights API 的ID
有了ID之後,就是建立API Key,選擇建立API 金鑰
有了這兩組資訊,就可以到VSTS去做設定
預設在VSTS並沒有Application Insights for Release的Task,必須到Marketplace下載安裝,從安裝說明看來,因該是TFS也可以使用,不過,這邊還是採用VSTS作範例
下載安裝後,就可以在VSTS的Deploy看到這個Task
把這個Task加入在整個流程最後一個,並填入剛剛取得Application ID & Application Key
完畢後,跑一次Release,再去Application Insights看發生怎樣變化,圖表上方多了戳記的圖案
點開戳記的內容,就可以看到這次Release相關版本資訊
藉由這樣方式,讓整個資訊就會更完整,對於監控Application來說又更方便了
]]>繼上一篇的Azure Container Service初體驗之後,就在想要如何去應用ACS(Azure Container Service的簡稱)的功能,有什麼場景是在對於系統開發或是企業應用方面有幫助的方案,突然,想到其中一個方式,就是建立開發測試的資料庫,在開發時期拿來使用,所以,用ACS建立一個臨時要用的資料庫來做測試用,或許也是一個不錯的選擇,其實,也是可以做為微服務中的資料庫區塊
不過,說這樣多,還是先在ACS中建立一個可外部連線的資料庫吧
如果要使用Docker Swarm模式,就必須先了解這張圖架構圖,這張圖是說明了ACS中的Docker Swarm架構,這是非常重要的,在這之中包含了Master
& Agent
,與網路結構
不過,有一點不解的是這張圖的Master
對應到的NAT
,但是實際上建置起來後,是對應到Load Balance
,也就是說是跟Agent
相同,在Agent的Load Balance
是80
,443
& 8080
的Port有被設定對外開放,如果今日你需要的服務對應的Port沒有被開啟,必須要在Loader Balance控制器做開起設定,就如等下做的SQL Server,必須要去開起1433
,不然,外部系統是無法連線的到內部Container,如果是在Master,所有Port預設都是沒有被開放,必須自己去做設定
輸入docker info
得到的資訊,如下
如果是想要知道Master的Docker Host資訊,輸入docker -H 172.16.0.5 info
就可以得知此Host的資訊,以及此Host對應的Agent IP
如前面所講的,因為是要安裝SQL Server,所以,需要再ACS的Loading Balance控制器設定對外與對內Mapping的Port
在狀態探查
地方加入SQL的1433 Port,通訊協定選擇TCP
再到負戴平衡
的地方,加入SQL的規則
設定內的內容會是下面這樣
以上設定完後,後續等安裝完SQL,就可以透過SSMS連線進去
在Swarm
中,所具備的VM是屬於Linux作業系統,所以,用一般的SQL Server是無法安裝的,必須使用SQL Server for Linux,因此,必須先去Docker Store
下載,因為主要是在於開發使用,在SQL Server for Linux內的一些管理功能可能無法與一般的SQL Server一樣齊全,不過,這倒是影響不大
下載SQL Server for Linux
開始安裝SQL Server for Linux,預設登入帳號是SA
當安裝完畢後,輸入docker -H 172.16.0.5:2375 ps -a
就可以下面資訊,表示服務有起來了,其中,會看到Port的對應關係是10.0.0.5
,表示是位在Agent VM段
docker -H
-H, –host=[unix:///var/run/docker.sock]: tcp://[host:port]來綁定或者 unix://[/path/to/socket] 來使用。在 daemon 模式下綁定的 socket,透過一個或多個 tcp://host:port, unix:///path/to/socket, fd://*
這樣就安裝完畢,看是很簡單,當時要搞定這個,還花了不少時間,最常看到就是Port的資訊是空的,這表示SQL Server並未真正啟動,只是安裝好Container而已,還必須要透過docker run
啟動
設定好Container後,就必須要能進行連線,這邊是透過外部方式連入到ACS內的Container,因為是使用SQL Server,那就用SSMS工具來進行測試吧,要測試前首先要知道ACS對外的FQDN或是IP位置,我們可以去公用IP位址
的服務找到Agent對外IP和Host Name
在資料庫伺服器位置,需輸入tcp:IP or tcp:hostname
,同時,輸入你剛剛安裝SQL Server的Password,如果Container正常啟動,這樣就可以連入進去了,這裡看到名稱剛好會是Container ID
研究Docker時候,總是在想為了來使用Docker技術,我必須架設具有Container機制的Server,或是在自己PC上使用Docker for Windows建立Container,然後才可以使用Docker Image,雖然不複雜,但有時候也覺得不方便,尤其在寫程式時候,會需要做到測試部分,會用到Docker建置相關環境,如果這環境會被地域限制住,感覺又那樣不方便,在Azure上看到一個叫做Azure Container Service
的東西,感覺這東西就像把Container
變成PaaS,可以方便來使用
Azure Container Service是採用標準的Docker容器規範,所以,目前市面上的Docker技術,都是可以被放入這裡面,而在Azure Container Service內有三種模式可以選擇,分別為DC/OS
、Docker Swarm
和Kubernetes
可以依照個人習慣或是喜好來選擇自己想要的模式,後面範例會採用Docker Swarm
模式來做操作,預設Azure中沒有Azure Container Service
,必須自己到Marketplace安裝Azure Container Service服務,到Marketplace搜尋Azure Container Service
,就可以找到此服務
找到之後,就能進行安裝Azure Container Service,這時候可以自己選擇自己想要的Docker模式
進入設定模式,大致上會有四個步驟要進行,首先,要設定你服務的基本配置,如前面所提,這裡選定Swarm
作為我的Docker模式
基本設定完後,就設定服務的位置和連線進入的憑證
後續就是要建立Agent,雖然,感覺是在用Container的PaaS,但實際上背後還是透過VM方式建立Container,所以,這邊必須選定啟用多少agent
以及要使用的VM大小
完成後,會產生這樣的資訊
只要確認無誤後,按下OK,就開始建立了,不過,這樣建立需要一點點時間,建立完畢後,在你剛剛設定的資源群組中會發現被添加了許多的Azure服務
如果要跟Azure Container Service連線,因為先前我們在建立此服務時候,是使用SSH Key,所以,連線時候必須要有可以透過SSH連線的Client軟體,這裡我使用是PuTTY
的軟體進行,因此,這邊開啟Putty
,進行連線設定,在Host Name部分,在containerservice-XXX
內的Master FQDN
可以找到,而Port部分就輸入2200
連線資訊設定完成後,就是設定Auth
登入資訊,這邊提供剛剛在Azure Container Service的SSH私鑰,它會是.PPK
的檔案
最後,就是設定對應的Port資訊,因為,這邊是採用Swarm
,所以,對應的Port都使用2375
都設定完成後就可以開始連線,進去之後輸入docker info
就可以看到關於docker的資訊了
以上方式就可以建置屬於Linux的Container,如果今日你要安裝的Docker Image是屬於Windows Container,就不能使用Swarm模式,必須使用Kubernetes
模式,透過這樣方式,後續要在VSTS進行DevOps中的測試時候,也可以透過這樣方式進行,就不需要額外自行架設VM進行管理,至於,對於企業來說怎樣比較方便,後續還是要有實際案例再來進行比較,使用哪一種方式會是比較簡潔好用
文中有提到關於SSH相關設定,要知道怎樣設定SSH,可以參考這篇
- 建立Azure管理中的SSH金鑰
進入Azure之後,我們可以透過很多工具或是方式去管理我們在Azure上面的資源或是VM,不過,可以發現很多管理上,已經不只是使用帳號密碼做登入驗證,部分身分驗證資訊已經改用SSH
的金鑰來進行驗證,因此,就必須製作屬於SSH
的公鑰與私鑰,當我們在建構服務時候,就需要我們自己產生SSH公鑰資訊填入,做為日後登入資訊的驗證,雖然,這樣方式是相對複雜,但對於安全性又是多一分保障。
製作SSH Key前,必須先確認有這些工具,這樣會幫你比較簡單製作
如果上面工具都安裝好,就可以開始建立SSH金鑰,金鑰有公鑰與私鑰部分,因此,透過Git Bash
來產生私鑰,其指令如下
指令輸入後,就會產生一些資訊需要你填入,當資訊填完也就產生金鑰完畢了,這時候,可以到Windwos的自己帳戶下,看到azure.key
& myazure.pem
這兩個檔案
私鑰檔案內會有-----BEGIN PRIVATE KEY-----
字樣開頭,有了私鑰後,如果也想產生對應的公鑰,可以透過指令產生該檔案的公鑰
公鑰檔案內會有-----BEGIN PUBLIC KEY-----
字樣開頭
透過OpenSSH
的公鑰,格式還不是讓Client端連入驗證的SSH格式,這部分我們需要做轉換,一般Azure SSH公鑰內資訊格式會是如下
PuTTY除了本身是SSH連線工具外,也可以透過他產生這方面格式的SSH公鑰。要讓Putty可以把剛剛透過openSSH建立的私鑰做轉換,首先必須讓PuTTY可以讀到這個檔案,所以,必須把.Key
轉換成_rsa
,這部分還是需要透過OpenSSH
工具指令
這樣就可以產生_rsa
的私鑰
打開PuTTY工具,將剛剛_ras
檔案讀入,成功後就會有下面資訊
在畫面中的Public Key for pasting into OpenSSH....
,可以看到這樣資訊
把這些資訊Copy到Azure有SSH Public Key
的地方放入就可以,如果,未來需要透過PuTTY連線,也要在此視窗中,選擇Save private Key
,儲存後的附檔名為.ppk
,後續必須使用私鑰的Key來跟Azure公鑰Key進行連線認證
透過以上方法就可以產生SSH Key for Azure來使用
]]>Application Insights好處在前面幾篇文章就有提到,尤其對於企業內部眾多的Application來說,Application Insights確實有助於我們從資料面去查詢一些蛛絲馬跡,不過,就整體管理而言,Azure Applcation Insights還是相對薄弱,畢竟,在上面要看一些指標或是報表並不是那樣友善,如果,把Application Insights結合OMS
效果就不一樣,可以透過OMS的Dashboard強化,把監控數據視覺化或是進行分析,因此,就必須透過一些設定將Application Insights和OMS結合起來
想要啟用這功能,首先必須確定你的Application Insights定價,必須啟用Enterprise,才可以讓Application Insights資料整合到OMS內
要啟用OMS,除了在Azure內設定外,也可以到Microsoft Operations Management Suite
網站設定OMS的Workplace
,只是從這邊進去啟用OMS,必須填寫一些資訊,然後,後續OMS要結合Azure資料,還是會透過Azure
的Log Analytics去整合,因此,這邊就是透過Azure來啟動以及建置OMS。
首先,必須找到Log Analytics
設定相關資訊,在這裡其實就等於在建置OMS的工作區,如果是從Microsoft Operations Management Suite
建置的,只需要填入OMS URL進來,如果不是,就取一個新OMS名稱,後續動作Azure都會幫你建置好
當建置完畢後,找到Log Analytics
資源,進入後如下圖,可以看到OMS入口網站
,從這裡就可以進入剛剛Azure幫你建置好的OMS網站
到這一步就做好嗎?不,這邊只是讓Azure幫你建置好OMS工作區而已,還沒把Application Insights資料與OMS串接
進入到OMS介面後,可以選擇自己想要的語系,然後,可以看到方案庫的選項
進入到方案庫後,可以找到Application Insights Connector
,這目前還是屬於preview
版本,然後,將此方案加入到OMS內,此時,可以看到下圖,表示方案已經加入OMS中,但是,還沒有設定連接器要與哪一個Application Insights整合
可以進入Data設定功能,找到Application Insights後,把你想要的Application Insights資源給加入進來,等都設定好之後,必須要等一段時間。讓OMS跟Application Insighs要資料進來
有資料後,就可以看到Dashboard的Application Insights方塊變了
這邊前提是,OMS只會抓取與Application Insights連接時間後的資料,如果之前的資料,並不會顯示被匯入到OMS中
]]>通常在app.config
都是用原本預設的element
,不過,今天為了自己的元件的設定,必須透過客製化的element
作為元件的config,好久沒有研究這部分,所以,研究一下,終於被我弄出來,因此,在這紀錄一下,讓有後續想用的人可以參考
這裡自訂標籤如下,主要標籤分為三層,第一層Token
為最外面標籤,等同於元件要開始讀取此設定的root位置,第二層TokenTarget
,定義為設定值得Group集合,在root
下,可以設定多個不同的Group,第三層target
就是我們要讀得設定參數
而target
每個屬性都代表要給予的參數值,設定好自訂標籤的config,接下來就是要讀取標籤內的資料,Config內只設定這樣還不夠,還必須設定<configSections>
中註冊要讀取這客製化標籤的元件名稱,例如
在這標籤中的name
設定的是自訂標籤的第一層名字也就是Token
,在type的設定格式,前者為namespace
+第一層的Class名稱,後者為namespace
,以這例子,namespace=CustomeXMLConfig,第一層的Class名稱是Token
在C#則是把XML的結構進行拆解,每一層其實都是一個物件,所以,先從最裡面的target
開始,可以訂定如下的Class,使用之前必須先參考System.Configuration
進來
IsRequired
是代表這屬性是為必要,如果是必要,在XML設定中就必須放入值進去,在ConfigurationProperty
內定義要抓取在target
內的屬性標籤名字,所以,這部分可以稱做是Element
再來,就是第二層的TokenTarget
,這裡則稱為Collection
,在這裡必須告知在Collection裡面要抓的element名稱,必須給定是target
其中,Target this[int idx] => (Target)BaseGet(idx)
這一段可以讓你在後續要使用時候,可以列出target
所具有的屬性
最後就是第一層的位置,如果在Collection只有一個TokenTarget
時候,這邊就可以直接設定要讀取Property為TokenTarget
物件,再由TokenTarget
物件帶出target
物件
以上標籤對應的類別定義好之後,就可以去讀取它了,透過GetSection
取得root名稱下的標籤,這邊root名稱為Token
抓出第二層的資訊
然後,再從第二層物件取得最後一層element的屬性
就這樣就可以把我們想要客製化element中的設定檔讀出來了
]]>有了Docker這項技術後,想要把SQL Server
也放入到Docker中,自從SSMS 2016開始,管理工具與DB可以分開安裝後,就沒有在自己電腦安裝DB,但是,有時候在開發專案,並不可能隨時與DB連線,如果手邊沒有SQL Server也很不方便,所以,可以用Docker
建立SQL Server,如果中間被搞壞了,也不用太害怕。此外,或許可以透過這樣方式解決一些實務上遇到SQL測試的另一種問題
此外,這篇實作環境在Windows10
搭配docker for windows
,並啟用Windows Container
要安裝SQL Server,可以到Docker Store找到安裝指令,不過,如果在Docker Store開始找,可能只會找到mssql-server-windows-express
這個Image,此時,不需要太緊張,因為,在這個image
的文件中,有包含到SQL Server for Windows Containers
的資訊,只要點擊它就可以找到mssql-server-windows
,如果不想要找,也可以執行下面指令就可以開始安裝了
如果是第一次,會需要一段時間下載相關性的image,這段時間會比較久一點,之後就不會了,如果下載完畢,就會開始解壓縮,並啟動Containers,之後每次要建立SQL Server Containers,只要重複執行這段指令就可以,另位,預設是透過SQL帳號進行登入,且帳號是用sa
,所以,會透過sa_password
設定sa
密碼
使用docker run
指令後,可以透過docker ps
確認這個Container是否有啟動,若是有啟動成功,就會出現如下圖的資訊
但是,這樣不代表就可以讓SSMS連入,我們還必須要知道這台在Containers內的SQL Server
的IP位置才行,所以,必須使用下面指令查詢SQL Server IP
其中,ff04d07c4b51
是代表你啟動這個Container的ID,用先前的docker ps
就可以找到資訊,有了IP之後,就可以開心用SSMS連入了
如果,今天你忘記sa
密碼,還可以用docker exec
指令加入新的sa
密碼
如果在SSMS中紀錄這次建立的Container的IP,若是移除這個Container後,重新建立時候,就有可能下次就無法登入,要做這測試很簡單,只要你把剛剛建立的Container移除,移除指令如下
然後,再建立一個新的Container,會發現SQL Server網路位置變了,這主要是因為在Windows Container內的網路是透過NAT方式進行對外公開,所以,會導致每次重建後,IP位置會有所變更,想要指定IP給SQL Server,就必須給予這個Container固定IP
這時候會很好奇,為什麼要給172.20.1.10
,主要是Container內是透過NAT
方式轉換IP,預設都會啟動NAT
,又或是可以透過docker network ls
查詢目前網路配置,就可以看到有啟動NAT
了,不過,這樣依舊無法知道NAT
配置IP範圍,所以, 要知道IP的分配範圍
這樣就可以知道了IP範圍,就可以啟動Container時候去指定IP,指定的IP必須在NAT範圍內,不然會發生錯誤
到這一步,還不能高興太早,因為,我們還沒有把資料匯入進去,因此,就必須讓Container能讀取外部資料夾或是檔案,才可以把DB還原到Container的SQL Server裡面。把資料匯入SQL Server有兩種方式,一種就是用掛載mdf
檔案,另一種就是直接匯入備份檔,我比較習慣用匯入備份檔方式進行,所以,必須把正式區DB備份下來,這裡假設是放到E:\DB
下面,然後,我們需要透過資料夾mapping方式,將Container內的資料夾與外部資料夾連結起來,如果有用過VM人大概可以了解這意思。
我們把Container內的c:\DB
對應到E:\DB
,就可以在SQL Server還原DB時候找到這個備份的DB檔案
以上就可以把SQL Server Container建立起來,並匯入我們想要的DB,如果想要一氣呵成的話,也是可以,不用每次要建立Container都花這樣多工,整個指令如下,其中有一點不同的是,在這邊我們指定了Container Name,讓後續操作可以直接使用Container Name而不是用Container ID
第二個步驟主要是透過SqlCmd
做還原DB的動作,從"Restore XXXXX"
這一段就是SQL中還原DB指令,這樣我們就可以很快啟動一個具有資料的SQL Server Container了
如果版控是用VSTS,我們可以在VSTS裡面設定Continuous Build
&Continuous Release
,讓我們的Web專案可以自動化建置到自動化佈署,且佈署到Azure Web App又有Task可用,基本上只需要把相關屬性設定完成,就可以運作,整體來說並會太困難
但是,對於VSTS不熟的人,可能要花一點時間去了解如何設定這些Task,才能讓Continuous Build
&Continuous Release
很順利進行,這樣下來也是需要一點時間,尤其是在Release
部分,還要需要額外設定Service Endpoint
跟Azure做連接。這一點就需要花一點工了。
現在,想要省掉這些步驟,是可以直接在Azure的Web App屬性中,直接使用Continuous Delivery
幫忙去完成VSTS上的CI / CD。在這實作有一個前提要注意的,要用Azure Web App的Continuous Delivery,必須確認你登入Azure的Account,和登入VSTS的Account是否相同,如果,今天你登入Azure和登入VSTS的Account是不相同,就不能用這樣的功能。如果,兩者是相同,就順便在Azure中與VSTS做link吧。做法可以參考這篇從Azure管理Visual Studio Team Services服務
到Web App的Deployment
就可以看到Continuous Delivery
,一開始還沒有設定前,會如上圖所示,由於,這目前還在Preview
階段,所以,部分功能可能有點陽春,不過,我實作後發現,其實基本的設置已經滿足一個.NET的Web了,看到畫面中的Config
,我們按下Config
,就開始設定相關Build & Release了
整個設定流程中,不外乎是Source
,Build
,Test
和Release
循環,這跟在VSTS上的流程是相同的,如果有在VSTS自行設定過的,對這就不會太陌生,如果從未自己設定過這部分流程,這邊也會一步一步指導設定完成,且會比在VSTS上設定簡單許多,很多部分都自動化幫你做完了
前面提到,如果在Azure裡面,你的Visual Studio Team Services account已經與Azure綁定,這邊資訊就會自動帶出來,在VSTS放程式碼的地方叫做Code
,這裡是用Source
,但是意思是相同,裡面有幾個屬性分別如下
設定要Build專案的Framework,目前只有提供ASP.NET
& ASP.NET Core
,其他Web,我想這邊因該沒有辦法直接Build,如果,設定完成後,會自動在VSTS的Build
中,長出這樣的建置流程,而這個流程。基本上就包含所有建置該有的Task了
很多人在build Solution的MS Build Arguments
可能不會進行設定,而這邊會在build Solution
的MS Build Arguments
內設定參數,參數內容主要是把專案發行成Package,Release
則可以透過Web Deploy方式佈署到Azure
雖然,透過這樣方式會幫你在VSTS自動化建置好Build
的Task流程,但是,不代表我們不能自行修改,我們也可以在依照自己的特性,去修改Build
裡面每個Task屬性
或是增加Task,讓整個Build是可以符合本身專案需求。不過,有一點我沒有特別嘗試,就是如果是非.NET專案,例如PHP
專案,我在Azure Web App設定Continuous Delivery,這樣的結果會是如何?
我猜想它依舊會建立相同流程的Task,只是這些流程可能不符合PHP特性,造成Build Fail,自己必須手動在修改這裡面所有Task
,但是,這樣似乎降低在Web App內使用Continuous Delivery
的方便性,畢竟,如果客製化或是手動程度高,這樣想要省工的地方也沒多了,跟自己在VSTS內設定並沒有差太多,而剩下唯一好處就是在Web App內,可以看到VSTS佈署到Web App的相關資訊,不需要再到VSTS內看
設定Test,這邊主要是設定Loading Test
,如果本身沒有做這部分,就可以忽略不需要設定,如果有,這邊只需要開起就可以,另外,在Deploy
部分,也只要打開就可以,會自動幫你在VSTS的Release設定好Deploy Task
其中,連要在Azure App Service Deploy
中的Service Endpoint
都幫你設定好,也會自動幫你跟之前建立的Build
綁定,就可以做到CI & CD
如果要在VSTS做到更細緻化,這樣方式只是幫我們把骨幹建立出來,其餘部分,還是建議到VSTS內去做調整,在管理上也會比較方便點
]]>自從SQL 2014開始,有了In Memory Table
感覺在效能上又多了一道曙光,而到了SQL 2016
這部分又更強化了,可用的SQL語句又增加,雖然In Memory Table
是可以增加效能,但是,如果沒有設定好index反而會造成效益不彰的狀況,這幾天針對這部分進行一些調教,原本以為跟傳統資料表設定index一樣,最後發其實沒有這樣簡單,反而相對複雜,主要是因為在In Memory Table
中的Index多了一個BUCKET_COUNT
需要考量,設定太大,則消耗記憶體,設定太小速度反而更慢。在In Memory Table
中除了叢集索引外,還可以設定非叢集索引,非叢集索引分為兩類
這兩種索引要去設定,還真的會讓人搞昏,所以,藉由一些參考值讓我們至少有一些些依據可以設定,而非盲目的亂設定,尤其是BUCKET_COUNT的大小
如果你設定的索引值,在資料表內的資料重複性相當高的時候,建議採用非叢集索引,反之,該索引所造成的資料重複性小的時候,建議採用雜湊型非叢集索,造成這兩差異主要在於BUCKET_COUNT
的設計,而就官方說法,如果這個索引中你無法很明確設定BUCKET_COUNT
值,就要改用非叢集索引
。若是,確定要設定NONCLUSTERED HASH index時,不知道怎樣設定BUCKET_COUNT
大小時候,可以透過下面語法的值去設定
其中A
&B
就是要設定索引的欄位,由這樣方式可以計算出BUCKET_COUNT值,再由這個值去設定或是比這個值大兩倍去設定都是可以
索引不是一開始建立後就可以不管它,畢竟,當資料流穩定之後,還是必須回頭看看設定的index是否是有確實被用到或是有遺漏的,而在In Memory Table
中,也必須確定倒底是要設定雜湊型還是非雜湊型。所以,要在Review一下
透過上面語法,透過一些指標去判定設定Index是否合宜。
因此,在這兩個值中,如果 avg_chain_length 大於 10,且 empty_bucket_percent 大於 10%,則可能有許多重複的索引鍵值,那麼非叢集索引會較為理想,而不是設定雜湊的非叢集索。當發現empty_bucket_percent過小或是趨近於0,就必須看是否要把BUCKET_COUNT值調大了
https://msdn.microsoft.com/zh-tw/library/dn494956(v=sql.120).aspx.aspx)
]]>在VSTS上面,可以建置Xamarin並將App發佈到HockeyApp上面進行,就可以讓用戶透過HockeyApp下載App,且HockeyApp本身可以讓APP有更新上架後,讓用戶開啟App之後,自動跳出更新App的訊息,這樣好處就可以減少開發人員再去做版本更新的通知功能。HockeyApp其背後的通知更新的機制在於Build
版號要更新,才會通知有下載用戶說有新版本上架,換句話說如果只是單純上架新版的ipa
是沒有用的
要做到版本更新,手動方式就是在Hockapp
介面去調整build number
,不過,這樣似乎有一點麻煩,期望可以這部分自動化,讓ipa
檔上傳後就自動更新版號。因此,必須在VSTS做一些設定即可
要做到自動更新版號,主要需了解HockeyApp版號的控制,由下圖可以知道,版號的取得是來自於plist
檔案中的CFBundleVersion
數值
只要知道它取得資訊地方,基本上在VSTS內要做到修改版號這件事情就簡單多。只要我們在Build
的時候,去修改CFBundleVersion
數值,不就可以了嗎?基於此想法,所以,後續動作就是修改plist
檔案。
預設在VSTS裡面並沒有像MAC有方便更新plist
的工具,所以,需安裝一個套件來幫我們簡化這個步驟,套件名稱為Colin's ALM Corner Build & Release Tools
這工具可以修改東西有這些:
主要是透過Version Assemblies
方式去修改plist
檔案,原本Build Xamarin流程
我們加上一個Version Assemblies
Task,輔助我們修改plist
檔案
在這Task幾個項目要設定
plist
檔案目錄/Info.plist
1.0.0
Build.BuildNumber
,原本因該是$Build.BuildNumber
,但是這邊不可以加上$
Custom Regex
,由我們來定義,符合plist
內的CFBundleVersion格式(?:\d+\.\d+\.)(\d+)
,就直接抄這個,不需要變更這運作機制,其實就是幫忙找到plist
檔案,有設定CFBundleVersion
版本的地方,用$Build.BuildNumber
去Replace原本設定值,另外,在Advanced的Replace Pattern
設定為1.0.0
,且一個重點就是Build Regex Group Index
必須視為0
因此,當每次build完後,就可以增量增加版號,這時候再把build好的ipa檔,傳到HockeyApp就可以
我們都知道在iOS中BundleIdentifier名稱是唯一的,且每個名稱都會帶入一個憑證。一般我們在開發階段可以使用apple develop
的憑證,做開發與發佈。不過,如果要正式發布給用戶安裝,就不能使用開發的憑證,必須到正式發布的憑證,憑證的改變還算簡單,這要在Build Xamarin.iOS
的Task中,去更換P12 Certificate File
,P12 Password
& Provisioning Profile File
對應的資訊就可以
但是,困難的是修改bundle identifier,畢竟在開發階段是不會設定bundle identifier為正式發布的名稱,而是當我們要Release時候,才會進行變更。要做這方面原本以為很困難,不過,發現這資訊也是被綁在plist
檔案內,這時候發現一道曙光。就是如上面更新版號一樣作法去修改plist
檔案
不過,這邊操作起來就簡單許多,因為我們只要Replace開發用的BundleIdentifier
名稱,換成正式發布的名稱就可以,這樣上面會動到的地方有:
BundleIdentifier
的名字,後面可以直接Replace這個名字BundleIdentifier
的名字這樣就可以變更名稱了,以上這些步驟都要在build之前,這樣才會把資訊跟ipa檔一起打包
所以,後續只要透過Branch去拆分開發與正式版本就可以,也就可以達到自動化佈署與切換的功能
]]>因為安裝了Docker for Windows,並透過Docker
指令去抓取Docker Store中的image後發現,在Docker預設是把image放在C:\ProgramData\Dock
路徑下,這樣我C槽如果要放很多種image,有可能就不夠大了,於是想要把Image放到其他地方。這時候可以透過Docker for Windows中的Setting去修改預設路徑
這邊只要加入"graph": "d:\\Docker"
就可以
不過,當我可以把後續相關image檔案下載到新的路徑,但是原生舊的檔案,還是必須要移除掉,不然怎釋放空間呢?這時候,不管我用甚麼指令去移除C:\ProgramData\Dock
內的windowsfilter
目錄,始終顯示我沒有存取權限,因此,就無法移除這個資料夾,剛好這資料夾又放特別多大的檔案,其他檔案大小其實不大,對於釋放空間幫助有限。
我猜這是Docker
指令中的一個bug,要能移除這個資料夾,必須使用docker-ci-zap.exe
指令去刪除此資料,此檔案下載位置
下載後,只要去執行這個執行檔,指令很簡單
這樣就可以徹底把windowsfilter目錄
給刪除掉了,另外,再刪除前,記得要關掉dock for windows,如果還是無法刪除,就重新開機後,再次執行就可以了。如果刪除完畢後會顯示INFO: Zapped successfully
,這樣就完成囉
之前在研討會曾提過,要把自動化程序搞好,善用PowerShell
是不可少的,尤其在企業內部的管理面上,不使用PowerShell
感覺還是卡卡的。在這邊分享如何用PowerShell
去更改檔案名稱以及把過期檔案給刪除
抓取某個資料夾中指定的副檔名,並修改成自己想要的副檔名。透過Get-ChildItem
把該資料夾內的檔案列表抓出來。其中,為了讓整個.ps
更靈活,所以,這邊採用$args[0]
讓外部可以輸入參數進來
|
|
這邊主要抓取該資料夾中副檔名為.dll
的檔案,如果是.dll
就把副檔名變更成.XXX
,其中,使用BaseName
抓取檔名,用Extension
取得副檔名
|
|
使用Rename-Item
修改檔案名稱,其語法如下,FullName
是取得檔名+副檔名
|
|
這樣就可以修改檔案名稱
刪除備份檔案,主要動作就是透過PowerShell
刪除檔案,其做法跟前面修改檔名方式相同,也是必須透過Get-ChildItem
取得該資料夾檔案列表,因為,要判對檔案的最後修改日期是否有過期,所以,必須抓取今日時間,語法如下
有了現在時間後,就是判斷檔案最後修改時間,藉由LastWriteTime
抓取檔案最後修改時間,利用AddDays
可以對$Currentlytime
做時間的運算
若是要刪除30天前的檔案,外部輸入就設定-30
,這樣就可以把-30
值帶入時間運算。然後,再用Remove-Item
把檔案給刪除,這裡需要使用fullName
才可以,完整範例
大部專案都透過VSTS來進行佈署,雖然專案多,但是其實很多時候要設定的參數往往都相同,或是要佈署的路徑可能有80%是一樣,就必須每次都設定一次,或是說要用到一些Command的指令,在不同專案可能要寫一樣,若是,當中有需要變換指令寫法,就必須記住那些專案有用到,然後去改他,這樣非常不方便。再者,有些設定參數可能是具有安全性,不適合寫在Task
中。
基於上面一些理由,就可以透過VSTS的Library來做管理,目前可以在Release
的Definitions引入Library設定的變數群組,Build
的Deginition目前還無法使用變數群組功能
另外,變數群組是依附Project
,無法跨Project
共用
進入Library後,就可以替每個參數設定想要的群組,另外,在安全性部分,可以設定甚麼人可以進來編輯群組資訊
在主要Library上的安全性,是控管可以進入使用Libray的成員。
然後,使用新增群組
,就可以增加變數群組,可以把相關屬性的變數歸納一起,設定變數方式很簡單,就只是Key & Value方式
這時候,我們可以看見,設定安全性的地方,在這邊可以針對這個群組去設定使用人員的角色,做進一步群組安全性的管控
設定完變數群組後,再來就是到Release Definitions中去引用它。
選擇Variable Group
,就可以搜尋在Libray類設定群組。只要把想要納入的變數組加入,就可以看到群組相關設定變數的值
在變數的value
中,是以字串形式呈現,可以讓你設定任何資訊。只要把Variable Group
引入到這個Definitions中,在任何的Task就可以使用它。使用變數語法是$(變數名稱)
藉由這方式進行管理,就會非常方便,當之後有變數要變動時候,就可以集中修改,不忘記有那些沒有變更到
]]>VSTS Packages可以讓我們自訂團隊的Nuget Service,我們可以把自訂元件放到VSTS內,並分享給團隊人使用,一般來說這樣應用問題不太大,不過,用一段時間發現一個問題,就是當要把這個元件從Package Feed移掉時候,並沒有想像中簡單。雖然,介面上有提供Unlist & Delete Package,前者是讓這個版本不顯示在Feed上面,後者則是把這版本元件給刪除,當然同時也不會顯示在Feed上面。
又或者不想透過介面去刪除,也可以透過Nuget指令刪掉。不過,這樣都只能一個一個手動處理,似乎不太方便,介面也不能多選後刪除,在管理上,想讓這個元件完全消失在團隊的Feed列表,就必須刪除這個元件所有版本才可以,這樣可能會按到手痠,因此,這一段就必須自己寫一點點小程式讓它自動刪除所有版本。
下載VSTS上面的Download NuGet + VSTS Credential Provider工具,這壓縮檔裡面會有Nuget.exe
執行檔,曾經試過用nuget.org下載的Nuget.exe
,即使輸入VSTS帳號密碼,依舊會再跟你要一次帳號密碼,呈現無窮迴圈狀態,所以,還是建議使用從這邊下載的Nuget.exe
來用
在執行有發生彈跳一個輸入VSTS彈跳視窗,這邊只要輸入登入VSTS帳號密碼後,就可以了,後面就不需要再輸入
這邊使用PowerShell
指令來撰寫,一般來說要控制VSTS Package上面可使用nuget
和PowerShell
指令,只是後者必須在Visual Studio中的套件管理去下指令。但是,針對刪除套件這件事來說,目前就只能透過Nuget.exe
執行了,而Nuget的刪除指令如下:
-prerelease
,主要是找出beta的版本,因為預設只會找Release版本,
|
|
|
|
因此,把這兩個指令組合起來,用Foreach
讀取所有版本號,放入刪除功能中
在這邊有加入一個echo 是
,這主要是當你刪除時候,會跳出詢問框,問你是否真的要刪除,為了達到自動化目的,所以加入這個指令,如果今天你的OS是英文版,要把是
改成Yes
,後續再加工一下,把XXXXX這個元件名稱當作外部參數輸入,就可以讓ps
檔能自動化執行了。就可以省下很多人工要去刪除套件版本的時間
遇到VSTS佈署到遠端VM後,必須執行一些遠端VM中的Powershell
的情境,執行佈署的Server和遠端VM並不在同一個網域內,所以,無法透過網域的方式去執行遠端VM中的PowerShell
指令。因此,為了要達到這個目的,就必須在遠端VM中安裝WinRM( Windows remote management),這樣才有辦法在Clinet端呼叫遠端VM中的Powersehll
首先,必須在遠端VM安裝Winrm元件,我們才可以透過WinRM和遠端的PowerShell溝通。安裝完畢後,執行啟動PSRemote功能
為了確保WINRM有啟動,可以再執行下面指令確認
若有出現詢問視窗,基本上都選擇Y,完畢後會出現下面資訊
WinRM service is already running on this machine.
WinRM is already set up for remote management on this computer.
遠端VM設定好之後,還要設定呼叫端的TrustedHosts
,不然,會出現連線驗證的問題,所以,可以在呼叫端先查詢TrustedHosts設定,一般來說預設並沒有設定任何Trusted的Hosts
|
|
要設定TrustedHosts其指令如下,其中*,代表任何位置都可以,如果要特定的位置,就把星號改成IP或是HostName
這樣基本雙方環境就設定的差不多,接下來就可以開始撰寫Powershell的Script,這邊把要呼叫遠端VM的Powershell的指令,也寫成一個Script
在呼叫遠端的Powershell指令前,我們需要幾個參數
因為,後續要把這個Powershell Script放到VSTS做自動化佈署用,所以,必須讓密碼能直接被使用,而不是彈跳出輸入密碼的對話框
建立登入VM的憑證
設定Clinet連線到遠端VM的Session,並且要Keep這個Session,讓後續指令可以使用
取得遠端VM要被執行的Powershell檔案的路徑
使用Invoke-Command
來執行呼叫test.ps1
的動作,基本寫法可以這樣
另一種寫法就是把-scriptblock {}
中的值作為一個Local變數來處理,後面再用帶參數的方式填入$filepath
,所以,寫法可以改成下面這樣,這樣寫法的彈性個人覺得會比較好
今日,如果要被執行的Powershell Script,本身有需要外部帶入參數時候,就可以擴充如下,等同執行C:\test\test.ps1 Hello world
意思是相同的
所以,完整的程式碼如下
之前還很高興的把Application Insights與Slack串接起來,可參考Azure Application Insights發Alert訊息到Slack ,但沒多久Microsoft又出了一個Microsoft Teams的協同工具,再加上部分工作已經轉移到Teams,為了整合各項資訊到同一平台上,所以,打算把原本發送到Slack的轉移到到Teams上面,再加上Slack免費版只有10000則訊息上限,Teams這方面則沒有上限,當然就二話不說轉過來囉。
基本上是沒有辦法直接在Application Insights的webhooks
直接與Teams連結,這之間依舊必須透過logic app
和Teams的連接器
做橋接
首先在Teams內建立連接器,把連接器產生的URL
放到logic App
內
2.選擇傳入Webhook
3.給這webhook取個名字,按下確定後,就會產生URL
,把這URL
保留下來,等下開發logic app
會需要用到
這樣在Teams上面設定就算完成了
關於開發Logic App部分,方法跟之前與Slack方式類似,只是這次不需要在Azure上建立連接器,可以先參考這兩篇
這邊會用到Logic App
原因主要是要把Application Insights送出來的Alert格式轉換成O365 Connect可接受的格式,Application Insights送出的格式如下:
而Microsoft Teams是透過Office 365 API Connectors做串聯,所以,必須將上面資訊對應到Office 365 API Connectors訊息格式內,關於這格式說明,可以參考下面這篇
所以,在Logic App部分只需要用到HTTP
就可以,這樣就簡單多
在這Task內的設定如下,其中的URI
就放入連接器的URL,而在body
部分,就串出符合O365訊息格式資訊就可以
開發完成後,只要把Logic App
的URL放入Application Insights Alert的webhooks
裡面就可以,這樣只要有發生錯誤或是相關警示訊息,就會拋到Teams
裡面了,個人覺得這部分開發相對比Slack
簡單一點
Teams除了一般協同工具之用外,針對開發人員來說又多一個好玩的東西,就是可以整合VSTS了,在整合部分目前可以整合就是VSTS發送通知,讓團隊在不管是在Build或是Release時候,都可以即時獲得訊息,尤其是當Release需要被Approve時候,也可以透過通知方式,通知要Approve人來處理
在還沒有Teams以前,我是用Slack去整合VSTS資訊,在Slack應用面上,主要是在Slack的Channel取得Webhook URL放入到VSTS的Service Hooks
現在,在Teams則是透過連接器方式與VSTS的Service Hooks
整合,其方式如下:
Visual Studio Team Services
不知道是否還為Release緣故,需要等待一下子才會跳出設定視窗,如果你的VSTS與Office 365帳號是綁定的,就會自動帶出Visual Studio Team Services帳戶,不然你就要自行用Office 365建立建立VSTS,這邊可以設定的Event Type如下
說真的,可以設定還針對,如果全都要設定也滿累人,而不同的Even Type下面可以調整的選項也會有所不同
設定完成後,儲存起來就可以,然後,再到VSTS的Service Hooks
查看
都會自動幫你建立好相關Link,不需要再手動過來進行設定
為了達到統一資訊平台目的,在Teams目前也可以把VSTS的Story Board整併進來,不過,這部分感覺非常地弱,其實,就像把Board網頁嵌入到Teams,而做法其實就在是Teams增加一個Tab
概念
在裡面就會看到有VSTS,選擇它就對
設定完成後,就可以把Backlog變成Teams其中一個頁籤了,如果要針對這些資訊做討論,可以直接選擇上方的交談按鈕就可以邊看邊交談
個人覺得這一個地方整合互動性並不是很高,純粹就像看黑板資訊討論感覺,雖然,你還是可以直接在上面拖拉Story,但是交談時又不能tag該Story,是有點可惜
]]>在前面的[自動化建立Database版本差異化Script]提到,我們可以透過SQL Compare方式去產生這次要佈署的SQL檔案,不過,在實務上來說,會習慣把產出檔案直接寄送給相關人員去佈署。又或是如果今天是撰寫元件的團隊,要把改版或是修正版的dll
傳送給人員做更新。現在可以當你自動Buil & Release後直接寄送檔案給指定人員
首先到VSTS的Marketplace找到SendMail
這個套件安裝
這個套件可以支援多個收件者,同時,也可以夾帶附檔寄出
套件基本上操作非常簡單,只需簡單幾個設定步驟就可以
目前情境會在當build
後在release
階段將檔案寄出,所以,我們在release
部分加入了SendMail
的Task
這畫面設定中,主要就是設定收件者、寄件者、信件標題和信件內容,如果要有多個收件者,用;
隔開就可以,不過,這邊有一點就是收件者和寄件者的信箱,不會與VSTS內的人員綁定,必須手動去建立相關人員的Email
在信件內容中,也可以用html
語法撰寫成具有html
格式的文件內容,不過,若是這樣,就必須開啟Is HTML Body
的功能
這時候,如果想要Mail能夾帶附檔,就必須勾選Add Attachment
,並在下方填入要抓取檔案的位置,假設我希望將地端要佈署的SQL File寄出,路徑我可以這樣填寫
透過這樣方式,就可以自動化將所需要的檔案寄給有需要的人了
]]>Microsoft Teams其實是跟Office 365人員的功能榜的相當緊密,所以,當你在Teams建立一個小組時候,同時,會在Office 365的人員
建立起群組
Teams是直接和O365同步的唷
如果在群組中下建立自己Channel則就不會再Office 365中的群組有甚麼變化,不過,有一個地方卻是不同,就是在檔案中會區分各個Channel的資料夾出來
這樣代表甚麼涵義呢?,也就是說當你在交談的Channel中有帶有上傳檔案的訊息,檔案自動都會被儲存到這些資料夾中,
看Teams的檔案裡面就有剛剛交談視窗中上傳的檔案
Office 365上也同步了
換句話說就不需要擔心聊天過程中,因為訊息太多找不到之前同事傳給你的檔案在哪邊了,只要到這與Channel名稱相同的資料夾就可以找到所有歷史上傳的檔案,至於空間大小,就取決自己O365上面的給予的空間大小了
如果有這樣功能,我們就可以做到讓檔案上傳,不僅可以直接儲存在雲端,也可以同步到地端自己的電腦,當然,也是可以在自己電腦放入檔案,自然也會同步到Office 365且Microsoft Teams的Files裡面也可以看到唷,這樣就能做到隨處都可以辦公的狀態(不知道這樣是好是壞Orz)
另外,如果在檔案資料夾不僅可以有原先的Channel資料夾外,還可以自行建立資料夾,就可以輕易地做分類
如上面提到Microsoft Teams的檔案可以和O365群組檔案同步,所以,透過這樣模式再把群組檔案與本地端同步,就可以讓檔案的協同合作更方便
1.選擇檔案
到O365的該群組中選擇檔案
2.選擇同步處裡
這邊會出現比較奇異現象,會要求你安裝Ondrive for Bussiness,但是,實際又是用Sharepoint方式進行同步,之後只要選擇你打算把檔案同步到本機哪一個位置就可以
等你同步後,會在本機資料夾看到Sharepoint的標誌
利用這簡單方式,就可以做到跨平台的檔案分享,你只要在本地端有標示Sharepoint
的資料夾存入檔案,就會自動同步到Office 365且Microsoft Teams裡面也可以看到
這時候,想必就會考慮到檔案安全性問題,畢竟,企業很多檔案是具有機密性,雖然這樣檔案分享很方便,但是,方便和安全往往是一體兩面,要解決這問題可以透過兩種方式處理
1.透過Azure RMS在檔案上傳前進行版權控管
2.如果覺得這樣麻煩,就開啟IRM功能
因為Teams的檔案既然是存在O365上面,且群組的檔案管理,它的背後其實也是Office 365的Sharepoint,所以,可以到Office 365將檔案開啟IRM功能
-開啟資訊版權管理
-啟動IRM
這樣就可以做到檔案的安全性控管了
]]>在SQL 2014
之後,有了Memory Table
這功能後,在處理大量資料上的效能相對於以往加快不少,不過,在使用這項功能前必須先建立好該資料庫的Memory Optimize
檔案群組,這個在預設是不會產生的,每次都會忘記要先做這一個步驟,導致建立Memory Table都會發生錯誤
記憶體最佳化檔案群組被建立後,會有幾點限制,須事前要先注意
Maxsize
每個資料庫只能有一個Memory最佳化檔案群組,而該群組必須是被設定為Memory Optimiz
,其中XXXX表示為該資料庫名稱
建立好群組後,就是加入檔案到這個群組中
透過以上兩行指令就可以完成建立了。這樣才可以開始使用Memory Table的功能
]]>在VSTS提供三種預設樣板,分別為Agile、CMMI和Scrum,這三種比較屬於標準型的流程,但是,在許多實務上並非這三種內所包含的欄位或是要觀看的指標是符合現狀,如果,覺得這預設值表可以符合現狀,其實也滿怪的,以Scrum為例,雖然,Scrum有提到一些所謂的”標準”流程或是方式,但是,如果只是一昧認為開發流程要去符合上面Scrum所定義的才算是Scrum,感覺就是倒果為因,反倒是因該讓兩者相輔相成,這時候就可能必須額外增加一些客製化欄位以及在管理者層面所有需要的一些指標。因此,就必須變動原本Process上面的Layout了
在TFS中,如果要針對現有的Process去變動Layout,則必須透過Visual Studio建立好相關Layout後,再佈署到TFS上面進行變更Template,不過,在VSTS中則可以不需要這樣麻煩,直接到到VSTS的管理介面中,可以看到基本的三種類型
這三種類型是無法直接進行修改的,我們想要自訂客製化的Layout,必須先建立自己得Template,而建立時候,也必須決定你要繼承哪一個Process,以下圖來說,我要建立一個以Scrum為基礎的Process
輸入我想要的template Name
建立好後,會呈現如下圖
一旦建立好之後,就可以在自訂的Template中的每個流程內如backlog、Task…等的Layout內加入自己想要的欄位
在每個流程內點擊開來,會有Overview
,Layout
,Fields
,Stauts
和Backlogs
,這五種Stage提供我們去做修改或是設定,
其中,在Status部分,原本預設不會有測試這個流程,如果基於團隊流程,需要額外訂定一個測試流程,在Stauts
這邊也可以加入額外的狀態來符合企業需求
多了test
的流程
專案的狀態中也有test
的狀態了
另外,如果在原本的Layout中有資訊不足,則到你想要的修改的那個項目中的Layout
去修改就可以,不過,有一點就是原本繼承下來的欄位資訊是不可以被刪掉的,但是,如果是自己額外增加,則是可以做刪除
以Task
為例,我們可以在Detail的Group中加入,我們想要的資訊,而要加入的欄位可以是原本系統預設或是額外產生的
如果是採用預設有的欄位,是無法變動其欄位的格式,只有新增欄位才可以選取該欄位的格式,在新增欄位中有三個屬性可以被設定
這邊所謂的Group是這樣呈現的,紅色框就表示是一個Group,而Details
就是這個Group Name
因此,我們就可以自己新增一個欄位並設定該欄位為必填
然後再到實際的Task
觀看,就會發現多一個剛剛加入的欄位名稱,同時,會提示你說該欄位還沒有被加入值,必須填值後才可以儲存
雖然,客製化原本的Process是複雜,但是,操作上其實並不困難,直接在UI就可以達到我們想要的樣板,甚至,連Visual Studio都不需要開啟,而透過能客製化修改,就可以讓開發流程更貼近團隊或是企業現狀,而不會讓工具與管理是無法整合,這樣就失去用工具去節省時間的美意。一個好的工具就是該讓工作行為是能貼近流程與團隊或是組織的實際運作,而不是讓團隊或是組織去為配合所謂”合理正確”的流程或是工具做一些不符合現狀的改變,這樣不僅無法讓原本開發更敏捷,反而會帶來更多災難。
]]>在先前談到使用Application Insights時候,大都是講Backend如何去加入Application Insights功能,不過,現在很多架構上,Backend被用於Web API,操作介面則大部分是以FrontEnd技術為主,這樣就無法使用到Application Insights功能?其實不然,使用前端技術時,同時也可以享用Applciation Insights,且使用起來還相當簡單
前端主要的Application Insights主要是透過javascript去監控我們網頁,利用這方式可以追蹤每個網頁被點擊時間,同時,也可以追蹤網頁的Loading時間,當然,若有發生相關Javascript錯誤,基本上都可以被抓出來,要取得這段程式碼片段,可以進入Azure
你的Application Insights裡面
把這個程式碼片段放入</head>
之前,並在instrumentationKey
填入屬於你自己的Application Insights的Key就可以,基本上這樣就可以開始監控你的前端程式了,像是在C#中,我們可以去增加Application Insights的客製化屬性,或是初始化telemetry,在前端是否可以呢?這當然是沒問題,我們可以透過addTelemetryInitializer
,增加properties
完整寫法
不敢保證所有前端問題Application Insights都一定可以抓到,但是,目前所有網頁行為與錯誤是都可以抓到,這時候就要擔心使用量是否足夠我們使用
如果想要找出網頁的相關性,也是可以用這方式去做,就可以幫忙蒐集到資料了,這算是非常簡單且又不會影響到程式的方式之一呢
]]>因開發Xamarin關係,每次在Build iOS App時,必須透過MAC OS才有辦法達成,如果,平常在辦公室或許還可以透過Remote到MAC電腦,但是,就行動開發者來說,怎可能隨身再攜帶一台電腦?所以,就想辦法在Windows環境中安裝MAC OS,這樣就可以不需要Remote到MAC電腦中,雖然,這樣解決了Build App的困境以及產iOS模擬器的問題,但是,衍伸另一個問題就是,今天要做Notification功能時候,在模擬器上無法呈現這樣功能,必須把App佈署到實體手機才可以,所以,就必須讓VM中的MAC OS能連上手機
在沒有特別設定下,當你把手機與電腦連接起來後,VM中的OS基本上是抓不到你手機的,首先,你必須在VMware的USB設定部分做更改
如果你電腦的USB是支援3.0,預設會是設定3.0
,這邊必須調降為2.0
,另外,如果沒有安裝VMWare Tool
也必須安裝
當你插上手機時候,在VMWare會出現如下圖,多出手機圖示
啟動連接
然後,去iTunes就會看到手機圖示。這樣就表示連接成功囉,當然,啟動xCode
也可以連接到手機,用Visual Studio也可以直接將Xamarin App直接佈署到手機上
這樣就方便多囉
]]>用了一陣子Microsoft Teams
後,把手邊之前跟Slakc
整合的服務,陸續轉移到Teams,因為,Teams目前還在Preview版本,所以,建議使用的人務必將Teams的語系改成英文版,不然會出現一些莫名的問題,例如:建立Meeting時間會永遠出現前後時間錯誤或是無法設定問題
目前比較完整的功能只有在PC版,手機版本雖然可以跨三個平台使用,不過,功能跟PC版本就差異很大,手機版本現有功能只有在交談和檔案分享,也不能做視訊聊天,只能有語音聊天,不過,我認為這些問題之後都可以被解決,畢竟在Skype for business都能做到,這技術上因該問題就不大,後面針對PC版Teams來做分享
說真的設定真的是簡單到不行,基本也沒甚麼可以設定的
Default
, Dark
& Hight Contract
三種其餘就是宣告資訊,及更新Teams功能
檔案功能,主要是列出你在Office 365的OneDrive
跟Teams
中所儲存的檔案
小組成員可以發起會議通知,一旦發起該小組會議通知,就會自動發訊息到該小組的Channel,等到時間到時候,也會再發一次訊息通知,看到該訊息通知,被邀請人只需要點擊訊息中的加入
即可參加會議,當然會議中可以用語音或是視訊
通知功能分為
tag
的訊息都會顯示在這聊天功能和小組功能的差異,我認為一個只是非工作上的需求,一個是工作上的需求差別。由圖中可以看到在聊天功能中,不僅僅只是雙方對話,你還可以加入其他人做群聊,當然也可以用視訊
和語音
進行溝通,另外,tab
上分別是:
到這邊,跟小組功能是差不多的,當然你也可以自己增加Tab
,不過,在聊天中的Tab
是只能增加微軟提供的功能,並不能自己客製化。而目前只有提供Power BI
的功能,另外,現在有一個缺點就是聊天群是不能被刪除,也就是凡事走過必留下痕跡的概念
在聊天中,如果是多人聊天,需要用@
去Tag某位人員,這樣對方才會出現提醒,包含手機也才會收到Push Message,如果沒有加入@
,這樣對方就不會有任何提示訊息
小組就是Teams
最主要的核心功能,這邊小組協同合作方式跟slack
有一點不同,在slack
中,Host Name就是代表小組的意思,每個Channel類似要合作專案項目,所以,在小組裡成員可以看到Channel列表,但是你沒有被受邀到該Channel,你是無法知道該Channel裡面討論的訊息。
Teams
則是先用小組做區分,只要你有被邀請到這小組裡面,該小組的所有Channel你都可以參與討論,但是,你沒有被受邀的小組,你是無法看到該小組的存在,在小組的tab
中可以與Office 365多項服務給綁定,如果不夠,還可以自行客製化Tab
另外,在小組內聊天中有傳遞過任何檔案,都會自動被儲存在Office 365內,可以到File
內找到,如果是不同Channel則會分成不同資料夾,這樣好處在於當後續要回過頭找檔案時候,不會找不到
在聊天時候,有提到要使用@
去提醒對方,在小組聊天也是這樣,不過,如果有重大訊息要一次提請全部人,每個人都要逐一加上@
是很笨的,所以,這邊簡單作法就是@小組名稱
,例如:@MS Teams Test,就可以一次提醒整個小組了
本身每個Channel有提供多種連接器可以與其他雲端服務做串接,當然也可以與VSTS
整合唷,就看自己需要哪些服務,目前這種作法不管在office 365
,Flow
…等微軟出的產品中,用法都大同小異了
對於開發人員來說,就是希望整合相關開發流程或是將相關資訊也放入Teams,做法可以參考下面幾個
本身也提供不少客製化開發模式,很適合讓開發人員惡搞,且又可以把bot framework
整合進來,就可以做出Service Desk
的服務
用Teams另一個好玩的地方,就是聊天用的表情圖示,發現內建的圖示還滿多,不過,目前只有支援PC版本才有,手機版本目前沒有唷
如果只是發發表情圖案有甚麼稀奇,稀奇是竟然可以改動表情內的對話文字,這樣就很特別了
目前Teams還是有很多問題需要被修復,尤其在行動裝置的APP功能明顯不足,Teams往往會被跟Slack比,基本上我認為這兩者產品區隔還是有所不同,一個重點在整合,一個是種輕巧,企業內使用Teams會比Slack適合多,畢竟,在整合企業環境是微軟強項,但是,如果是一般團隊或是新創公司用Slack就已經在協同合作上就足夠,不過,從另一個角度考量,那還需要用SharePoint嗎?早期SharePoint也是在協同合作有其效益,不過,現在都講求小團隊,用SharePoint似乎就有點殺雞用刀。個人覺得如果能在Teams無論在操作或是功能擴充能再加強,未嘗不是一套可以成為企業級的協同工具
]]>在Office 365提供了webhooks
的功能,讓外部系統可以與Office 365進行溝通,因此,只要能開發相容或是本身有相容webhooks
定義,就可以讓外部系統把訊息傳遞到Office 365,因此,了解Office 365 webhook
可接受的傳遞的格式就很重要。由於本身webhooks
是透過Http
協定,所以,在哪一種平台上去開發,就部會是障礙,而格式內容是使用json
方式,這樣操作起來就更容易,在訊息Header
要加上
我們發送一個簡單文字格式,例如:
這樣就可以把訊息傳到O365中,不過,只是單純這樣的訊息似乎也太寒酸,所以,在整個O365的json
訊息中,又可以分為幾大塊模組,讓我們組出想要的訊息內容,只是每個欄位名稱必須符合O365定義,大概可以分成下面主要的幾大塊
利用這些區塊就可以組出我們想要的資訊內容
title算是整個訊息的標題,不過,在不同服務內呈現樣貌會有一點不同,如果只有輸入下面這樣指令是不會Work的,若只想單純文字,只要用text
就可以
還必須加上內容才可以,內容用text
加入,不然是發送不出去
若是要在文字中加入超連結,這是可以,其寫法就跟寫Markdown
的超連結語法相同,用[]()
組合,像是
就可以做到具有超連結的文字
Actions的概念就像是在訊息中間帶入一個button
,可以讓人去點擊,不過,實作上在某些開發編輯器或是服務上會認為這樣語法是有錯誤,主要是因為有用到@context
和@type
這兩個屬性會被視為錯誤的json
格式,導致無法發送,這裡@type
中可以用的選項,可以參考http://schema.org/ViewAction了解有那些可以用
前面使用text
用來描述相關資訊,感覺似乎有一點點少,畢竟,某些時候這樣的資訊是不夠我們使用,因此,便會想要我擴充資訊內容,這時候就可以用Sections
加上Fact
的搭配,Sections
內則使用activityTitle
,activitySubtitle
,和activityText
做摘要性的描述,詳細描述則透過Fact
方式的Key & Value
概念去放入必要的資訊,另外,在使用Sections
時候,必須要先有title
和text
,只有單純sections
是會發生錯誤
這時候,再配上Fact
則可以填入更多的訊息,而Fact
內是搭配name
和value
方式把資訊填入,且可以有多組的Fact
,如果資訊過長,還會自動幫你摺疊訊息
利用webhook
方式再搭配json
資訊格式,看來要與Office 365做整合也就不是那樣困難了
1.https://dev.outlook.com/connectors/reference
2.http://schema.org/ViewAction
做單一系統資料庫專案,透過SQL Project方式開發,基本上並無太大問題,但是,如果在企業內部時候,會遇到一個實務上問題是,當要把某一個系統的資料庫轉換變成SQL Project時候,裡面如果Script有參照到其他資料庫,或是你在A資料庫下寫View
或是Store Procedure
時必須參照到同一台Server不同DB抓資料(如果是Link Server可以參考這解決[點我],這時候在A資料庫專案終究會有問題出現,會發現你的Script出現紅色警告,甚至無法編譯成功。範例是當你在A DB的View用到B DB的Table
最簡單解決方式,當然也是把另一個DB也變成SQL Project,然後做Database Reference,但是,實務上要執行會是有相當難度
所以,必須要有變相的做法來解決這問題,不然,在A資料庫的SQL Project將會無法編譯成功,又或是需要大費周章把有參照到資料庫都變成SQL Project
在自己專案內,建立一個要參照B資料庫的專案檔,在專案檔下面建立要對應的Table
然後,在Table
的欄位中,只要放入你所有需要的欄位就可以
建立好要被參照SQL Project後,就在原來SQL Project去參照它
然後就會跳出相關設定的屬性
Database Name
如果SQL Project專案名稱與實際DB Name不同,這邊要換成實際DB Name,這樣在後續部署上才不會出問題,至於變數名稱就看自己喜好訂定設定完成後,會多出一個Reference,這跟寫C#一樣,是參照不同Assemably的概念
透過變數方式,只要在後面有用到這個DB時候,都可以透過變數取代
所以,就可以把剛剛上面語法變成下面這樣,用[$(RefHR)]
去代替B
,就可以解決無法參照問題
但是,這種做法透過New Schema Comparison
去部署,也是可以的唷
因為,Visual Studio在幫你部署SQL Statement時候,自動把[$(RefHR)]
變數至換成實際的值,所以,透過這樣做法也還是可以能用SQL Project做版控的,只是切記別真的把被參照的DB也部署到Server就好
一般開發系統人員常常遇到當自己系統跑一段時間後,就會被使用者抱怨說系統怎越跑越慢,當然,系統越跑越慢的因素很多,其中一項就是Table該要有的Index卻沒有建立,在系統初期設計上,不是很容易訂定有效的,不過,當系統越來越大時候,透過SQL Server的統計資訊分析後,去找出較為精準的Index反而會簡單一點,且Index不是建立越多越好,不好的Index反而會讓系統效能變低。
因此,在有一次聽過百敬老師的DB效能調教課程後,原來,可以透過T-SQL去找出目前DB中有哪些資料表是缺乏Index的然後,先針對這些Miss Index資訊建立Index,可算是一個比較安全建立Index方式,其語法如下:
|
|
在SQL_Statment欄位中,是顯示要建立Index語法,只要把內容Copy出來就可以建立Index了,省去還要去撰寫建立Index的SQL語法。
個人認為因該先從使用者搜尋次數高的優先找尋要建立Index的資訊,畢竟使用者次數少的,可能只是IT人員自行下條件搜尋,並非是系統再使用的,因此,建立Index後可能效益也不大。然後再找建索引可降低的成本最高和平均使用者可以降低的成本最高的為優先考量,透過這樣簡單分析,去建立比較可靠的Index,比胡亂建立Index有效益多了
]]>