Khushboo's blog : Team Build

CI sample updated for the RC build

khushboo — Thu, 23 Feb 2006 12:18:00 GMT

Many of you must have already noted that the CI sample that we had earlier posted here was broken for the new RC build. The link has now been updated and you can download the sample from the same location for it to be built using the RC build.

Again, many of you must have noted that the article needs a small update in the bissubscribe command if you use it with the RC build to subscribe to events. The only change is that the /userId <your id> parameter does not have to be passed as it picks up the current user (I have updated my blog to reflect this change).

If you face any issues with the latest updated sample - do let us know

MSDN article on Continuous Integration

khushboo — Tue, 31 Jan 2006 09:56:00 GMT

I mentioned in my blog that there is an MSDN article on its way for CI and the sample that we shipped. Its now available - go check it out!

Build report:Changesets taking too much time to get populated?

khushboo — Mon, 09 Jan 2006 13:56:00 GMT

A Team Build user had this problem the other day and I thought it would be a good idea to share this lil 'tip of the day'..

As a part of the build process in team foundation build, we report changesets associated with each build. This is done primarily to help you quickly view what all checkins that went into this build with the name of the dev who made the checkin and his comments. This makes it much simpler to point out the possible cause of a build break..

But in cases where you have a huge number of changesets being reported (say around 5k of them)..this might take several minutes hence holding up your report and build. A very typical scenario would be when you have just migrated an existing project with an already existng store of changesets and work items and you have started a build. An interesting fact which causes this is, that we report changesets only between two 'successful' builds for a team project and for a build type. Pardon me for diverting from the topic but - the definition of a 'successful' build that we use in Team Foundation Build is a "build which has 0 compilation errors and has passed all tests included in the build" (Again we had a huge debate whether test results should or should not be included in determining a 'successful' build but we finally thought that any good daily build process should have this behavior - here is what Martin Fowler says about it ( I would love hear your thoughts on this though).

Ok so back to where we were - now that you have changesets taking several minutes to report and the matter is made even worse if the builds are failing - cause everytime you have to invest the same time to even debug what went wrong with the build..here are some tips to help you..

1. Did you know that you can actually skip this step of getting changesets altogether in team build?

To do this you would need to edit the Microsoft.TeamFoundation.Build.targets file. You simply need to change the property value of SkipPostBuild to 'True'. Here is what it would look like

But yes by doing this you would also be choosing to switch the automatic update of the associated work items with the changesets with the build number

2. But before even doing this - if the problem is simply that you need to debug the issue causing the build break - a better idea would be simply to do a desktop build (which does not get changesets or update work items).

Keep team building !!

Continuous Integration using Team Build

khushboo — Wed, 04 Jan 2006 11:26:00 GMT

You can easily get Team Build setup to perform Continuous Integration - a number one ask from most of the users of Team Build. Here is a sample which kishore and I came up with which helps you to get going with it (for beta3 and beta3R)

Follow these simple steps I followed to setup my CI sample

1. Install the CI.msi

2. In the second page of the wizard when it asks me for Site – I choose ‘Team Foundation Server’, Virtual directory is CI

3. I am done and the CI tool is installed.

4. I go to IIS manager and check if CI has been registered under ‘Web Sites’ ‘Team Foundation Server’

5. Go to the properties of CI and make sure the Application Pool chosen is ‘TFS AppPool’

Now I need to edit the web.config file in the CI tool

6. I go to the local path where CI has been installed – in my case by default it has gone to d:\program files\Microsoft Visual Studio team Foundation Server\webservices\CI

7. uncomment the following line and add the name of the TFS server, team project name and build type name

Finally I need to subscribe to the checkin event notification using bissubscribe

8. subscribe to the notification using Bissubscribe

To do this, use the bissubscribe tool available at “%programfiles%\Microsoft Visual Studio 2005 Team Foundation Server\TF Setup\BisSubscribe.exe" on the server. The command to use is

Bissubscribe /eventType CheckinEvent /address http://khushboo-dev1:8080/ci/notify.asmx /deliveryType Soap /domain http://khushboo-dev1:8080

Voila! You have CI all set for you, make a quick checkin and see if you get that build triggered off !

Something seems to be wrong still ? - Go through this list to make sure everything is in place

- Did you remember to choose Team Foundation Server while as the site or was it created under the default web site

- Did you remember to choose the TFSAppPool as the Application Pool

- Sometimes after subscribing to the checkin event – iisreset is needed

The sample consists of:

notify.asmx
web.config – the configuration page which contains the properties for continuous integration.
app_code\*.cs – the source code for the application.
bin\*.dll – the reference assemblies.

Soon you will find a detailed whitepaper on this sample on MSDN - till then have fun with the sample and feel free to let us know what do you think of this.

Some feedback on Team Build...and what do you think?

khushboo — Tue, 06 Dec 2005 17:08:00 GMT

I had almost written a blog on 'How to get comments on my blogs' asking for suggestions after fretting over the fact that I was not getting any comments or feedback on my earlier blog, when thanks to Chris (who sent me feedback through email cause he couldnt manage to post a comment) and Steve who helped me realise that at least someone actually reads my blog (yes - please take the hint and post comments [:)]). Before I become a complete cry baby - back to the point on Team Build...

