Release management with different configurations

So Visual Studio Team Services now has this automatic deployment option, where you can checkin your changes in source control to have the application deployed to a development/testing/production environment automatically. 

But how do you cope with each environment's different configuration? Read on...

What we want

As you are developing locally you probably want to develop on a local database. The easiest way to do this is to have everything in web.config (I am using a web project as an example here, but things are similar for other project types). This way developers can quickly change things locally, for easy testing with different databases, and even see how things work with live (I hope cloned from production) data.

But when deploying to a test environment (and other environments such as production) you want to use a different web.config, preferably NOT containing any production secrets (like the connection string to the production database).

VSTS release management makes this very easy.

How To

Let's say that I have application settings and connection strings that I want to give a different value in development, QA and release:

  <appSettings>
    <add key="Secret" value="DeveloperSecret"/>
  </appSettings>
  <connectionStrings>
    <add name="DB" connectionString="DeveloperDB"/>
  </connectionStrings>

I have already created a Build definition in VSTS, and I am using it to initiate a release with VSTS release management.

In my release definition I have three environments, one for dev, QA and production.

For each environment, click on the ellipsis (...) button and choose Configure variable


Add variables who's key matches the key from appSettings (or name for connectionStrings)


Select your deploy to azure task in release management


Look for the File Transforms & Variable Substitution Options section and make sure you check the XML variable substitution checkbox.


This will make the deployment task replace any key in appSettings and connectionStrings with your variable values.

That's it!

Keeping a file checked out after check-in with Team System

This week I got a question whether it is still possible to keep some file checked-out during a check-in. This is something you can do with Source Safe for example. To be honest I had no idea if this is possible, so I decided to have a look. So the answer is yes (although in general I think this is dangerous because this way people tend to check out files for long periods…).

Simply go to options and check the fourth check-box from the top.

image

Team System 2010: Easier project management with Team Project Collections

Team System 2010 introduces the concept of team project collections (TPC). A team project collection is, as it says, a collection of team projects, which can be managed individually. You can backup, move, delete, etc… each collection individually. Each collection will also have its unique work item ids, check sets, etc… Team project collections also change the way team foundation stores its stuff. Before it would use a bunch of databases, now everything connected is stored in a single database. One database per collection. You can easily find the database because it’s called Tfs_<CollectionName>. You ‘ll also find the Tfs_Configuration database containing all configured project collections (and depending on your installation a database for the analysis services).:

image

Project collections also solve a problem some of you might have encountered; TFS 2008 has an upper limit of 255 team projects. Now with TPC you just add another TPC when you reach the limit (I don’t know the limit of projects per collection, but I would assume it would be around the same…).

A TPC can also easily be moved to another team server/farm, or to another SQL server on the same farm, as long as you keep it on the same type of SQL server (enterprise, express, …). Documentation states you cannot move it to another kind. The way to do this is to first open the Team Foundation Administration Console, and select the Team Projects Collections tree item. To the right you should see all your TPCs.

image

Here you can also create new TPC's, but that should be obvious.

So to move a TPC you should first stop the collection. You’ll be asked for a reason:

image

And then you detach the collection:

image

Next you go through a verification step:

image

And then you click Complete:

image

Now the TPC is no longer connected to TFS, but is still there in SQL server.

image

So now you detach the database in SQL server, move it to another SQL server or TFS farm. You might first need to restart a couple of services, such as the build service.

So after attaching the database in SQL server, we now need to attach the database to TFS; go back to Team Foundation Administration Console, and click the “Attach Collection” button. Now choose your SQL server instance, and you’ll see all candidate databases:

image

Hit Next if you want to change properties such as the name/description:

image

And next again to see an overview.

So complete attaching, hit Verify to make sure everything is in order:

image

And then hit attach.

image 

Eh voila!

image

Now the TPC should be in the list:

image

You can also split the projects in a single TPC to multiple TPCs (but not merge them, so be careful), but that will be for a later post.

Gated Check In with Multiple Build Definitions

As promised in my previous blog on Gated Check In, in this blog I’ll discuss using multiple builds with gated check in.

So what happens when you check in (using gated check in) and there are multiple build definitions targeting the solution? Well, Gated Check In will then allow you to choose between the different build definitions; for the moment Team Build does not allow you to filter the build definitions that are shown:

