[SpecFlow] SpecFlow Report and Pickles via Command Line

續上篇,https://dotblogs.com.tw/yc421206/2016/04/25/specflow_pickles_live_document,上篇使用了 Pickles 產生出 Feature 報表,這篇要介紹 SpecFlow 報表,SpecFlow 本身就內建報表,這個報表比較適合開發人員,請參考:

https://github.com/techtalk/SpecFlow/wiki/Reporting

這篇提供了我寫的 Batch 檔,若對指令還不熟的,可以從參考一下。

[TFS 2015] 實作 Build vNext + Release 自動部署元件到內部 Nuget Server

以往,我都是使用用 NuGet Package Explorer 手動部署到公司內部的 Nuget Server,也用過 Nuget Packager,這兩種方法都不錯,只是無法自動地跟我的測試整合在一塊

TFS 2015 Build vNext 裡面有打包 Nuget Package 的步驟,Release 有部署 Nuget Package 的 Task,新版的 TFS 2015 讓我的自動化部署 Nuget 變得很簡單,有在使用 Nuget 的夥伴,可以參考我的設定。

[TFS 2015] 實作 Build vNext + Release 自動部署至內部網站

前半段, CI (Continuous integration) Server 處理:程式碼版控→自動化測試
後半段, CD (Continuous Delivery) Server 處理:自動化部署→自動部署到測試機→簽核(QA), 用來完成自動化部署的動作 ,TFS 2015 Update 2 才把 Release 整合到網頁。

Release 就是 CD
接下來的演練, 我仍然要發行網站應用程式到內部環境,除了上篇的做法之外,我們也可以用 TFS 2015 Update 2 才加入的 Release 新功能。

[TFS 2015] 實作 Build vNext + WebDeploy(偽) 自動部署內部網站

以往手動部署網站我習慣用 Web Deploy,就是在網站應用程式,按右鍵→Publish。

但,我在目前的 TFS Build vNext 版本找不到這樣的部署步驟(只有 Azure),於是花了一天的時間試出堪用的替代步驟,所以嚴格來說這不算是真正的 WebDeploy ,目標環境也不需要安裝 WebDeploy。

若有更好的做法,也請你跟我說

[VSTS] 利用 VSTS 實作自動部署

 VSTS(Visual Studio Team Service),是微軟雲端版的 CI (Continuous integration) Server ,以前叫 Visual Studio Online,近幾年,VSTS | TFS 改變的很大,尤其新版的 Build vNext,使用起來更有彈性、更容易。我需要用它來完成,程式碼版控→自動化測試→自動化部署(部署到測試機),下圖出自董大偉老師。

就算你只有一個人,也建議應該要有 CI Server,來幫你完成這些事情

[SQL Project] 依條件部署資料庫

資料庫專案範本,已經成為我在開發專案時,不可或缺的資料庫管理工具,善用它提供的機制,可降低出錯的機率。

Predeployment | Postdeployment Scripts 它是資料庫專案所提供的語法,是一種SQLCMD,現在我要利用它來部署我的開發 | 測試環境,資料庫專案有 DDL,在不同的條件,呼叫不同的 DML

[C#.NET][Entity Framework] 實作 DAL 共用方法的交易

上個月,同事問我 DAL 裡的 CUD 方法若需要共用,交易要怎麼寫?

首先,要思考處理資料庫的 Data Access Layer 裡的 CUD方法,該不該共用?

  •  以使用者案例的角度切入看 DAL,它不應該有機會共用,因為每一個作業流程的資料異動方式不會一樣。
  •  設計 DAL 方法時,不應該用 Table 的 CRUD 作為 DAO 的 Method,相信我,那只會讓事情變得更複雜而已。
  •  共用 DAL 方法,就得把檢查機制放在 DAL 方法。

[C#.NET][Unit Test] 採用 LocalDB 進行集成測試

集成測試主要是測試個元件之間的互動是否如預期,在這個階段的測試,我會把程式進入點 UI Layer 換成單元測試專案,由測試專案取代之,為什麼不是直接從UI測,原因很簡單,因為 UI 的變化太快了,一方面為了減少因 UI 改變而衍生出額外的工作,另一方面則為了提高測試程式碼的重用性,所以我會從 BLL 測試

三層式架構,物件彼此之間的關係,如下圖:

[C#.NET] 動態產生 AS400 對應的 POCO/DTO

手動建立 OR-M 的 POCO 可是一件苦差事,針對 EF 不支援的資料庫,透過這個小技巧,可以大大提升程式設計師的生產力、降低錯誤發生,團隊使用 EF開發資料庫,但 AS400 並沒有支援 EF的 Provider,怎麼辦,我再也不會回頭使用弱型別的 DataTable 了,這時候 Dapper 就派上用場,請參考:https://www.dotblogs.com.tw/yc421206/2015/04/20/as400_connect_provider