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 two builds on your team project. These should be setup and tested using an empty solution before you write any code at all.
Figure: Two builds named in the format [TeamProject].[Areapath]_[Branch].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.
Reminder: The same build rules apply to 'release' branches as the 'trunk' branch. Review our rule Do You Know When To Branch? for more information on the best branching strategy.
Important: Gate Builds are bad! Some people believe in having a build that stops developers checking in code unless the build succeeds. See our rule on Do You Know That Gated Checkins Mask Dysfunction?
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