image

In my example I’ve created a second build definition that doesn’t run tests, so you can select this one when you need to check in code without running tests…

Planning, Running and measuring tests with Visual Studio 2010 Ultimate and Test and Lab Manager

So what does Visual Studio 2010 bring for testers? A whole lot! Especially the new test environment, where you can create a test plan to validate the quality of the software you’re building. A test plan is a collection of test cases, which you can then run. While running the system keeps track of a whole lot of things, including code coverage and IntelliTrace information. And finally this application allows you to examine the combined results of all tests, to see how your development effort is doing.

So again: A test plan is a collection of test suites, used to test a certain iteration in your project. A test suite is a collection of test cases to test a certain part of your project, and a test case is a test for a project feature. A test case is basically an UI test running in a specific environment. To model this, Test and Lab manager also allows you to define a test configuration, which is a certain environment for your code, for example Windows 7 with IE8, or Windows XP SP2 with IE7.

Running Test and Lab Manager

First time you run this application it will ask for your Team Foundation Server (TFS) and after that, for the Project Collection and Team Project:

image

Ok, next step it will ask you for a test plan; since there are none you will have to create a new one:

image

Then click “Select plan >”.

This opens the test plan.

image

if you want you can change some of the properties of this test plan by clicking on the properties tab:

image

Here you can change the iteration for example, or the test settings.

image 

With test settings you can change how your tests will be executed. For example in the Local Test Run settings you can change the diagnostic data adapter, which record data from your test run. For example is you want an action recording, event log entries, etc… You can also use it to emulate certain environments, for example running low on memory. You can even create your own data adapter.

image

This first page allows you to change the name, and choose between running a manual or automated test.

image

On the second page you can define the roles. You define a role for each tier to use to run tests and collect data. One the local settings you can only have one role, your own physical machine. If you want to use roles, you will also have to define environments.

image

Here you can define what kind of data you want to gather. For example, the Action Recording will record each action taken during the test, making it easy for another person (typically a developer) to understand what happened during running the test. The Action log is a text version of the recording. IntelliTrace will allow a developer to load the IntelliTrace log and step back in the code, to see how the error came to be.

Go back to the Contents tab.

Now we’re ready to test some of our user stories (from now on I will be using User Stories, but this could just as easily be called a requirement or anything else to denote a certain needed functionality of your software system). Test cases are grouped into test suites. Per test plan you have a default test suite, but you can also create a test suite for a specific user story, copy a test suite from another test plan, create a nested suite or create one from a query:

image

If you select “Add requirement"to plan” you will need to select a user story. This user story is now associated with this test suite. This will allow reporting to figure out which tests have ran for which user story.

image

Now we’re ready to add a test case, so click the New button. The New Test Case dialog should show:

image

Add the four steps (please note that we’re doing this for the sake of the demo, normally your requirement should not be to crash :) ). Save it.

Click on the Tested User Stories tab: the User Story should be there. Save and Close.

A couple of other things you can now do is to assign it to a tester, and/or change the configurations:

image

Let’s run the test. First open the Test tab: image

From here you can see all test cases for a test suite:

image

Select the test case and click on the run button. The Test Runner should open:

image

Check the Create action recording button and hit Start Test. Do as the test case says, and try to use a repeatable way to start the application (for example using the start menu). The first and second step should not be a problem, so click the drop down boxes to the right of each step to indicate success:

image

Now make the third step fail. You’ll need to enter a comment why it failed. Then click the End Test hyperlink button. You’ll see test center gather some information.

On top of the test runner window you’ll see a toolbar. Click on the Create Bug button:

image

You’ll see that most of the fields are automatically filled in. You might want to change the Severity for example, and maybe assign it to a certain tester, but that is all… Click Save. Check out the information included in the System Info, and All Links tab. Close it.

Remember me asking you to start the application using some repeatable way? Well, try and click on the play button. Your test should replay again. This makes it easier to re-test later.

Coming back to Test and Lab Manager. The test case failed so now the UI updates to show this:

image

If you have more than one test, the bar will color depending on how many succeeded, failed or are still in progress.

Later you can come back and verify if a bug still exists by using the Verify Bugs tab:

