Introduction
In the previous post in this series on Continuous Delivery with TFS / VSTS, we configured a sample application for Git in Visual Studio 2015. This post continues with that configuration and also examines some of the more interesting parts of Contoso University before firing it up and taking it for a spin.
Build and Update NuGets
Picking up from where we left off last time in Visual Studio, Team Explorer – Home should be displaying ContosoUniversity.sln in the Solutions section. Double-click this to open Contoso University and navigate to Solution Explorer. The first thing to do is to hit F6 to build the solution. NuGet packages should be restored and the five projects should build. It’s worth checking Team Explorer – Changes at this point to make sure .gitignore is doing its job properly – if it is, there should be no changes as far as version control is concerned.
For non-production applications, I usually like to keep bang up-to-date with the latest NuGets so in Solution Explorer, right click the solution and choose Manage NuGet Packages for Solution. Click on the Updates link and allow the manager to do its thing. If any updates are found, click to Select all packages and then Update:
Commit (and sync if you like) these changes (see the previous post for a reminder of the workflow for this) and check the solution still builds.
Test the Unit Tests
The solution contains a couple of unit tests as well as some UI tests. In order to just establish that the unit tests work at this stage, open Test Explorer (Test > Windows > Test Explorer) and then click on the down arrow next to Playlist : All Tests. Choose Open Playlist File, open …\ContosoUniversity.Web.UnitTests\UnitTests.playlist and run the tests which should pass, albeit with very poor coverage (Tests > Analyze Code Coverage > All Tests).
Code Analysis
Code analysis (a feature formerly known as FxCop) is enabled for every project and reports on any rule violations. I’ve set projects to use the Microsoft Managed Recommended Rules (note though that rule sets don’t exist for SQL Server database Projects and in the case of ContosoUniversity.Database, everything is selected), however the code as it exists in GitHub doesn’t violate any of those rules. To see this feature in action, right-click the ContosoUniversity.Web project and choose Properties. On the Code Analysis tab, change the rule set to Microsoft All Rules and build the solution. The Error List window should appear and there should be quite a few warnings – 85 at the time of writing this post. Reverse the change and the solution should once again build without warnings.
SQL Server Data Tools – A Better Way to Manage Database Changes
There are several ways to manage the schema changes for an application’s database and whilst every technique undoubtedly has its place, the one I recommend for most scenarios is the declarative approach. The simple explanation is that code files declare how you want the database to look and then a separate ‘engine’ has the task of figuring out a script which will make a blank or existing database match the declaration. It’s not a magic bullet since it doesn’t cope with all scenarios out-of-the-box, however there is usually a way to code around the trickier situations. I explained how I converted Contoso University from an Entity Framework Code Migrations way of managing database changes to a declarative one using SQL Server Data Tools here. If you are new to SSDT and want to learn about it, I have a Getting Started post here.
As far as Visual Studio solutions are concerned, the declarative approach using SSDT is delivered by way of SQL Server Database Projects. In Contoso University, this is the ContosoUniversity.Database project. This contains CREATE scripts for tables and stored procedures as well as for permissions and security. Not only does it contain scripts that represent the database schema, it also contains scripts that can insert reference data into a newly created database. The significance of this becomes apparent when you realise that a database project can be used to create a database in LocalDB, which can be made fully functioning by inserting reference data. In many cases, this could remove the need for a ‘dev’ environment, as the local workstation is the dev environment, database and all. This eliminates the problem of config files containing connection strings specific to developers (and the check-in problems that this can cause) because the connection string for LocalDB is generic. This way of working has the potential to wave goodbye to situations where getting an application working on a development machine requires a lengthy setup script and usually some magic.
To see this in action, within the ContosoUniversity.Database project, right-click CU-DEV.publish.xml and choose Publish. In the Publish Database CU-DEV.publish.xml dialog, click on Publish:
Now make sure that the ContosoUniversity.Web project is set as the startup project (if not in bold, right-click and choose Set as StartUp Project) and hit F5 to run the application. A fully functioning ContosoUniversity should spring to life. Navigating to (for example) Departments should allow you to perform all CRUD activities. How’s that for simplicity?
Tour Stops Here
That’s it for our tour of Contoso University. Although there are automated UI tests in the solution, I’m purposefully not covering them here as they are very much an advanced topic and I’m also planning some changes. That said, if you have FireFox installed on your development machine, you can probably make them run. See my post in a previous blog series here.
In the next post, we look at getting a basic CI build up-an-running. Happy coding until then!
Cheers – Graham
The post Continuous Delivery with TFS / VSTS – A Lap Around the Contoso University Sample Application appeared first on Please Release Me.
