Build Server

Every enterprise has its own software development practices that cover how developers update code, how changes are tracked and tested and how new releases are created. We generally expect that whatever practices have historically worked within an organization will continue to work for the implementation of this application. However, a build methodology was developed that has worked well for managing concurrent changes to the application that is based on the following principles:

• All of the application should work all of the time. Therefore, changing one small part of the application requires that all of the application be retested.
• Bugs are more expensive to fix the longer they stay in a system. This principle has been proven time and time again in software engineering. This truth mostly owes to the fact that it is easiest to find the offending developer immediately after he or she broke the system and also that developer has less recollection of how and where the system was broken as time goes by.
• In a complex system malfunctions can occur "far away" from the points of code modification. It is unreliable to expect selective retesting based on what was likely to malfunction to find the all the places of actual malfunction.