安裝 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: 必須要知道預計部屬的環境,例如: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 的細分需要許多討論,無關的人參加畢竟有時間上的浪費,且成效也未必大。

 

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