建立 Visual Studio Team Service 的 Build Process

Build: 主要目的在於整合,編譯程式,並且準備好進行部署

Release: 必須要知道預計部屬的環境,例如:TestStage & Production

基本概念在於要分開 Build & Release,也就是 Compile 只需要一次,就可以部屬到不同的地方,這樣才可以讓程式的變動通知到不同的地方(不然往往就會有測試環境是版本一,但QA環境是版本二,造成程式不一致,很難知道測試正確或者錯誤所反應的程式到底是否一致)。

以下用 asp.net core target .net core 2.0 為範例(使用不同的環境需要不同的設定),建立 Build Definition 方式如下:

  • 選擇 ASP.NET Core Template:如果專案是 .net Core Console 同樣可以使用這個 Template

 

 

  • 指定 Hosted VS2017 (代表可以使用 VS2017 的開發環境進行編譯)

  • 指定 .Net Core Version,請注意一定要指定 2.0,因為預設是 1.0

上圖要注意 Use Package from this VSTS feed,因為我們有使用 VSTS 當作內部的 nuget source,因此這裡也要指定

目前 .net 2.0 會在左方產生『previewtag,因此要注意上圖的 Restore, Build, Test & Publish 都要是 2.0

  • 設定 publish 的對應環境:使用 dotnet core publish 要指定環境
  • 設定 Trigger:主要目的在於讓原始碼的更新可以直接排成,不需要手動排入 QUEUE 中。設定方式很簡單,在 Trigger 中指定方式即可:

指定當 Source code Commit 時候,就自動進行排程。

 

  • 下載已經 publish 的檔案:透過 Build 可以在 Artifact 頁簽直接下載編譯完成的檔案:

 

使用 Visual Studio Team Service 的 TEST MANAGER

測試是我們每一個 BACKLOG 都必須要完成的任務,VSTS 已經內建這樣的服務:

此項服務依據註冊等級有區分不同的權限,目前使用最基本的授權(BASIC ACCESS LEVEL)無法在此新增 TEST PLAN(更高一階的 VISUAL STUDIO / MSDN ENTERPISE授權就有),因此只能由 TASK / BACKLOG 新增測試任務:

如下(下圖範例只有一個測試,但實際上可以有很多個):

一旦加入後,TEST 頁面中就會顯示此任務與對應的 TEST ACTION

透過 CRHOME EXTENSION 執行測試

MICROSOFT 提供 CRHOME TEST AND FEEDBACK EXTENSION 可以方便使用者依據設定的 actions 執行測試,這些測試可以透過影片錄製記錄測試過程與結果,若發現問題也可以直接截圖紀錄 Bug。

作法如下:

  • 首先,使用者 Chrome 開啟 VSTS 並且點選 Package Extension

開啟下方的 Chome install,就可以在 Chrome 上面安裝 Test & Feedback 套件:

點選『設定』,然後輸入要連結到 VSTS 的網址,就可以看到對應的專案,點選要測試的專案 TEAM 如下:

 

  • 點選 Test Action,在更多的選項中,點選 『Run test』

就會開啟新的 Chrome 頁面,顯示要執行這個測試的相關步驟:

可以點選右上角的『錄製』,就會開始記錄操作畫面:

然後開啟 Chrome 頁簽,輸入測試網址開始執行測試,就會自動錄製,可以選擇錄製整個桌面,或者特定視窗(一般就是crhome的視窗)。

這時候就可以依據步驟說明,點選是否已經通過測試(下圖綠色勾勾):

當完成所有的測試,就可以點選上圖左上方的『Save and close』就會將結果記錄到 VSTS中。可以看到顯示『Passed』代表這個測試已經完成。

可以點選 View Test Result,Details 就會有顯示 webm 的影片,可以播放觀看。

使用 Chrome Extension 的最重要是可以直接建立 Bug;步驟一樣點選 Run Test,但在特定步驟可以點選『失敗』:

上面的 COMMENT 就是讓我們輸入錯誤內容,然後點選右上方的『Capture Screen Shot』,會出現讓我們選擇要截圖的位置:

如果使用 IE,必須要選擇『整個畫面』,因為IE無法呈現在『應用程式視窗』中。選擇截圖很簡單,就只需要拖拉範圍區間即可:

拖拉完畢後,就會出現標示畫面(下方有框線、標示與文字可以輸入相關的描述):

輸入想要的訊息後,點選下方的勾勾『V』救代表存檔。

存檔完畢後,會自動回存到原來的 Bug Comment 中:

這時候請點選『Create bug』讓系統自動產生 Bug Task,唯一需要輸入的就是 Bug Title,其他相關資訊都會自動幫我們產生(包含剛剛的圖片),按下『Save and Close』後就會自動產生:

我們可以看到 Test plan 顯示這個測試是錯誤的:

並且也可以 Backlog Item 中,看到建立的錯誤:

 