As I mentioned earlier - Chris sent me an email and brought up some excellent points and feedback on Team Build which I would like to discuss and get more feedback and ideas on. Pasting his email below ..

--------------------------------------------------------

Sent: Saturday, December 03, 2005 5:33 AM

To: Khushboo Sharan

Subject: (Khushboo's blog) : Team Build Comments

Importance: High

You wanted some comments! ;)

I think CI is fine as sample. Then agian I don't use CI.

However you have some very basic things missing.

1. The fact that creation of Team Build project is one way and the only way to make changes is to edit the msbuild script in SCM is incredibly limiting. No one gets it right the first time. They frequently want to change settings etc. The code gen guys realized this long ago and have had to do a lot of work to always do the right thing.

2. Scheduled Build - There is no service to schedule a build and have it happen nightly. This is the number one reason folks need a team build, nightly integration builds! Yes I know I can use a command line to schedule it, yada yada yada. I bought a tool to do this I don't want to be figuring out obscure command lines to schedule my build!

3. I have yet to be able to figure out how to delete a team build or to delete reports from previous builds. Given #1 above I have many orphaned build projects created by folks that I can't figure out how to get rid of. Again probably some obscure command line tool to do this task but it should be in the UI.

4. There just isn't enough control over how the build is setup in the wizard you use to create the initial team build. Please give me more options here.

5. The fact that if I include an ASP.NET project in Team Build I have to go in and manually edit the build file to get it to build is hopefully a bug. If not it is unacceptable and will generate a lot of support calls.

6. I argued with one of the other build PMs about this. I hate the fact that I can only build solutions and not projects. Even the ASP.NET guys have realized their projectless nirvana was a bit misguided and are releasing a web development project type out of band. Let me pick projects. Multiples. Please don't limit me to solutions.

Thanks,

Chris

----------------------------------

This message was generated from a contact form at:

http://blogs.msdn.com/khushboo/default.aspx

---------------------------------------------------------------------------------------------------------------------------

Here are my views, thoughts or questions to you on each of these points and I definitely want to hear what you guys think about it

1. A much debated topic which I would love to get more views on. Help me understand the basic problem here a) Is this a purely discoverability issue where it is difficult for a user to figure out the fact that he needs to actually check out a file and edit that to make changes to the build type OR b) It is actually a pain not to have a UI for helping me edit this. The reason I ask is that from what I understand - its not a very common scenario to change a build type - Chris definitely has a point that it will take a couple of attempts to get the correct one but once it is in place you wouldnt change them often ..Or are there some other scenarios around this ?

2. Clearly my favorite [:)]. I fought for it in V1 and am again gearing up for V2 discussions. But then there are quite a few finer points to look at over here. Again is this feature clearly being missed because of a) discoverability - because yes it is definitely easy enough to get it working through the command line and then again how many times would you want to set this up - not regularly right? Again feel free to correct me if I am wrong - thats what I am looking for OR b) Is the whole Scheduled build issue a larget issue (as Nagaraj - a tech lead in our team interestingly pointed out in one of our discussions)..which brought us to a question - is 'scheduled build' just about scheduling a build to kick off at a particular date and time OR does it also mean having the ability to queue, prioritise, pick up machines from a pool and what not...the whole system in place rather than JUST the ability to start a build ...

