none
Increasing Speed of Team build

    Question

  •  

    Hi

     

          We have decided to incroprate the following changes to our build script

    • BuildSolutionsInParallel=False
    • SkipDropBuild=True
    • StopOnFirstFailure=True
    • SkipLable=False

    After changing this we got 10 Min diff. Is there any other key i can use to increase the build time. We are not going to use IncrementalGet as a policy.

     

    Is there a way i can switch off communication between TFS build server with TFS appserver while compileing. I don't want codechurn report based on this build. This build script is for purely checking integrity of source code.

     

    Thanks

    Balaji Devendran

     

     

     

    Tuesday, April 29, 2008 1:10 AM

Answers

  • See my other notes on how SP1 should decrease build time here: http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=3197812&SiteID=1

     

    In general, another thing you can do to decrease build times is to make sure that your workspace mappings are as targeted as possible - this will decrease the time spent (a) getting files from source control, (b) labeling files in source control, and, most importantly, (c) associating changesets and work items.  Since you are already skipping labelling, however, this will probably not help you very much.  Hopefully SP1 will get your server builds more in line with your IDE builds.

     

    Tim had some great advice in this thread as well - thanks for all your help on the forums lately, Tim!

     

    -Aaron

    Tuesday, June 03, 2008 1:06 AM

