發表文章

目前顯示的是 3月, 2017的文章

the DevOps journey (9) – 在TFS/VSTS中使用Git版控

圖片
接著,我們來看如何在TFS/VSTS中使用Git形式的版控。 同樣的,請先建立一個支援Git版控的Team Project,與TFVC版控的Team Project不同,建立好該專案之後首先納入眼簾的是底下的畫面: 你可以透過SSH連線的方式來連接,也可以點選上圖(2)的地方,產生連線所需的帳號密碼。 如果你用開發工具是Visual Studio,那你可以很大方的按下上圖(3)的位置,即可直接Clone該專案並且設定Mapping的用戶端資料夾位置,如果你用的開發工具並非Visual Studio,但也是知名的開發工具,則可點上圖(4)的下拉清單,看看是否也支援直接Clone: 從VS2017連接TFS/VSTS上的Git版控伺服器 當然,你也可以用類似我們開啟TFVC版控專案的方式,直接從Visual Studio當中建立連線,請注意一樣是選擇Connect to Project,在出現的畫面中找到要連結的專案與repository: 接著,成功的連上之後,在Team Explorer中一樣會出現讓我們選擇用戶端Mapping版控檔案的儲存位置,也就是你要把雲端的原始程式碼Clone到用戶端的哪個資料夾。 請選定資料夾後(下圖A),按下Clone鈕即可: 如果伺服器端已經有其它開發人員先前push上去的程式碼,會被一起下載下來,但由於我們是建立一個新的專案,因此目前還沒有任何檔案被Clone下來。 我們可以點選下圖A的New,建立一個新專案: 你會發現預設的資料夾,應該也是先前我們Clone時設定的資料夾,你可以直接按下OK,建立該專案。完成後,切換到Solutions Explorer視窗後,會看到類似底下這樣的畫面,這時請留意,和TFVC版控有些許不同: 你會發現,在上圖A的位置,標示出了有12個檔案已變更(或新增),你可以點選該數字,會出現Commit程式碼的畫面。 將程式碼Commit並Push到伺服器端 你會發現,在下圖A的地方,和TFVC版控類似,也會讓你輸入此次Commit的Comment,而B的地方有三個選項,分別是Commit All, Commit All & Push, Commit All & Sync: 所謂的Commit,和TFVC的Check-in不同,Commit並

the DevOps journey (8) – 使用TFVC程式碼版控

圖片
我們先看採用TFVC的部分,請先建立一個以TFVC為版控的Team Project: 當你在VSTS/TFS中把專案建立好之後,首要工作就是從用戶端的Visual Studio連上伺服器,請開啟Visual Studio,找出Team Explorer視窗: 在Team Explorer視窗中,最上方(上圖1)的位置,有一個連線按鈕,點選後接著會出現Manage Connections選項,理論上會有兩個,一個是上圖2的『Connect to Project』,另一個是『Connect to Github』。 上面的Project指的就是VSTS/TFS的TFVC或Git Repository,而Connect to Github指的當然就是網路上那個Guthub。 請注意,不管你在team project建立時,選擇的是TFVC或Git版控,都是點選上圖2那個『Connect to Project』 接著會出現底下這樣的畫面,這是VS2017的UI,你會看到所有你的登入帳號可以連上的TFS Server或VSTS站台: 留意上圖,其中(1)的部分是你的連線帳號,由於該帳號可以連上我建立於區域網路的TFS以及internet上的VSTS,因此上圖(2)和(3)分別就是TFS伺服器以及VSTS站台,而展開的項目當然就是Team Project(上圖6),而(4)和(5)所指的分別是位於VSTS站台上的Team Project裡面的Git版控的repository和TFVC repository。 新版VS2017的連線UI設計的很完整,一次把所有需要連線的對象全列了出來,你只需要點選後,按下Connect鈕即可。 Mapping工作區並下載檔案 當你連上了伺服器端之後,會看到類似下圖的畫面,由於範例是剛建立的Team Project,因此下圖中你會看到還沒有其他開發人員先前已經簽入(Check-in)的source code,只有一個預設的資料夾: 由於第一次連上,你必須先Mapping你的Workspace,你會發現上圖(2)的地方,可以設定你的用戶端工作區位置,一但設定,未來該位置就可與伺服器端做同步,設定後按下『Map & Get』,如果先前有其它開發人員已經簽入程式碼,也會被下載下來。 你也可以點選下圖(1)的地方,也可

the DevOps journey (7) – 你的source code還沒上版控嗎?