當然,也可以不用這麼麻煩,可以直接 TEST PLAN 點選最下方的『Passed』 or 『Failed』,直接說明這個測試範例是否通過或者失敗:

 

使用 Exploratory Test

雖然建議在每一個 Backlog 都要事先規劃測試計畫,但如果沒有規劃 Test Plan 也可以進行測試記錄。

主要方式就是在 Backlog 點選:『Do Exploratory testing』

然後點選CHROME 右上角 Test & Feedback 圖示,就會出現下圖可以點選進行、錄影與截圖,同樣可以錄製後,會自動關連到 Backlog Item 方便後續追蹤與紀錄。

可以先選擇截圖之後,在點選記錄 Bug 可以輸入錯誤的描述與畫面貼圖:

 

建立一個 SCRUM Team:第四週

本週主要重點:

練習 BACKLOG

針對 BACKLOG 的 EFFORT(STORY POINT分數)評價,是一個很重要的目標,因為有足夠多的數據與經驗,才能對未來的速度產生足夠的信心。

因此,本週將會對使用者的維護需求,開始進行修改描述。每一個描述必須要能夠有充分的內容,可以讓團隊每一個成員給定 STORY POINT 分數。也因為如此,時間上不允許對每一個都進行描述。因此步驟將會:

1. 先將所有的 NEW 的 BACKLOG 給定優先序(由上而下)

2. 將NEW 最上方的幾個(預設5個)移到 APPROVED,然後針對這幾個進行 STROY POINT 的給分。

持續進行此項動作,將會是未來每一週的例行性任務

說明如何執行 VSTS TEST MANAGER

由於測試是我們每一個 BACKLOG 都必須要完成的任務,VSTS 已經內建這樣的服務:

此項服務依據註冊等級有區分不同的權限,目前使用最基本的授權(BASIC ACCESS LEVEL)無法在此新增 TEST PLAN(更高一階的 VISUAL STUDIO / MSDN ENTERPISE授權就有),因此只能由 TASK / BACKLOG 新增測試任務:

如下(下圖只有一個測試,但實際上可以有很多個):

一旦加入後,TEST 頁面中就會顯示此任務與對應的 TEST ACTION

有關如何使用 TEST MANAGER 記錄測試的正確性,請參閱:使用 VSTS TEST MANAGER

建立一個 SCRUM Team:第三週

這過去這一個星期,我們開始進行了實際操作。將目前所有的工作區分,依據專案開發與維護成兩個區塊:

系統維護

目前維護的系統,仍有需多修改需求單,若要單獨將這些需求都納入 SCRUM 方式管理,很明顯的不符合效益;因此使用 KANBAN 方式,直接將所有的需求、BUG利用 BACKLOG 紀錄,並且簡單的提供 ARRPOVE – COMMIT -DONE 三個步驟。

基本上不使用 SPRINT,因為大部分的工作都只需要指派的成員 COMMIT 之後就可以完成 DONE 的。

各項欄位用途:

NEW:使用者提出的需求,這裡我們要先逐項討論,並依據優先序安排上、下的順序。

APPROVED:已經確認要列入處理的項目中,這裡的目標就是要描述工作內容,團隊討論給定 EFFORT 的分數

COMMITED:上面兩項是由PM 決定移動,這裡就是成員依據自己的時間,由 APPROVED 移動到 COMMITED,代表已經開始進行

DONE:同樣由成員將已經完成的項目移動。

這樣的方式主要目標就是簡化成員的工作項目,讓使用率可以普及。

專案開發

走標準的 SCRUM 架構,這一週花費許多時間討論 TASKS &CAPACITY,並且說明 BURNDOWN CHART 的目的:

此外,在專案開發部分,採用小組訓練,而非全部的成員一起參與。因為 TASKS 的細分需要許多討論,無關的人參加畢竟有時間上的浪費,且成效也未必大。

 

目前接受度算是可以,尤其對專案經理而言,也同意這樣的方案有許多優點,並且能夠積極參與,算是已經邁出第一部了。

第二週心得總結

本週主要重複進行 PBI 的心得分享與評分,可以感受到大家參與的熱度。

透過這樣的心得分享,可以讓大家得知其他人在做什麼,也順便更新了目前團隊所進行的項目有哪些。另外也強調團隊整體的榮辱與共,每個項目也許不是所有人都投入,但是還是必須要分享給其他人。目前會以兩個方向為主:

  1. 維護的項目:以KANBAN 的方式進行,不區分SRPINT,直接透過 BACKLOG BOARD 區分 APPROVED、COMMITED & DONE。這裡的目的在於將重要的維護項目也納入,如此就可以讓每個人都自行規劃進度,降低PM的工作量。此外一個重點再於維護項目一班都是一個人負責到底,因此TASK的拆分相對而言不是那麼重要(畢竟把事情完成即可);因此直接將PBI指定給成員會是比較簡單的作法。
  2. 專案:此部分就會按照標準的SCRUM進行