So we want to hear from you - what is in your mind a 'Scheduled Build'?

3. Sure enough. We have heard from alot of folks on this - look at Anu's blog for a discussion around this. We are clearly working on providing more consistency between command line options and UI options post V1.

4. Hmm...this is an interesting one. So the question here is - what is 'enough' - ? We have thought about it alot - added more options, cut them and then again added some more and realised that its difficult to reach a state where one wizard fits all. The interesting point here is that no two build processes are same - so what is the best set of options which can cater to the most common build scenarios? We definitely need help from you guys on this one - what are those options that you clearly miss in Team Build wizard today?

5. Just to clarify we do not need to edit the build file (tfsbuild.proj file) for getting Asp.Net projects to work but I think what Chris is referring to here is the fact that the user needs to edit the sln file to get the paths correct today. Yes Chris - completely agree with you. This is a bug which we unfortunately couldnt get rid of in V1 but definitely in V2.

6. Actually this can still be done with Team Build today - you can build projects instead of solutions using team build. For doing this you need to edit the tfsbuild.proj file to add the project name and path in the SolutionsToBuild property. But yes we do not have a UI way of doing this - given this fact - what do you think?

But this list does not end here - I am still waiting to hear more from all those who have tried out TeamBuild or any other build automation tool even if they were homegrown ...while you guys read this blog ..I am rushing off to crack today's puzzle...wondering what it is ??Check out Ankur's blog and I bet you will be hooked on to this - BTW the school that's organising this event (ISB) is the school that I went to for my MBA and boy am I proud of it [:)]!!

Have you tried Team Build ?

khushboo — Fri, 02 Dec 2005 11:17:00 GMT

Now that we are on the final leg of shipping TFS - its time to sit back and look at what we have built all over again, hear from you and prepare for Vnext...It is indeed the most exciting part of the shipping cycle (my first experience, well I am almost a newbie to MS - been around for just about 2 years now - about all that n more later though :).

As the Program manager for Team Build its my job to get the best features in the product on time to you (dont go "Aha so she is the one responsible for this" and start killing me now) - so I got together with a bunch of folks to have a discussion on what next ? What are the "absolute must haves", what "should definitely become better", what are the "welll...maybe we should do it", what are "I think we are already doing good on that" features. Some of you have already been giving us loads of excellent feedback but I would definitely like to hear more. In case you cant think of anything (is our product so good ;)) let me get you started - so what do you think about CI being a sample and not 'in the box feature', ....the extensibility story, the usability and so on... Let them all come - the praises, the bashing, new feature ideas, tell us why you love Team Build and can use it, tell us what is stopping you from using it, randomn blabbering just about anything - come on..help us make the product better for you!!

Team Build Permissions

khushboo — Wed, 09 Nov 2005 11:39:00 GMT

Figuring out permissions is one of the most common stumbling points in the use of any new product where half the time you are trying to figure out – what am I doing wrong, why the heck is this feature not showing up, how can I get this damn option enabled and so on!

In case of Team build – again, this is one of the most common problems people have faced and various questions have been asked on this.

So let’s start at the very beginning…you have got a build machine ready and now you have figured out from all blogs and forums that you need to install something to get Team Build working in Team Foundation.

To setup a build on the build machine you need to be

a. An admin on the build machine

b. During setup you also provide a valid ‘build service account’. This is the account under which the build process will take place.

Build Service account permissions

Needs to be a member of the ‘Build Services’ group – this automatically gives this account all the relevant permission – remember the service account touches quite a few TFS parts as it goes through the build process
Also make sure this account has full access to the ‘drop location’ which you specified while creating your build type using the build type wizard. This is the location where your build binaries are dropped.
The service account also needs to have ‘Publish Test Results’ permission in case you want to include tests in your build process.
In case you are running webtests as a part of your build process, the build service account needs to be an admin on the build machine. But this is not recommended until and unless you are running webtests.

Build Type – Abhinab explains very well in his blog what exactly is a build type and how you can perform various actions on it. In this blog you get to know the kind of permissions you require to do all that.

To create a build type : You need to belong to a group which have the ‘Administer a build’ privilege AND you should have permission to checkin into the ‘Team Build Types’ folder in source control. This is designed in this way because build type files are actually checked into this folder and any edits requires the user to check out and checkin this file and of course we don’t want everyone in the team missing around with the build scripts do we?