圖片
原始程式碼對於軟體公司來說是一種資產,Source Code被納入版控不足為奇(沒有才奇怪),但我常常看到企業內的MIS/IT,認為自己開發的專案只是小型專案,或是開發人員只有『一個』,所以要控管什麼版本呢? 因為一切都在自己的腦袋裡啊。 不,千萬別這樣想。 在這個時代,任何專案,那怕從頭到尾都只是一個人開發的,都應該要簽入到版控系統當中。不管是任何一種專案,不管是因為任何目的原因所撰寫的,不管它能夠在企業中活多長,只要有需求,有程式碼,需要維護,就一律必須納入版控。 如果非要我在兩者中選擇其一,我會說,軟體專案成敗的關鍵常常不在開發,而在維護。在這個時代,幾乎沒有寫完程式碼後可以不用維護的專案,也沒有你可以大聲喊『Close!』結案之後就再也不管它的程式碼,幾乎所有的Projects都會持續衍生、修改Bugs、調整需求。如今想要很快的生出一個可以動的網站太容易了,但隨著需求的變更,對程式碼的修改常常才是軟體開發真正內涵的開始。況且廣義的說,專案還沒有交付前所作的任何需求變更或修改,也都得算是維護的一部分。 如果你敢在寫好程式碼編譯成.dll之後,立馬把source code丟掉,我就承認這世界上有不需要維護的專案,但我們從來不敢這麼做,對吧? 不管一個專案再混亂、或是你開發的是根本是拋棄式的應用程式(用一次就不會再用),原始程式碼都至少還要留上一段時間,甚至永久保存下去。 而如今這些需要無限期永久保存的程式碼,慢慢的逐漸移動到了雲端環境上,我們到了一個版控雲端化的時代。當然,保存原始程式碼不是為了安全感,TFS/VSTS的版控可以幫助我們解決那些實質問題? 版本控管的價值 有沒有發生過底下這些事情? 某位團隊中的程式設計師改了某一個bug,結果另一個原本好的功能卻壞掉了? 沒改過的地方怎麼會錯呢? 客戶突然告訴你,你剛才改好的某個功能他不要了,他要回到上上上個版本的那個狀態! 團隊成員結婚去度蜜月了,但不幸的是,他手上負責的某個案子,客戶發現了一個安全性的漏洞,嚴厲指責這估計是他結婚前一個月的某次修改時造成的,但...那段程式碼在哪呢? 你同時是三個軟體開發專案、兩個維護案的程式碼設計師,面對客戶和專案經理天馬行空的需求,你的大腦常常必須在2-3個案子之間切換,剛剛才改完維護案的bug,下午要開發另一個專案的新功能,但是…昨天…我程式碼寫到

the DevOps journey (6) - 安排與設定專案的迭代

圖片
當專案啟動後,我們會用VSTS來管理專案中的每一個Features/work items,以及source code。 Source code管理的部分我猜大多數的開發人員比較熟悉,畢竟版控這幾乎是開發人員吃飯的工具,我們就暫且先不說了,主要是因為有用過TFS的開發人員肯定知道怎麼用,而VSTS在版控上的操作完全相同,因此不需贅言。 但由於最近幾次的改版之後,VSTS除了過去支援的TFVC,現在還支援GIT,因此似乎也必須稍微整理一下,如果以後有機會我再補齊,讀者可參考後面的篇幅。 因此,這一個部份我們先focus在work items在iterations中的處理。 回顧先前所提過的,敏捷開發的核心精神之一,就是把開發周期縮短成多個iterations,在Scrum中我們叫做Sprint。(其實想一想,我覺得不管是不是敏捷開發,只是要面對需求快速變更的近代軟體開發專案,都應該盡可能的切分出iterations) 前面曾經說過,這個Sprint可能是 1-4 周,一般來說我自己喜歡用2周。但這個長度完全取決於你希望專案有多透明,衝刺有多密集。 經驗上來說,2周是一個比較舒服愉快的周期,1周多半意味著Team Members和PO/PO, Stakeholders都得要上緊發條;但 3 or 4周我自己覺得有些鬆散了,比較適合人數比較多、或是整個專案時程預估會超過一年以上的開發團隊,或是長期抗戰永無休止日的軟體產品開發團隊。 要在VSTS當中設置iterations相當容易,你會發現當一個新的專案被建立起來之後,就已經建立好了預設的迭代了,只是系統還沒有幫你安上迭代的時間日期: 當你點選專案主選單的『Work』選項(上圖1)之後,會發現初始建立的專案已經有預設的Sprint1-6(上圖2)。但每一個Sprint的日期則還沒設定(上圖3),而中央黃色區域的地方則是輸入工作項目的位置(上圖5)。 這別請特別留意,上面的『Sprint 1』這個名稱,是依照你選的流程版型Scrum而定,如果一開始你選的是Agile或CMMI,則Sprint會變成Iteration 原則上每一個迭代(Sprint)的週期應該一樣長 , 當專案建立好之後,你其實可以直接修改預設已經存在的迭代名稱和日期區間: 動作很簡單,請依照上圖的操作順序,最後點選(1)的Set

