Rules to Better Branching And Builds

Microsoft Gold Partner Logo
Search Go Search
SSW Rules/Management/Rules to Better Branching And Builds

 Rules to Better Branching And Builds

Hold on a second! How would you like to view this content?
Just the title! | A brief blurb! | Gimme everything!

  1. Do you check your Workspaces when defining a new build?

    When defining a build, you should always check the Workspace tab. Only the workspace relevant to your build should be included.
    ​
    If you have a number of Team Projects open from the same TFS Project Collection, all of their workspaces will be included by default.  You should remove those workspaces that aren’t being used otherwise the build server will get the source for every workspace in this list before starting a build.
     
           Figure: Bad example – Several workspaces from other team projects are included by default
     

      Figure: Good example – Only the relevant workspace has been included in this build definition
    Read more about Do you check your Workspaces when defining a new build?

  2. Do you know the minimum builds to create on any branch?

    When creating projects one of the only ways that you have of proving that it works and is a viable solution is to build it. This is easy when you only have one developer and that developer will be the only one using a solution. But what if you have 2 developers? How do you prove that one developer's code works with the other? The answer is build servers. These build servers take specific code away to another computer and build it there.

    You should always have three builds on your team project. These should be setup and tested using an empty solution before you write any code at all.

     Figure: Three builds named in the format [TeamProject].[AreaPath]_[Branch].[Gate|CI|Nightly] for every branch. These builds should use the same XAML build workflow; however you may set them up to run a different set of tests depending on the time it takes to run a full build.
    • Gate - Only needs to run the smallest set of tests, but should run most if not all of the Unit Test. This is run before developers are allowed to check-in (a gated Check-in)
      Note: This build should take no more than 2 minutes otherwise developers will get annoyed!
    • CI - This should run all Unit Tests and all of the automated UI tests. It is run after a successful developer check-in.
      Note: This build should take no more than 10 minutes to run.
    • Nightly - The Nightly build should run all of the Unit Tests, all of the Automated UI tests and all of the Load and Performance tests. The nightly build is time consuming and will run but once a night. Packaging of your Product for testing the next day may be done at this stage as well.
      Note: This build can take as long as it needs to - of course more than 24 hours is too long.
    Figure: You can control what tests are run and what data is collected while they are running. Note: We do not run all the tests every time because of the time consuming nature of running some tests, but ALL tests should be run overnight.
    Note: If you had a really large project with thousands of tests including long running Load tests you may need to add a Weekly build to the mix.
     Figure: Bad example, you can't tell what these builds do if they are in a larger list Figure: Good example, you know exactly what project, branch and type of build these are for.
    Read more about Do you know the minimum builds to create on any branch?

  3. Do you know that branches are better than Labels?

    Although labels are useful they can be changed after they have been created with no way to tell that they have been changed.

    Figure: Bad example, labels can be edited after the fact (they are mutable)
    Figure: Good example, branches give absolute certainty of versions (they are immutable)

    Fact #1: Creating a branch of 1GB of source code does not increase the size of your database by 1GB. It just adds a bunch of pointers. Only the differences are actually stored.
    Fact #2: When you delete a branch it is not really “deleted”, you are just ending the history. You can undelete at a later time.

    Tip: Find deleted items by ticking “Tools | Options | Source Control | Visual Studio Team Foundation Server | Show deleted items in the Source Control Explorer”

    Read more about Do you know that branches are better than Labels?
......