Daily Builds - is it possible ?

Daily Builds - is it possible ?

• farah

  Hi,< xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />

   

  Thanks for the query and the good suggestions.

   

  Does the build feature in VSTS allow only daily builds  

  -You can use Team Build in whatever frequency that suits you; you can kick off a build manually using VSTS, use Windows Task Scheduler to schedule a 'daily'/'nightly'/'weekly'/etc build; or you can invoke the XML Web Service remotely to fire one up.

   

  Can we do a build when a certain number of lines of code has been added newly

  - Yes, what you want to do is read the 'checked in' event and examine what is being checked in, if it matches your threshold, you can kick off a build using any of the methods described above

   

  Can we do a build when new features are added  

  - Yes, same idea as above, read the 'checked in' event - this event has the following associated information -what files are being checked in, check in comments, check in notes, associated work items, team project, access to VS global services

   

  Does MSF require daily builds

  - MSF for Agile Software Development requires a daily build and more frequently if resources allow it.

   

  Can we do a build when any change occurs (hardware/software updates are done)

  -         Good question. If you can program the Windows events/updates for the hardware/software changes, you can achieve this as well.

   

  < xml:namespace prefix = st1 ns = "urn:schemas-microsoft-com:office:smarttags" />-Bindia Hallauer

  Senior Product Manager

  Visual Studio Team System & MSF

  
  

• yassir

  Vinothkumar,
  
  In my experience daily builds are possible and very desirable.  A big problem that I have encountered as a developer and team lead is check-outs of code that span days, weeks and even months.  This sort of practice is found all too frequently in immature organizations where the rule may be not to check-in and build until the feature being worked on is complete.  This exposes the codebase to loss if local changes are lost, leads to integrations problems late in the cycle, and prevents tracking of what is complete.  By doing check-ins and builds daily the changes for any cycle are small so integration problems are reduced, potential loss is minimized and changes can be tracked better.  The rule for the developer is that changes must not break the build, not that everything must be finished on the feature being worked on.
  
  Doing this is not hard in modern environments where hardware and compilers are fast and build utilities are widely available.  It does not reduce the creativity of the developer at all.  On the contrary, knowing that you have a working system at the start of each day is very liberating.  Rolling back a few hours of changes is an annoyance at most; rolling back days or weeks of work is usually not an acceptable choice.
  
  I've been successfully practicing short cycle development practices for almost 20 years now and I encourage you to give it a try.
  
  

• JamesChan

  In message 
  <243c7c7b-4620-4051-a935-62b80d9f8afb@discussions.microsoft.com>, 
  vinxter@discussions.microsoft.com writes
  >hi ,
  >
  >Thanks for the comments.
  >
  >Currently My team is trying to for Daily builds and run regression
  >tests every day.
  >
  >But one problem is , the codebase is split in three places..
  >We have to check in the code in South Asia... The team in SouthEast
  >asia will check in their code and finally people from U.S. check in the
  >code and build has to take place there in U.S.
  
  So why not consider virtual build labs: each day, have the team in South 
  Asia build their own version of the product locally, run regression 
  tests, etc. Then, once the code is validated on a private build lab it 
  can be integrated back to the main build 
  
  >With this scenario , there are problems with time to start automated
  >builds... It should be end of day for all teams .. But end of day in
  >China is half day in india and end of day in india is start of day in
  >U.S.  It takes hours to build. [:)]
  
  Have multiple build labs 
  
  
  >This would require us to Merge the code daily in three places .
  >Globalization ... u cant live with it , u cant  live without it [:D]
  
  LOL - take a look at how MS manage Windows. They have not totally 
  dissimilar problems!
  -- 
  Thomas Lee
  (tfl@psp.co.uk)
  
  
  
  
  
                                              
  

• XiaoFeng

  What about the case when a developer is in the middle of coding a feature enhancement And it will break the code at the point that s/he has coded upto at the end of the day
  
  Daily builds is something I would love to setup for my team, just want to look at all the different scenarios.
  
  Also would one of these daily builds be the same that goes to Test, Staging and eventually to production
  
  Is there any documentation out there for doing this daily build process and especially in relation to deployments to the various levels
  
  I guess that's enough questions for now.
  
  Thanks,
  JGP

  
  

• StevenBerr

  Here are some resources that can answer to your questions:
  "Windows XP Whistler Daily Cycle" http://www.only4gurus.com/v3/downloadcount.asp id=7662
  "21 Rules of Thumb – How Microsoft develops its Software" ttp://blogs.msdn.com/David_Gristwood/archive/2004/06/24/164849.aspx

  
  
  

• Brent Rector

  You can alternatively use Build Manager system at http://republika.pl/dailybuilds
  
  This distributed across machines system just help you with daily builds and co-work with VSS automatically for auto labelling and versioning solutions.
  
  Requirements:
  .NET Framework 2.0 beta 2
  C++ Builder / Delphi (soon .NET compilers also)
  Visual SourceSafe (optionally when automatic labelling and code fetching)
  
  You can sign-up there and receive trial license to use daily builds now.
  
  

• jrenton87

  hi ,
  
  Thanks for the comments.
  
  Currently My team is trying to for Daily builds and run regression tests every day.
  
  But one problem is , the codebase is split in three places..
  
  We have to check in the code in South Asia... The team in SouthEast asia will check in their code and finally people from U.S. check in the code and build has to take place there in U.S.
  
  With this scenario , there are problems with time to start automated builds... It should be end of day for all teams .. But end of day in China is half day in india and end of day in india is start of day in U.S.  It takes hours to build.
  
  This would require us to Merge the code daily in three places .
  
  Globalization ... u cant live with it , u cant  live without it
  
  Thanks
  vinothkumar
  
  
  

• Philipp Lenz

  In message 
  <4381a0ab-f26c-4780-820d-f8bde1075985_WBRev2_@discussions.microsoft.com>,
   "anonymous@discussions.microsoft.com" 
   writes
  >This post has been edited either by the author or a moderator in the
  >Microsoft Forums: http://forums.microsoft.com hi ,
  >I have seen the word daily builds in MSF docs.
  >Is this really possible in a real world  
  
  Yes.
  
  At MS (at least when I worked there), the windows team did daily builds. 
  It was the rhythm and heartbeat of the project. You could tell how well 
  things were going by the quality of the builds.
  >
  >How small the project may be , it would still be difficult to do a
  >daily build.
  
  Depends but generally, you should be able to do something. My blog is 
  something that tries to have a daily build .
  
  >As a programmer , if im doing some work , i cant give out a completed
  >code in one day . Solving some issues would take more than a day . If
  >no new code has been updated daily , then why do a daily build . That
  >would be waste of resources .
  
  If it's a single developer project, you have a point. But even then, 
  there usually _something_ you can build in.
  >
  >I think, the builds would be done based on more appropriate factors
  >like
  >do a build when a certain number of lines of code has been added newly.
  >do a build when new features are added.
  >do a build when any change occurs (hardware/software updates are done)
  
  All of these are important too - but to some degree, with enough 
  developers someone hits these metrics every day. ;-
  
  >The combination of these kinds of variables would give a much more
  >efficient build schedule instead of daily building. Also daily builds would put more pressure on the programmer and  reduce the creativity ,
  >experimentations of the programmer.
  
  Daily builds get to be a norm - you are seeing constant improvement 
  every day. Yes, it puts pressure on the team but it's useful IMHO.
  
  Thomas
  -- 
  Thomas Lee
  (tfl@psp.co.uk)
  
  
  
  
  
                                              
  

• Daily Builds - is it possible ?