the DevOps journey (5) - 在VSTS站台與專案中添加成員

圖片
前面 我們看過了如何免費申請VSTS站台與建立專案,接著,我們要在專案中添加成員。專案的成員在VSTS當中都是以Microsoft Account來添加的(如果你有Azure AD,也可以是AAD帳號),在新增帳號前,有幾件事情你應該要知道… VSTS的帳號類型有三種,分為: basic(五人以內免費), MSDN Subscriber(視為已付費), Stakeholders(免費) 由於未來我們的Source code control、Work Items整個都在VSTS當中,包含bug tracking、document、unit test...等全都透過VSTS。因此,理論上所有與開發相關的人員,都必須添加進去成為專案的Member,我們可以提供這些團隊成員basic類型的帳號。Basic類型的帳號五人以內免費,如果超過五人,則需要從Azure Portal購買額外的帳號權限。 如果你的團隊成員當中,已經被指派(或購買)有MSDN訂閱,則該Microsoft Account可以選用MSDN Subscriber權限,毋須占用免費的basic權限。 如果並非Developer,且只是要觀看Work Items(像是Features, Backlogs, Tasks…等)的Stakeholders,也可以加入VSTS Members,毋須占用basic帳號,可選擇免費的Stakeholder身分即可。 要新增用戶,你可以先點選VSTS左上角畫面的Logo(下圖1),會進入到該站台 (Collection)的管理畫面,請找到Users(下圖2): 進入該畫面之後,你可以點選(1)的部分,會出現讓你輸入email增加用戶的介面,請於(2)的地方輸入該用戶的email(必須是Microsoft Account),Access Level請參考前面的說明,選擇三者其中之一: 請注意,我們現在新增的是整個站台(Team Site)的用戶使用權限,待會這裡新增完成之後,接著才針對專案(Team Project)來新增用戶權限。 順帶一提,也因此,VSTS的五個免費basic用戶,指的是站台,而非專案,請留意。 請依照底下的操作順序,即可把成員加入站台: 添加專案成員 當用戶被成功的加入站台之後,接著我們就可以針對專案來添加成員。 一般來說,

the DevOps journey - 直接import Github上的Project到VSTS

圖片
我相信你一定有用Github,其實我很少用,但不知道從什麼時候開始,開發人員沒有Github帳號好像是很詭異的事情。 直到去年,我才開始比較多的把一些範例放到Github上面,當然主要原因是分享,也作為blog和書籍範例的儲存位置。 如果你有在用,你一定知道,Guthub上的專案是open的,除非你付費,否則你的原始程式碼只能選擇公開(Public)的模式。 然而,某些比較敏感的專案,你還是會希望能夠以Private的方式做版控,如果是團隊開發,那你一定得用Private的方式來管理你的原始程式碼。 從好一陣子以前(忘了有多久),提供團隊開發(五人以下)免費使用的VSTS,就徹頭徹尾的支援了Git版控機制,也因此,你可以直接申請一個VSTS站台,在上面建立Private的專案,並且讓多位程式設計師一起透過VSTS上提供的Git repository進行版控。你毋須自行架立Git伺服器,和所有的Git服務一樣,他也提供SSH或簡單的帳號密碼身分驗證,如果你還不知道,可以參考 這篇 建立一個VSTS站台試試看: 當你在VSTS上建立好一個Team Project之後,立馬會看到一個很有趣的功能,VSTS的Git版控可以直接從某一個現有的Github Repository把source code給Import過來(下圖),你建立好自己的VSTS Team Project之後可以試試看,請不用客氣,直接用我分享在Github上的範例即可: https://github.com/isdaviddong/isRockWebFxBasicSample (順帶一提,如果你不知道上面這個專案在幹嘛,可以參考 這邊 ) 按下Import鈕之後,會跑一下底下這個畫面: 完成之後,該repository上的source code就都複製到VSTS的Team Project中囉: 從此之後,你就享有自己團隊非公開的Git repository,五人以下免費,空間無限,非常方便吧。 基本上,目前我只有需要刻意公開的專案,才會使用Github,除此以外全部都在VSTS上了,你也要試試看嗎? 同場加映 ------------------------------ 本系列文章索引位於 http://studyhost.blogspot.tw/2017/02/the-devops