image

Go back to the Plan tab, then open the properties. Now you should see an overview:

image

Back to Visual Studio, so close the Test and Lab Manager. Go to the Team Explorer and open the My Bugs query. You should see the bug we created before. Open it:

image

Go to All Links, and open the IntelliTrace log (.tdlog). With it you can now replay the bug, just like in my previous post on IntelliTrace. If this doesn’t work, go back to the test settings. You might also like the Video feature, so you can replay the user’s actions!

Using the Visual Studio 2010 layer diagram to verify your solution

Visual Studio 2010 adds a whole new series of modeling tools to the product, including UML modeling. In this post I want to discuss the Layer diagram and its relation to building enterprise applications.

The Layer Diagram

Visual studio 2010 now comes with new modeling tools, which you can reach through the architecture menu from Visual Studio 2010 (I’m using the Ultimate edition):

image

This will open the Add New Diagram dialog:

image

Select Layer Diagram. If you don’t yet have a Modeling Project in your solution, another dialog will open so you can name your new modeling project.

You should now see an empty layer diagram, so let’s add some layers. Open the toolbox:

image

Double click the Layer item in the toolbox (doing this will lock the toolbox into adding layers, if you single click it you will need to go back to the toolbox for each layer) and click the layer diagram three times to add three layers, stacked vertically. Name the top one Presentation, the middle one BLL (Business Logic Layer) and the bottom one DAL (Data Access Layer).

image

So now we have three layers. Now let’s add a couple of dependencies. I want the presentation layer to use the BLL layer, but not reversed, so let’s model this by adding a dependency image from the Presentation layer to the BLL. Let’s also do the same for the BLL to the DAL:

image

The Enterprise Application Skeleton

Having a layer diagram is nice, but how can it help you with your development? The layer diagram can help by verifying your solution and projects comply with the layer diagram. As an example I want to use the Enterprise Skeleton solution I use for enterprise development. In its simple version there are 4 projects (excluding the modeling project): one for the presentation layer, one for the BLL and one for the DAL. The fourth project contains the data carrier objects that travel between layers; the DAL is responsible for retrieving and storing these objects, the BLL will check these objects using the business rules and the presentation layer will display these objects.

image

Let’s use this solution with the layer diagram.

Adding layer verification to your solution

Open Visual Studio with this kind of solution and with your layer diagram (part of a  modeling project in your solution). Now drag and drop each project to its appropriate layer. Drop the Products.Common onto the DAL layer (this is a mistake which we’ll discover soon with the verification feature). Each time you do this you will see a counter appear on the layer, counting the number of projects mapped to the layer…

image

However, you cannot see here which project is mapped to each layer. Back to the architecture menu. Open “Windows –> Layer Explorer”, which displays the mappings:

image

If you select a specific layer in the layer diagram, this window will show only projects mapped to it. You can do the same by: right-click on a layer, select View Links.

Validation the solution

Right-click the layer diagram and select Validate Architecture:

image

Visual studio will start to analyze your code and may return a bunch of validation errors:

image

image

Open the error list window to see these errors:

image

From here you can do several things: create a work item to correct the error, suppress the error, or investigate the error:

image

The screenshot illustrates the last action. With this you can go to the method or type involved in the validation error.

The problem we are facing here is actually because I put the Products.Common project into the DAL. But the presentation layer also needs the types in this project, but we’re not allowing referencing the DAL from the presentation layer. We could add this dependency (please don’t), or we can fix the problem.

Fixing the problem

Add another layer to the layer diagram, calling it Common. This layer will contain all types common to the other layers, so add dependencies from these layers to the common layer. Finally drag the Products.Common project to the common layer.

image

One more thing: we need to remove the Products.Common project from the DAL layer. Select this layer, in the Layer Explorer you should see two projects. Remove the common project. Now verify again. You should have 0 errors.

Automating Validation

This validation is a powerful tool to prevent layering mistakes from creeping into your solution. So can we automatically run this whenever we build?

Yes we can! One way is to set the Validate Architecture property of the modeling project to true. Then each time you build the solution the layer diagram will verify. This can take same time for each build, so it is better to do this using Team build. You can enable validation using the /p:ValidateArchitecture=true option. To do this, open your build definition and set the “MSBuild Arguments” property like this:

