1. Confidence in your ability to deploy your software is best achieved by executing a private build before a commit to catch and prevent issues. It is the first and most important quality gate/check point. We should be continually trying to catch issues as early as possible and shift left.
2. Reduce risk. Completely unrelated issues often appear after making even a simple change. That risk is higher in large enterprise applications and especially for any new developers on the project. Requiring your developers to verify the stability of the software project prior to every commit reduces that risk.
3. Ability to deploy quickly. As a software development team, you should be able to get a fix or feature into the hands of your users as quickly and with as low risk of failure as possible. It is your team’s best way to deliver high quality and maintain velocity.
4. Save time and money. If a an issue that could and should have been caught prior to a commit is missed, it could potentially impact the entire team. At a minimum, it impacts the time and cost of resources that were unavailable and busy deploying and testing the application.
5. Commit small, early and often. The smaller the change definitely means the smaller the risk. The larger the team and the larger the change both exponentially increases the risks. Stub your code and/or wrap it with a feature flag/toggle to help get it into your team’s hands as quickly as possible. Make sure you maintain and run your tests.

References & Resources

1. What is a private build?
2. Using psake for Private and Integrated Builds – Powershell
3. Cake – C#
4. Fake – F#
5. Rake – Ruby