Note : Often it so happens that you belong to two groups – say project administrator AND contributor. And if any one of the group has deny checkin permission enabled – then that overrides all other checkin permissions and you will NOT be allowed to play with the build type.

To edit/to delete a build type : Same as above
How to revoke permissions :In case you want to revoke creating/editing/deleting a build type from someone make sure that you deselect simply deny checkin permission to that individual using

Start a build All that you need is ‘Start a build’ permission to get this working.

Delete a build You need ‘Administer a build’ permission AND publish test result permission to delete a build. The publish test result permission is required because when you delete a build – all relevant test results are also deleted. Also please note that in case this build had test results associated with it, you also need to have ‘Publish Test Results’ permissions to delete this build.

Stop a build All that you need is ‘Administer a build’ permission to get this working.

View a build report This requires ‘View Project Level’ permission.

Edit a build Quality All that you need is ‘Edit a build quality’ permission to get this working.

Where is customaction.targets file in beta3 Team Build?

khushboo — Mon, 24 Oct 2005 12:28:00 GMT

If you have been using Team Build in beta 2 and have been brave enough to customise it :-), you would have come across CustomActions.targets file. This file was automatically created when you created a build type and got checked in. If you needed to customise your build steps - this is where you would need to plug in your custom task. Now - if you have further been brave enough to try out beta3 Team build - you would find this file missing.

No - its not a bug just that we have gotten rid of it simply because we did not see why we should not recomend the user to simply add his custom steps in the tfsbuild.proj file itself (earlier called TeamBuild.proj) instead of mantaining the overhead of yet another file. So in case you want to plug in your custom tasks in beta 3 - you can do this straight in the tfsbuild.proj file.

Just in case you are already used to customactions.targets or simply want to give it neat and simply by having a separate file for all your custom tasks - you can still create your own customfoo.targets file and import it in the tfsbuild.proj file and you will be good to go!

Whats new with Team Build and of course who am I !!!!!!!!!

khushboo — Thu, 22 Sep 2005 11:35:00 GMT

Beta 3 is round the corner and will soon be out of the door and definitely this is a good time for me to start my own blog – vooooooohhhooo!!! I am Khushboo Sharan and am a Program Manager at Microsoft working for the past year and a half on Visual Studio Team Foundation (the server component of Visual Studio Team System). I am not 'brand' new to the blog world and some of you would have read my initial blog on Team Foundation team blogs. Well – Ok, so what if I just wrote a few blogs and then kind of disappeared J! On all this and more later but today let me tell you what excites me the mooooooosst today –

Yup – with beta 3, out goes a bunch of new features and improvements in Team Build – never heard of Team Build? Do it rightaway !! Yes, this is a build automation tool being shipped with team foundation and does a bunch of things to automate your build process.

For those you have already tried out Team build and have given feedback, loved the product, hated it, got stuck with it – thanks a ton!!! Based on whatever we heard from you, we have done loads of changes to TB.

So here’s a list of whats new with beta3 on Team Build. Detailed descriptions for all these will follow. However here is a sneak peak –

- A brand new command line tool

This was definitely one of the top common asks in beta 2. Has commands for common operations like starting a build, deleting a build and aborting a build in progress(the last 2 being recent additions to the feature set of Team build). Check out tfsbuild.exe for getting your hands dirty.

- Improved detailed report UI

Much improved look and feel and yes not to forget a complete new ‘Build steps’ section which steps through each build step (live!!!) as the build happens

- Test Integration

This was kind of busted in beta 2 and you had to apply some tricks and tips to get this working. Moreover we did not have support for running all kinds of test. However with beta3 its all done up for you – you can run unit tests, load tests, webtests, ordered, generic tests as a part of your build process easily

- New webmethods

Earlier we had ‘get’ methods which would help you read data from our database and create say custom reports of your own. Well, we have done a bunch of things to polish these and other webmethods and have documentation support. Also, we have added a bunch of ‘set’ methods to help you write data into our database. So if you want to use your own build system (come on – give Team build a shot!!) you can still use that – push your data into our store and get the benefit of the build reports that we generate.

There is all this and much more that we have done in beta 3 with our product. Try it out as soon as beta 3 is out !! Let us know what do you think !!