image

Generating dependencies from your solution

Another thing you can do is to add the layer dependencies from your solution. Right-click the layer diagram after adding your layer (and which you mapped to your projects). Then select the Generate Dependencies menu.

image

What else is there?

What else can you do with the layer diagram? Look at the previous screen shot. If you’re connected to VSTS you can link and create work items.

Project Management: Planning an iteration with Team System 2010

In my previous post I talked about planning a whole project. Now I want to blog about planning a single iteration using the new Team System 2010 iteration with Excel and Project.

After creating the user stories, the next step is to break each user story into detailed tasks. To facilitate this, the MSF agile template has a special Excel sheet under Documents->Shared Documents->Iteration <X>:

image

Double-click to open it. Before you edit, click the Edit Workbook button beneath the ribbon:

image

To split up a user story into (linked) tasks, you want to create child work items beneath your user story. Do this using the “Add Child” button on the ribbon:

image

Pressing the Add Child will add another row to the sheet, and also adds another Title column. This is used to detect/indicate the parent/child relation between two work items.

image

So here I’ve added a couple of child tasks to the user story. Now we can start planning the iteration.

First you will want to fill in the “Assigned To”, “"Remaining Work”, “Area” and “Iteration” columns with some data. Choose a team member for the Assigned To column, and choose your iteration for the Iteration column. Here’s an example:

image

Next you want to plan the iteration, so go to the Settings tab. In this tab you set the iteration start and end date. The Excel sheet will use this together with the interruptions sheet to determine the amount of work that can be done in this iteration.

image

Once you fill out this sheet you can go to the Capacity sheet, where you can balance the work load for each team member. Start by providing the hours/day and number of days in the iteration for each team member. Now you can see the workload for each team member.

image

April has way too much work (and Abu too little) so go back to the backlog sheet and move some work to Abu. Go back to the capacity sheet and see the now work load:

image

Imagine Doris being called over to help with another project. How will this affect capacity? Start by filling in the interruptions tab:

image

And go back to capacity. Whew. Not a problem!

image

Project Management: Hierarchical Work Items with Visual Studio and Project in Team System 2010

In my previous posts I talked about high level project management, and detailed iteration planning. Both created work items, mainly user stories with child task work items. How does this work in Visual Studio? And what about MS Project?

Visual Studio and hierarchical work items

Let’s start with Visual Studio. Open your team project and expand the Team Queries, then Workbook Queries:

image

You’ll notice that for each iteration VSTS creates an iteration backlog query, showing you the work items for the iteration. Pay attention to the icon: this means that this is a hierarchical query which will use indentation to show the parent child relation.

Execute one of the iteration backlog queries. You should get a list user stories:

image

Notice the + sign before the user story title: with this you can expand the the child tasks. In the toolbar you can also see an + and – icon. These will expand/contract all user stories with their children:

image

Should you see a task assigned to the wrong user story, you can simple drag it to the correct one, and Visual Studio will automatically move it, and indicate your changes using bold. Here I’ve moved tasks #48 to user story #11:

image

You can also use the green arrows in the toolbar to change the level of a work item, for example to make it a child work item. Be careful: this only works if your work items is below a user story. Otherwise drag it to the parent like before.

image

You can also directly create a child work item by right-clicking on a work item and adding a New Linked Work Item.

image

Linking to other work items has been greatly extended. You can now choose from a variety of links:

image

Note the predecessor link. We will revisit this when we look at MS Project and TFS.

Scheduling tasks with MS Project

When using MS Project with TFS 2008, dependencies added with MS Project would not be saved back to TFS. With TFS 2010 you can now easily plan tasks in project using Gantt charts, add dependencies and publish back to TFS without losing these dependencies.

Start MS Project using the “Open in Microsoft XXX” feature in Visual Studio:

image

Let’s say you have two tasks:

image

Now you want to indicate that the first task assigned to April must be done before April can start the second task. Do to this Alt-drag the first task to the second task to create a predecessor relation. Your Gantt chart should now look like this:

image

Note the Predecessors column which contains the row number of the first task. This is not the work item id, it is the number of the row in Project.

Now you can publish this back to TFS. After that, go back to Visual Studio and open the first work item. Go to the links tab. You should now see a successor link to the next task:

image

Project Management: Planning a project with Team System 2010

Project management has changed. Changed towards SCRUM based project management where you start by building a list of User Stories, also known as the backlog... This list of user stories allows you to plan the project by selecting the highest priority user stories, adding them to an iteration, planning the iteration and implementing it. User stories are assigned story points which is an abstract unit for measuring the amount of work.

Let’ start by creating a new Team Project. Nothing has changed in the “New Team Project” wizard except that the team project templates have been modified (to better support SCRUM like project management). Again you can choose between an agile template and the CMMI template. The CMMI (Capability Maturity Model Integration) template is more formal; in this post I’ll be using the agile template.

Creating user stories

A newly created team project will now be empty of work items; the intent is that you start by creating User Stories. These user stories describe the user’s needs. Then you prioritize the user stories and assign story points to them to estimate the work required.

A user story is a very slim and high-level user requirement. For example: “The delegate can pay by credit card to confirm reserving the course” (Personally I see user stories as short-hand versions of use cases). To create a new user story with Team System you can choose between Visual Studio, Excel or Team Web Access.

Using Excel

To create user stories you’ll probably want to use Excel. Previously I found the workbook that came with team foundation 2008 a little lacking, but now you get all you need to perform high level planning. So let’s set out and try this. Open Team Project explorer, and drill down to Documents->Shared Documents. Double click on Project Backlog.xlsm to open Microsoft Excel.

image

Ignore the security warnings if you get some...

The Product Backlog is a new workbook that enables you to manage your product backlog of work items from within Microsoft Excel.

image

Start by refreshing from the server by clicking the Refresh button. This will synchronize your workbook with changes made to the server. From Excel you can also edit your areas and iterations, access Team Web Access, and create reports. But also take notice to the sheets in this workbook:

image

First one is for editing the backlog, second one is for high-level iteration planning and the third one is for planning interruptions. The workbook takes very good care of synchronizing changes from one sheet in the other. Let’s start with the first one: the product backlog.

The workbook is open in read-only mode by default, so start by clicking on the “Edit workbook“ button:

image

Then you can start adding user stories:

image

Prioritize your user stories by assigning a rank. Prioritizing user stories can be done in many ways, for example Karl Wiegers Kano model. You also need to assign story points as an estimate for the amount of work required (story points don’t generally use precise estimates, like hours or something).

Using Visual Studio

You can also use Visual Studio to add a new user story; then you’ll get this window inside VS:

image

Please note the format of the title. This makes it a lot easier to think about user stories. Using VS for a single user story works like a charm, but for lists of users stories you’ll want to use Excel.

Using Team Web Access

Another option, which I think is quite realistic for project managers (and even end users), is to use a web site for editing work items. That is why Team System comes with Team Web Access. You can find the site from your team project portal. Then you can add any work item directly like this:

image

Select User Story from the drop down and you get this:

image

Again, you can add all necessary information directly.

Planning Iterations

Once you have a good idea about your user stories, you can start iteration planning. In this phase you will assign user stories to iterations. Each iteration will have room for a number of story points (this number is called project velocity, which is the average number of story points your team can do in a single iteration). Iteration planning is done with the Iteration planning worksheet.

image

Note the help above. Once you’re familiar with this sheet you can hide the help. In here you plan your iterations. First you enter start and end date. The sheet will calculate the number of days for the iteration, taking into consideration any planned interruptions you entered into the interruptions sheet. Next you can start to assign user stories to iterations. The sheet will update again with a simple bar chart, making it easier to load balance your work over iterations:

image

The interruptions sheet is just that, simply fill out any dates when no work can be done on the project because of holidays, special events, etc… The Planned Iterations sheet will automatically update nr of days with it. So for example, if we plan a team building meeting in Hawai on the 01/13/2010, the iteration will have 4 days:

image

That’s it for now. In my next post I’ll discuss detailed iteration planning with Visual Studio 2010.

Trying this yourself

If you want to try this yourself, I recommend you download the virtual machine from Microsoft (comes with sample data and all, and a bunch of labs).

The one using Virtual PC 2007
The one for Windows 7 Virtual PC
The one for Hyper-V Windows Server 2008