All replies

  •  

    >>We are not going to use IncrementalGet as a policy. <<

    Can I ask why?

     

    If you are not using this to prove you can build your software from scratch, you can define a separate build to that runs overnight with IncrementalGet = false.

     

    >>SkipLable=False<<

    Please be aware of the implications of this, one of which includes the build will not include any changeset information.

     

    Another thing you can do is set your projects up to build to a common directory (this already occurs on Team Build) and then set CopyLocal = false for project references.

     

     

    Tim Bassett

    Hound Dog Enterprises, LLC

    Tuesday, April 29, 2008 5:13 AM
  • >>We are not going to use IncrementalGet as a policy. <<

     

    Why because we have a custom task that unshelvs programmers shelve set before compilation. This why we are not using IncremetalGets in our build this will messup the workspace.

     

    >>SkipLabel=False<<

    We are fine with  changeset we don't want to do that also

     

    CopyLocal=False how it improves the build speed?

     

    Thanks

    Balaji Devendran.

    Tuesday, April 29, 2008 4:04 PM
  • >>Why because we have a custom task that unshelvs programmers shelve set before compilation.<<

    How does it merge code?

     

    >>CopyLocal=False how it improves the build speed? <<

    It does not have to copy dependencies, nor check their timestamps to compare.

     

    Tim Bassett

    Hound Dog Enterprises, LLC

    Tuesday, April 29, 2008 5:47 PM
  • Basicly build will fail. When there is a merge problem the user how requested the build will merge his changes with latest source code and que a new build.

     

    Is there a way to swich off. The communication between TFS Build server and TFS Server during the compilation.
    Tuesday, April 29, 2008 5:59 PM
  • >>Basicly build will fail. When there is a merge problem the user how requested the build will merge his changes with latest source code and que a new build. <<

     

    How long have you been using this methology?  What was the catalyst for it?  What were your other options?  I bring this up because it goes against a lot of best practices of CI, and I am worried it is not going to scale, nor lead you to a good place. 

     

     

    >>Is there a way to swich off. The communication between TFS Build server and TFS Server during the compilation.<<

    I don't know, but I don't think that would lead to good things.  ;-)

     

    Tim Bassett

    Hound Dog Enterprises, LLC

    Tuesday, April 29, 2008 6:17 PM
  • Hi Tim

     

    We are using this process from long time. We don't have other options now. Because this a process in our daily checkins. I think there is no good way to switch TFS Build server and TFS Server during the compilation.

     

    There is big diffrence in compilation timeing between a desktop build and TFS scheduled build.  Will you agree on this.

     

    Thanks

    Balaji Devendran.

             

    Tuesday, April 29, 2008 8:21 PM
  •  

    >>There is big diffrence in compilation timeing between a desktop build and TFS scheduled build.  Will you agree on this. <<

     

    I haven't done side by side comparisons, but we just try to structure things so it's fast on both, sometimes trading off one for the other.

     

    Our incremental builds are 10 minutes with over 1000 unit tests.

     

    How long is your build?

    How many developers do you have working on the source code?

    How many submissions do you have a day?

     

    Have you ever investigated task branching?

     

    Tim Bassett

    Hound Dog Enterprises, LLC

    Tuesday, April 29, 2008 11:19 PM
  •  

    >>Our incremental builds are 10 minutes with over 1000 unit tests.<<

     

    This is cool. So what i need to do get this timeing in my build.

     

    How long is your build?

    45 Min 800 Mb Source code. 36 Solutions.

     

    How many developers do you have working on the source code?

    We are having more than 350 Programmers working

     

    How many submissions do you have a day?

    Around 50 to 70 checkins

     

     

    Thanks

    Balaji Devendran.

    Wednesday, April 30, 2008 9:13 PM
  • I don't want to make you mad, nor have you think that I being judgemental.

     

    You just want it be faster?  But, how much faster?

     

    Let's say you cut 15 minutes off of your build?  Does that add any real value to your process? I have to wait 30 minutes, instead of 45 minutes;  that really doesn't allow me to build on every check-in.  Right now, you have 50 to 70 checkins, let's say a 12 hour day?  That's an under 5 minute build requirement.  Even if you have a 24 hour shift, that's a 10 minute build. 

     

    There's not much that can be done to get from 45 minutes to 5 minutes without some dramatic changes in either your build or source code architecture, probably both.  So, I want to try to help you, but sounds like you're pretty engrained in how you're doing things and I am sure there were good reasons for them at the time.

     

    What are you doing right now, rolling builds every hour?

     

    >>

    How long is your build?

    45 Min 800 Mb Source code. 36 Solutions.

    <<

    Do the solutions share projects (e.g. a project is in more than one solution)? 

    Do the solutions share outputs (e.g. a project reference the binary output from another solution)?

     

    Thoughts?

     

    Tim Bassett

    Hound Dog Enterprises, LLC

    Friday, May 02, 2008 5:13 AM
  • You just want it be faster?  But, how much faster?

    20 min is my idea time.

     

    Do the solutions share projects(e.g a project is in more than one solution)?

    No, We are refreing for a common output folder.

     

    Do the solutions share outputs?

    No, most of the our projects don't copy dependents to output folder.

     

    We are going to add more solutions soon. As our project is growing longer.

     

    Thanks

    Balaji Devendran

    Balaji.Dave@Gmail.com

     

     

     

    Saturday, May 03, 2008 12:29 AM
  • Blog entry of aaron Reduce build log noise was some thing i am looking for long time.

    http://blogs.msdn.com/aaronhallberg/archive/2008/05/05/orcas-sp1-tfs-build-changes.aspx

    Tuesday, May 06, 2008 9:36 PM
  • >>

    Do the solutions share projects(e.g a project is in more than one solution)?

    No, We are refreing for a common output folder.

     

    Do the solutions share outputs?

    No, most of the our projects don't copy dependents to output folder.

    <<

     

    Balaji,

     

    I don't understand, your answers seems almost contradictary.  Let me give an example.

     

    Solution A

    Project AA

    Project AB

    Project AC

    Solution B

    Project BA

    Project BB

    Solution C

    Project CA

    reference to AA.dll via a binary reference

    Project CB

    Solution D

    Project DA

    Project AA

    Project BA

     

    So you do not have anything like I show in solution D where it also contains a project from Solution A and Solution B, correct?

     

    You do have something like Project CA with a reference to AA.dll?

     

     

     

    Tim Bassett

    Hound Dog Enterprises, LLC

    http://ciontfs.com/blogs/tim/

     

    Wednesday, May 07, 2008 11:35 AM
  • See my other notes on how SP1 should decrease build time here: http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=3197812&SiteID=1

     

    In general, another thing you can do to decrease build times is to make sure that your workspace mappings are as targeted as possible - this will decrease the time spent (a) getting files from source control, (b) labeling files in source control, and, most importantly, (c) associating changesets and work items.  Since you are already skipping labelling, however, this will probably not help you very much.  Hopefully SP1 will get your server builds more in line with your IDE builds.

     

    Tim had some great advice in this thread as well - thanks for all your help on the forums lately, Tim!

     

    -Aaron

    Tuesday, June 03, 2008 1:06 AM