Tag: VSTS

0

用Azure Conditional Access限制公司以外地區不可以連入VSTS

就目前微軟以雲端服務為優先情況,VSTS的功能是越來越強大,再加上本身VSTS也可以與地端整合,所以,使用VSTS來做為版控工具是一個不錯選擇,不過,很多人知道好處,但畢竟是雲端服務又會很擔心,如果在公司外部讓公司有心人進入後,把所有程式碼都拿走就慘了,安全性的管理一直想用VSTS的一個。 其實只要透過Azure Conditional Access就可以解決這問題。畢竟,在整個微軟雲端服務中,

0

自動化建置取得不同VSTS平台內的Packages Manager套件

自從VSTS有了Packages的功能,可以讓我們自建團隊私有的Nuget後,就習慣把大量可以Re-Use套件放上去,可以讓整個團隊共同使用這些套件。不過,如果給自己團隊是沒有甚麼問題,今天要跨團隊使用呢?就是給在不同專案成員也用你開發的Package,在同一個VSTS URL下,只要去設定Feed權限也就可以,如下圖,在BestFeed下設定給予要讀取此Package的人員那些權限 但是,如果

0

VSTS 整合Visual Studio Mobile Center

要在VSTS建置一個Xamarin開發出來的App,只要在Build Process將相關要建置的Task設定好基本上就可以產生出一個APP,若是要建置出iOS用的APP,就必須要在建置的Agent下一番功夫,例如使用Local agent或是第三方的Agent像是MacinCloud幫忙建置Xamarin專案,用Local agent則還是必須準備一台MAC在上面安裝Build Agent,似

0

VSTS佈署Xamarin.iOS到Hockeyapp,自動更新版號和切換BundleIdentifier

在VSTS上面,可以建置Xamarin並將App發佈到HockeyApp上面進行,就可以讓用戶透過HockeyApp下載App,且HockeyApp本身可以讓APP有更新上架後,讓用戶開啟App之後,自動跳出更新App的訊息,這樣好處就可以減少開發人員再去做版本更新的通知功能。HockeyApp其背後的通知更新的機制在於Build版號要更新,才會通知有下載用戶說有新版本上架,換句話說如果只是單純

0

善用VSTS的Library功能管理參數

大部專案都透過VSTS來進行佈署,雖然專案多,但是其實很多時候要設定的參數往往都相同,或是要佈署的路徑可能有80%是一樣,就必須每次都設定一次,或是說要用到一些Command的指令,在不同專案可能要寫一樣,若是,當中有需要變換指令寫法,就必須記住那些專案有用到,然後去改他,這樣非常不方便。再者,有些設定參數可能是具有安全性,不適合寫在Task中。 基於上面一些理由,就可以透過VSTS的Libra

0

快速刪除VSTS Package某一個元件所有的版本

VSTS Packages可以讓我們自訂團隊的Nuget Service,我們可以把自訂元件放到VSTS內,並分享給團隊人使用,一般來說這樣應用問題不太大,不過,用一段時間發現一個問題,就是當要把這個元件從Package Feed移掉時候,並沒有想像中簡單。雖然,介面上有提供Unlist & Delete Package,前者是讓這個版本不顯示在Feed上面,後者則是把這版本元件給刪除,

0

VSTS 能夾帶附檔的Send Mail套件

在前面的[自動化建立Database版本差異化Script]提到,我們可以透過SQL Compare方式去產生這次要佈署的SQL檔案,不過,在實務上來說,會習慣把產出檔案直接寄送給相關人員去佈署。又或是如果今天是撰寫元件的團隊,要把改版或是修正版的dll傳送給人員做更新。現在可以當你自動Buil & Release後直接寄送檔案給指定人員 安裝Send Mail套件 首先到VSTS的Ma

0

VSTS也可以在Process Template Layout加入客製化欄位

在VSTS提供三種預設樣板,分別為Agile、CMMI和Scrum,這三種比較屬於標準型的流程,但是,在許多實務上並非這三種內所包含的欄位或是要觀看的指標是符合現狀,如果,覺得這預設值表可以符合現狀,其實也滿怪的,以Scrum為例,雖然,Scrum有提到一些所謂的”標準”流程或是方式,但是,如果只是一昧認為開發流程要去符合上面Scrum所定義的才算是Scrum,感覺就是倒果為因,反倒是因該讓兩者

0

打通自動化雲端部署到地端-VSTS用MSBuild產生部署Web Site所需要的Files

用VSTS去部署Web Site有什麼難的?尤其部署到Azure Web Site更是沒有難度,基本上只要用Azure web app deployment這個Task就可以。但是,部署到地端的IIS裡面,就沒有這樣簡單,尤其是要從雲到地的部署,沒有這樣簡單的原因,不外乎幾點: IIS沒有辦法裝Web deploy套件 地端Agent可能沒有用Web deploy的權限 VSTS並沒有類似Az

0

解決VSTS內Azure File Copy的Content Type問題

透過Azure File Copy的Task,可以把檔案部署到VM或是Blob中,在後者部署上如果只是一般的檔案,基本上並無太大問題,不過今日要是你部署的是js,image,css或是fonts檔案可能就會出現問題 最容易發生的問題就是Web的連結這些Link檔案,雖然不會出現404問題,但是檔案內容也不會有做作用。主要是因為使用這Task部署後,檔案在Blob的Content Type會被設定

0

如何替VSTS增加User Account , Agents和Build時數

一般來說使用VSTS好處是在五人以下的團隊可以免費使用VSTS的功能,且VSTS額外提供幾項免費項目 每個月免費build 240分鐘 每個月免費20000名的虛擬使用者分鐘數 (VUM) 一個免費的build agent 一個免費私人的部署agent相關計價方式可以參考下面詳細價格資訊https://www.visualstudio.com/pricing/visual-studio-tea

0

打通自動化雲端部署到地端-自動化建立Database版本差異化Script

基於雲到地部署,除了我們在Application能做到CI&DI的流程,現在連Database也是可以做到這個流程,不過,在實務上不太可能讓開發人員自動化去更新資料庫,尤其在正式環境下更是不可能,畢竟異動資料庫的風險是很大的,所以,一般保險作法可以產生要部署的SQL Script提供給DBA確認後,再做部署的動作 要產生部署的SQL Script不是很容易嗎?是的,不過當你從開發到真正要

0

打通自動化雲端部署到地端-安裝VSTS Agent

當開始使用Visual Studio Online做版控後,雖然很多新功能都可以優先使用以及運用一些雲端的優勢,但是,頭痛地方在於用VSTS做版控的系統,並非都會部署到雲端環境,尤其企業內部的系統往往必須部署在自己的Server內。所以,如何運用VSTS的優勢再結合實務上的需求,這就很重要。 要讓雲端Source可以與地端接觸,必須要安裝Agent,讓Agent與VSTS做溝通,Agent可以在

0

Hexo+VSTS+Azure Web app 的持續整合與交付

Markdown撰寫文件的方式,大多被常用在blog撰寫,不過,其實在很多地方應用上,也可以透過這種簡易方式去架設企業KM或是一般產品或是商店的簡易型網站。撇開個人blog的應用外,其他應用上難免都會有需要多人一起協同開發或是撰寫的場境,因此,基於協同合作的模式,還是必須要對這些文件做版本控管。 Markdown只是撰寫內容的模式,還是要給它套上有質感的殼,才能出去見人,所以,選用Hexo框架來