Wednesday 26 June 2013

Are my changes in the release?

One question often asked from a release manager is "Are my changes in the release". This happens often especially when it comes to the crunch i.e. near the release deadline or at times of sending a patch to fix of a urgent high priority issue.

Team Foundation Server behaves slightly differently in selecting changesets to include in the build based on the build trigger. So, if you are pondering that a changeset you were not expecting in the build is not part of it, it might be useful to look at the build trigger option.

There are 5 options to trigger a team build and here is how changesets are chosen in each build case:

Manual:
As named, the build with a manual trigger option will only occur a user queues a build manually. For builds triggered manually the executing build will fetch all the changes in the Active working folders until the point of time when the build fetches source files.

For example, let's say that the build was queued at 8:45 am but remained in the queue for 10 minutes So it started running at 8:55 am. Meanwhile, a couple of changes (changesets 11495 and 11497) were checked in at 8:47 am and 8:51 am respectively. The build would include both the changesets.

Continuous Integration :
If this trigger is selected, a build is queued every time a changeset is checked in. In this case, the build request also contains the changeset number that queued the build. For all CI builds, all changes in the Active working folder up to the changeset that queued the build would be in included in the build.

For example, if the build was queued at 8:45 am by a changeset 11495 and remained in the queue for 10 minutes i.e. it started running at 8:55 am. Meanwhile, another changeset 11497 was checked-in at 8:47 am. Another build was triggered. The first build would not include the changes present in the changeset 11497 even though the changes were already in source control at the time when the build was fetching source files.

Rolling Build:
With this trigger option, Team Foundation Server still triggers a build on a check-in but only if there are no build already in the queue or in progress. If a build is already in queue or in progress, it accumulates all changes and queues a new build once the first build is completed.6

Similar to Continuous Integration, the build request contains the changeset that queued the build and all changes up to that build number are included in the build.

For example, if the build was queued at 8:45 am by a changeset 11495 and remained in the queue for 10 minutes i.e. it started building at 8:55 am. Meanwhile, two changesets 11497 and 11498 were checked in checked-in at 8:47 am and 8:51 am respectively. Another build would be triggered after the first one is completed. The first build would not include changes in the changesets 11497 and 11498 even though the changes were in source control at the time when the build fetch source files.

Gated Check-in
With Gated check-in, a build is triggered for each changeset and only committed or check-in once the build is successful. With this option a build is queued for each changeset (assuming the option to merge and build gated builds is not selected).

Like Continuous integration, every build request has a changeset that triggered the build. However, unlike CI the build will include all changes which are check-in until the build fetches the source control and not when the build was queued.

For example, if the build was queued at 8:45 am by a changeset 11495 and remained in the queue for 10 minutes i.e. it started running at 8:55 am. Meanwhile, another changeset 11497 was checked-in at 8:47 am. Another build was triggered. The first build did not include changes in the changeset 11497 since they are checked-in yet. However, the second build did include changes checked-in as a result of the successful completion of previous build even though at the time of queuing the build these changes were not checked-in.

Schedule:
The scheduled build is triggered repeatedly on a particular day / time. For scheduled builds, TFS picks up all the changesets until the time when the build was queued.

For example, let's say that the build was queued at 8:45 am but remained in the queue for 10 minutes and start started running at 8:55 am. A couple of changesets 11495 and 11497 were checked in at 8:47 am and 8:51 am respectively. The build would NOT include both the changesets.

PS: To read more about the build triggers and the scenarios and the optimal scenarios to use them, read the Build Customization Guide produced by Microsoft ALM rangers.

Tuesday 18 June 2013

TFS 2012 - Invalid Changesets appearing in the list of merges

I encountered this problem of getting unnecessary changesets in the merge list after branching using TFS 2012, so thought to blog about it.

I took a branch out of our main development branch, using the option "latest version". Immediately after the branch had been taken, I attempted to merge from the source branch to the newly created branch with the option of "selected changesets to merge". 

Since, nothing had been checked-in in the source branch, you would expect that the list is empty. However, I could see quite a few pending changes in there. Confused and somewhat unsure of what happened there, I did a folder comparison between the source and target branches and the files were in fact the same, so no concerns as far as branching goes.

This is actually a known issue in TFS 2012 and has been fixed in TFS 2012 Update 2. The issue was that if the source branch contains a file such that the file has had a case only rename (e.g. it has been changed from file.txt to File.txt), any changesets containing that particular file will still be shown in the list of pending merges.


As, I said the issue has been fixed in TFS 2012 Update 2, so your solution is to upgrade to TFS 2012 Update 2.

Thursday 13 June 2013

Failed to generate a user instance of SQL Server due to a failure in starting the process for the user instance. The connection will be closed

I haven't had much chance to use SQL Server Express Edition of late. So, when I hit an issue an on an environment using SQL Server Express Edition last night, I thought to use the opportunity to read around. I must say that Microsoft progressed appreciably the whole portable database story and it has come a long way since the days of MSDE.

First let me explain the  issue I was looking at, in case it might help some troubled soul. So, on an environment using SQL Server Express 2008, I started getting the following error

"Failed to generate a user instance of SQL Server due to a failure in starting the process for the user instance. The connection will be closed."

Not knowing what caused it, I tried to Google the error and got many posts suggested to delete the local database file copied to the folder "C:\Users\MyUserName\AppData\Local\Microsoft\Microsoft SQL Server Data\SQLEXPRESS"

Did that and restarted but the error persisted. Then I stumbled upon the following post http://social.msdn.microsoft.com/Forums/en-US/sqldataaccess/thread/60889070-5c3c-4823-ae9f-1ed6e32b2ce8/ indicating that the user instance feature of SQL Server 2008 has been deprecated. That was a good pointer. Changed my connection string from 

"Data Source=.\SQLExpress;Initial Catalog=mydbfilepath;Integrated Security=SSPI;MultipleActiveResultSets=true

To

"Data Source=.\SQLExpress;Initial Catalog=mydbname;Integrated Security=SSPI;MultipleActiveResultSets=true"

And that worked.

Coming back to the original topic, there are three flavors of portable databases available for SQL Server for small scale usage and for developers.

SOL Server Express
SQL Server express is the freely available and downloadable version of SQL Server that can be used for small scale applications. The change here is the User Instances have been deprecated from SQL Server Express 2008 onward.

SQL Server Compact
SQL Server compact is a very lightweight version of SQL Server that can connect to a database file. It is In-process DLL, which means it is an ideal candidate to meet all your IMDB (In Memory  Database) needs.

SQL Server Local DB
SQL Server local DB is designed specifically for developers and differs from SQL Server in that it min version of SQL Express with less pre-requisites.


This post compares the three flavors rather well.