Share via

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

  • Article

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:

https://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 [:)]!!

Comments

  • Anonymous
    December 07, 2005
    Yeah! Comments are working!

    1. I think it is B. Many of my devs aren't MSBuild experts. Even if they were I don't want them having to become experts on the msbuild file you generate. That is what tooling is for.

    2. I think the minimum bar is being able to schedule it, look at the results, resubmit it, etc. Nagaraj has great ideas but I think they are more applicable to Team Build as a whole. i.e. when my developers during the day want to kick off a build being able to queue, etc becomes more important.

    3. Anu shows me how to delete a report from a build I believe but not the actual Team Build node that I created. i.e. a now orphaned option due to bad choices in the wizard.

    5. Actually what I was talking about was the Any CPU vs x86 vs .NET change that is required in the msbuild file for the build configuration before an asp.net web site will build. The options the wizard puts in don't appear to work for ASP.NET projects.

    6. Back to editing the tfsbuild.proj file.

    To sum up. Anything which is answered with, "Just edit the tfsbuild.proj file" should trigger the thought, "This might be the wrong answer..."
  • Anonymous
    December 07, 2005
    Thanks Chris yet again for the feedback and your views on this. We are definitely looking at fixing most of these issues in V2.

    BTW for point 3 you mention - are you talking about deleting team build types and not team build? If yes, then I agree we missed on providing a UI way of deleting built type which I agree is kind of bad. While we make sure we get it in for V2 - I am sure you already know that this can be deleted and gotten rid of by deleting the team build type folder that was created in the source control system. You can find the folder under $/your team project/TeamBuildTypes folder. Once the particular team build type folder is deleted it will no longer appear in your team builds node in team explorer

  • Anonymous
    December 21, 2005
    Hi Khushboo,

    I just wanted to put my quick 2 cents in on team build. I think its a great thing and everyone should use it, but I'm going to go with the crowed and say that a nightly or continous build should be built into the UI. It's true that once one of these are set up that it might not be changed much, but it's just such a hasle to get that far. Plus some teams, like the one I work in, might make a new branch every couple of weeks. Wouldn't we have to make a new team build for each branch, or go into the .proj file and change things for that build?

    Other wise I'm lovin the new VS 2005 and keep up the good work. I know its hard to come up with everything, and please everyone.

    Eric
  • Anonymous
    December 21, 2005
    The comment has been removed