上述無論哪一個,都會採用PBI的方式進行。

此外,也介紹的VSTS關於 SCRUM 的整合方式,包含:PBI 建立、TASK建立、CAPACITY、SPRINT 定義。可以看出來大家還是很有興趣的,目前還再請成員各自研究,主要重點放在PM是否熟悉操作方式,此部分單獨指導即可,只要由上而下,自然就惠普及,不用太過於浪費時間全體教育。

下週要安排GIT的操作說明,讓現有維護專案可以直接匯入,整合WORK ITEM,發輝VSTS的效益。目標還是要走向完整的 DEVOPS。

建立一個 SCRUM Team:第二週

一個好的 SCRUM團隊,最基本的任務就是要能夠凝聚對於 PRODUCT BACKLOG 的評分依據,如此才能有後續依據。因此本周持續進行 Story Point Estimation。作法是個別成員報告已經完成的PB,需要描述完成哪些內容,以及評估的分數,然後再用新的要進行的PB進行團體評估。

此外主要重點在於介紹 VSTS,針對上週所提出的PB,填寫 PRODUCT BACKLOG,並且進行工作拆分(TASK),與指派同仁進行。具體介紹的內容如下:

  • 介紹 WORK 的項目與對應的內容:說明如何建立 PRODUCT BACKLOG ITEM 並說明 EFFORT 等同 STORY POINT ESTIMATION。與 PRODUCT BACKLOG 的優先序是由上而下,可藉由拖拉方式說明。
  • 介紹 TASK、ASSIGN & REMAINING WORK(等同工時)的定義
  • 介紹 SRPINT、ITERATION(定義兩週)、CAPACITY 的定義
  • 用測試專案實際操作給同仁參考,與練習

 

本週就會開始使用 VSTS 進行專案管理,因此主要的 PRODUCT OWNER 可個別教學。

第一周心得總結

完成的定義團隊討論的還不錯,每個人都有貢獻自己的意見與心得;最終也彙整出大家接受的目標。接下來就會將之放在 A3 紙上,並且用保力龍掛在辦公室後方,提醒自己,也讓其他單位知道資訊需求有哪些需要處理的項目。

至於 Story Point Estimation,事先準備 3, 5, 8, 13 這四個案例給大家參考,但可以看得出來不是每一個人都瞭解案例內容,因此評估分數比想像中高。不過還是要接受群眾的智慧,不堅持己見、不說服他人我想是推動的基礎。

下週會有兩個方式:

  1. 定義大家每天可以投入的時間
  2. 預估 story point 與時間的關係(可能要拆到 details,但也是依靠眾人力量)
  3. 再加上一個案例分享,這次則是大家評估,並且用來連結時間的關係

建立一個 SCRUM Team:第一週

目標一、定義什麼是完成!

一個SCRUM團隊,必須要有最基本的針對什麼是 PBI (項目:Product Backlog Item) 「完成的定義」

  1. 團隊共識什麼叫做完成
  2. 讓其他人知道完成一個小需求要做的事是很多的,而不是一下就好了
  3. 將完成的目標放入到 Product Backlog
  4. 將他寫在 A3 的紙上,貼在團隊後方,讓每一個來訪的人都可以看到
組織團隊會議,針對問題:『一個需求完成我們必須要做』,提出每個人的意見與整個團隊的共識
  • 開發:
    • 先撰寫單元測試
    • 50% 的程式碼都有單元測試涵蓋
    • 可以正常編譯,並且通過單元測試
    • 程式碼已經被內入到 main master
    • 測試資料庫的 Table Schema 已經被納入到正式資料庫
    • 程式碼有被其他人檢查是否撰寫OK
  • 測試、發佈、運營
    • 有QA測試計畫
    • QA測試計畫被其他人檢視確認正確
    • 在測試環境發佈與測試完成
    • 有撰寫自動UI測試並且通過
    • 少於一到兩個嚴重的BUG
    • 有明確的驗收標準,並且被專案經理審視過
    • 部署計畫有被運營單位確認
    • 正確發佈到正式區

目標二、討論什麼是速度

用 Story Point 分析每個項目的得分,請注意,這裡的分數是代表整個團隊投入需要的工作,並且項目的完成必須要滿足上面的「完成的定義」

作法:將目前手上的項目提出,用之前我們完成項目的經驗,再給定每一個項目分數。每個人可以用以下的分數給分:

接下來,進行討論會議:
1. 提出一個 Story Point = 5 的需求A,描述這個需求A要做哪些工作
2. 在舉範例需求B,描述需求B工作,為什麼比需求A大,再描述需求C與為什麼比需求A小
3. 在拿出目前的工作項目,讓團隊成員每個人決定這個需求分數
4. 請最大跟最小分數的人說明原因
5. 在重複團隊決定分數
直到大家都趨近一個數字即可停止。