VS 2017 建議安裝擴充套件

Visual Studio 是一個強大的開發工具，尤其套件更是可以簡化開發的時間。建議以下幾個套件可以讓程式開發上更加得心應手。

安裝套件主要是在 Visual Studio Marketplace： Extensions for the Visual Studio family of products

可以直接在 VS 2017 中，點選【工具】->【擴充功能與更新】，再點選【線上】，在搜尋中輸入字串就可自動查詢：

 Add New File

可以直接在畫面上按下 shift + F2 就可以輸入檔案，自動會將檔案放入到指定的目錄中

Code Alignment:

提供快速功能，可以依據不同的特殊字元排序

Shortcuts

Align by… (Dialog) Ctrl + Shift + =
Align by position… (Dialog) Ctrl + =, Ctrl + Backspace
Align by Equals Ctrl + =, Ctrl + =
Align by m_ Ctrl + =, Ctrl + m
Align by ” Ctrl + =, Ctrl + ‘
Align by . Ctrl + =, Ctrl + .
Align by Space Ctrl + =, Ctrl + Space

VSColorOutput

提供美化 Output 視窗的文字，容易辨識最後結果：

以下幾個是大名鼎鼎的 Productivity Power Tools 2017，但目前提供可以單獨安裝的模組，因此挑選幾個常用的如下：

Github Extension for Visual Studio

必須要用系統管理員執行 VS 2017 後才會生效（因為會修改相關的介面）

安裝完畢後，仍會出現要求安裝 third party Git 套件（此即為 Git windows 官方套件）畫面，直接安裝就可以在 command prompt 使用 git command：

安裝過程中可以點選安裝 unix tool in CMD，如此就可以將 ls 等命令放入到 CMD 中（請注意這會影響到既有的 find command）。

Roslynator 2017

提供 Refactoring 大部分的功能，必須要安裝！ A collection of 190+ analyzers and 180+ refactorings for C#, powered by Roslyn.

Viasfora

提供 Keyword Highlight 等等，讓程式碼更加美觀

ZenCoding

快速完成 HTML short cut，例如：  ul>li*3 就會自動產生： <url><li></li>…</ul>

或者直接使用 p + Tab 就可以產生 <p></p>

開發第一張 SQL Server Reporting Service 報表

要透過 Visual Studio 才可以進行報表開發，因此必須要下載與安裝 SSDT（Sql Server Data Tools），判斷條件很簡單，如果 VS 2017 沒有 BI Template 救代表需要下載了。

 

點選 VS 2017 版本，並且勾選 Sql Server Reporting Services：

安裝完畢後，開啟 VS 2017，依據 建立基本資料表報表 (SSRS 教學課程)

基本上依據此份文件教學就可以完成基本第一張報表。

 

簡單說明幾個項目：

  1. 匯入 AdventureWorks2014 資料庫

因 Sql Server 用 docker image，因此這裡必須要執行 copy host file to docker 方式將下載的資料庫備份匯入：

docker cp .\[host]\[filename] [dockerid]:/[docker]/[folder]

之後就可以用 SSMS 匯入

  1. 報表資料的視窗有時候會不見，這時候可以用 hotkey 快速呼叫（不用到檢視中慢慢找）： ctrl+alt+D

  1. 透過部署專案就可以直接發佈到 report server，這裡要說明一下幾個網址的差異

發佈網址（點選 專案->屬性 就可以看到）：

可以看到 reportserver 是發佈網址

執行報表網址則是 reports：

安裝 SQL Server 2017 Linux Docker 與 Windows 環境下的 Reporting Service

SQL Server 2017 支援 Linux 環境，但目前尚未提供 Reporting Serivce。微軟日前提供獨立安裝的 reporting service，因此如果有此需求，可以透過分開安裝達成：

Linux： Sql Server 2017 （使用 docker container）

Windows： Reporting Service 2017

安裝 sql server on linux docker

首先依據Run the SQL Server 2017 container image with Docker 安裝 sql server 2017，要注意建議 port 改為 1433 only：

docker run -e "ACCEPT_EULA=Y" -e
"MSSQL_SA_PASSWORD=Strong!Passw0rd" -p 1433:1433 --name sql1 -d
microsoft/mssql-server-linux:2017-latest

要使用 docker logs sql1 檢查是否正確執行。

更詳細步驟參閱 使用 Docker 安裝 SQL Server 。

安裝 SSRS

然後下載 SSRS Standalone 版本，進行安裝。

安裝完畢後，開啟 Report Server Configuration Manager：

在『伺服器名稱』中輸入 localhost （對應 docker image），選擇連線。

主要設定：

服務帳戶、Web服務URL、入口網站URL：使用預設即可

分需要點選套用，例如『Web 服務 URL』中，不需要修改直接點選『套用』：

設定資料庫

連結比較麻煩，需要建立新的報表伺服器資料庫（因為不是跟 SQL Server 一起安裝）：

這裡要輸入 Docker 的資料庫名稱（因為docker 安裝在本機，並且將 1433 port forwarding 到內部，因此可以當作是 localhost 使用），後續的資料庫名稱接受預設值即可：

上面提到驗證類型有很多，但因為使用 linux docker 的資料庫，因此使用服務認證與本機使用者認證都會有風險，因此建議使用  sa 帳號。

點選入口網站時候，要輸入本機登入帳號、密碼（因為服務帳戶的設定）。當我們看到這個畫面代表已經設定成功：

建立 Visual Studio Team Service 的 Build Process

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

Release: 必須要知道預計部屬的環境，例如：Test、Stage & 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 會在左方產生『preview』tag，因此要注意上圖的 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. 再加上一個案例分享，這次則是大家評估，並且用來連結時間的關係