在資安逐步被重視的年代，企業會導入更多資安相關工具，除了本身伺服器或網路層的工具外，近年也針對程式碼進行安全性的掃瞄，目前其中市面上比較熱門的工具之一就是HPE Fortify，他本身可掃描的程式碼種類很多。在開發者端，可以透過Visual Studio的Plug in方式，安裝在Visual Studio，如果你又有Fortify Center的登入權限，便可以從Center將資安團隊設定好的
在先前一篇的[用VSTS建立.Net Core的Package]，建立屬於.Net Core的Nuget Package，其中在Path to csproj or nuspec file(s) to pack是沒有辦法放.nuspec檔案的，但是，原本在.nuspec有一個標籤可以把外部dll包進Package123<files> <file src="lib\XXX.d
我們知道使用VSTS中的Packages Manager可以建立企業或是私有的Nuget Server，在一般.Net Framework下，可以用下面幾個步驟建立Nuget的Package，其中使用到的是MSBuild做編譯，再用Nuget指令打包成Package 不過，今天若是也這樣對.Net Core專案進行封裝，雖然會成功，但是，當在.Net Core專案下載來用時候，就會出現你使用了
在使用VSTS Agent 2.115版本時候，在企業內部使用是沒甚麼問題，不過，最近升級到2.123版後，地端與雲端就失聯，就無法進行連線，到_diag資料查看Log，發現會卡在最後連線驗證地端權限時候，一直發生Timeout然後Agent就發生Exception，導致怎樣都無法與雲端溝通，如果再倒回2.115版又可以連線，真是太神奇 仔細研究一下，因為企業內部必須透過Proxy才能連線，在舊
在前一篇的[在VSTS中建立npm套件管理平台]介紹說可以在VSTS內建立NPM套件平台，因為，VSTS建立的NPM套件管理平台是屬於私人的，所以，會有註冊憑證的動作，不過，這樣做下去之後，卻發生一個問題，如果今日我們是要從原本NPM官網下載套件，就會發生這樣錯誤 其實這錯誤就是因為在.npmrc設定檔中註冊是VSTS NPM套件路徑，而原本NPM平台上套件又不在VSTS，導致會發生失敗，如果不
在之前有介紹透過VSTS的Packages可以自建團隊的Nuget套件管理平台，在Packages中不只是可以建立Nuget套件的管理平台，如果，今日是前端人員或是非.NET人員，想要用npm指令來裝前端套件，VSTS是否可以做npm套件的管理平台呢?答案是可以，VSTS的Packages同時支援Nuget和npm套件管理，就讓我們來建立一個npm packages管理平台吧。 自動化建立npm
就目前微軟以雲端服務為優先情況，VSTS的功能是越來越強大，再加上本身VSTS也可以與地端整合，所以，使用VSTS來做為版控工具是一個不錯選擇，不過，很多人知道好處，但畢竟是雲端服務又會很擔心，如果在公司外部讓公司有心人進入後，把所有程式碼都拿走就慘了，安全性的管理一直想用VSTS的一個。 其實只要透過Azure Conditional Access就可以解決這問題。畢竟，在整個微軟雲端服務中，
自從VSTS有了Packages的功能，可以讓我們自建團隊私有的Nuget後，就習慣把大量可以Re-Use套件放上去，可以讓整個團隊共同使用這些套件。不過，如果給自己團隊是沒有甚麼問題，今天要跨團隊使用呢?就是給在不同專案成員也用你開發的Package，在同一個VSTS URL下，只要去設定Feed權限也就可以，如下圖，在BestFeed下設定給予要讀取此Package的人員那些權限 但是，如果
要在VSTS建置一個Xamarin開發出來的App，只要在Build Process將相關要建置的Task設定好基本上就可以產生出一個APP，若是要建置出iOS用的APP，就必須要在建置的Agent下一番功夫，例如使用Local agent或是第三方的Agent像是MacinCloud幫忙建置Xamarin專案，用Local agent則還是必須準備一台MAC在上面安裝Build Agent，似
在VSTS上面，可以建置Xamarin並將App發佈到HockeyApp上面進行，就可以讓用戶透過HockeyApp下載App，且HockeyApp本身可以讓APP有更新上架後，讓用戶開啟App之後，自動跳出更新App的訊息，這樣好處就可以減少開發人員再去做版本更新的通知功能。HockeyApp其背後的通知更新的機制在於Build版號要更新，才會通知有下載用戶說有新版本上架，換句話說如果只是單純
大部專案都透過VSTS來進行佈署，雖然專案多，但是其實很多時候要設定的參數往往都相同，或是要佈署的路徑可能有80%是一樣，就必須每次都設定一次，或是說要用到一些Command的指令，在不同專案可能要寫一樣，若是，當中有需要變換指令寫法，就必須記住那些專案有用到，然後去改他，這樣非常不方便。再者，有些設定參數可能是具有安全性，不適合寫在Task中。 基於上面一些理由，就可以透過VSTS的Libra
VSTS Packages可以讓我們自訂團隊的Nuget Service，我們可以把自訂元件放到VSTS內，並分享給團隊人使用，一般來說這樣應用問題不太大，不過，用一段時間發現一個問題，就是當要把這個元件從Package Feed移掉時候，並沒有想像中簡單。雖然，介面上有提供Unlist & Delete Package，前者是讓這個版本不顯示在Feed上面，後者則是把這版本元件給刪除，
在前面的[自動化建立Database版本差異化Script]提到，我們可以透過SQL Compare方式去產生這次要佈署的SQL檔案，不過，在實務上來說，會習慣把產出檔案直接寄送給相關人員去佈署。又或是如果今天是撰寫元件的團隊，要把改版或是修正版的dll傳送給人員做更新。現在可以當你自動Buil & Release後直接寄送檔案給指定人員 安裝Send Mail套件 首先到VSTS的Ma
在VSTS提供三種預設樣板，分別為Agile、CMMI和Scrum，這三種比較屬於標準型的流程，但是，在許多實務上並非這三種內所包含的欄位或是要觀看的指標是符合現狀，如果，覺得這預設值表可以符合現狀，其實也滿怪的，以Scrum為例，雖然，Scrum有提到一些所謂的”標準”流程或是方式，但是，如果只是一昧認為開發流程要去符合上面Scrum所定義的才算是Scrum，感覺就是倒果為因，反倒是因該讓兩者
用VSTS去部署Web Site有什麼難的？尤其部署到Azure Web Site更是沒有難度，基本上只要用Azure web app deployment這個Task就可以。但是，部署到地端的IIS裡面，就沒有這樣簡單，尤其是要從雲到地的部署，沒有這樣簡單的原因，不外乎幾點： IIS沒有辦法裝Web deploy套件 地端Agent可能沒有用Web deploy的權限 VSTS並沒有類似Az
透過Azure File Copy的Task，可以把檔案部署到VM或是Blob中，在後者部署上如果只是一般的檔案，基本上並無太大問題，不過今日要是你部署的是js,image,css或是fonts檔案可能就會出現問題 最容易發生的問題就是Web的連結這些Link檔案，雖然不會出現404問題，但是檔案內容也不會有做作用。主要是因為使用這Task部署後，檔案在Blob的Content Type會被設定
一般來說使用VSTS好處是在五人以下的團隊可以免費使用VSTS的功能，且VSTS額外提供幾項免費項目 每個月免費build 240分鐘 每個月免費20000名的虛擬使用者分鐘數 (VUM) 一個免費的build agent 一個免費私人的部署agent相關計價方式可以參考下面詳細價格資訊https://www.visualstudio.com/pricing/visual-studio-tea
基於雲到地部署，除了我們在Application能做到CI&DI的流程，現在連Database也是可以做到這個流程，不過，在實務上不太可能讓開發人員自動化去更新資料庫，尤其在正式環境下更是不可能，畢竟異動資料庫的風險是很大的，所以，一般保險作法可以產生要部署的SQL Script提供給DBA確認後，再做部署的動作 要產生部署的SQL Script不是很容易嗎？是的，不過當你從開發到真正要
當開始使用Visual Studio Online做版控後，雖然很多新功能都可以優先使用以及運用一些雲端的優勢，但是，頭痛地方在於用VSTS做版控的系統，並非都會部署到雲端環境，尤其企業內部的系統往往必須部署在自己的Server內。所以，如何運用VSTS的優勢再結合實務上的需求，這就很重要。 要讓雲端Source可以與地端接觸，必須要安裝Agent，讓Agent與VSTS做溝通，Agent可以在
Markdown撰寫文件的方式，大多被常用在blog撰寫，不過，其實在很多地方應用上，也可以透過這種簡易方式去架設企業KM或是一般產品或是商店的簡易型網站。撇開個人blog的應用外，其他應用上難免都會有需要多人一起協同開發或是撰寫的場境，因此，基於協同合作的模式，還是必須要對這些文件做版本控管。 Markdown只是撰寫內容的模式，還是要給它套上有質感的殼，才能出去見人，所以，選用Hexo框架來