Every file is compiled, linked, and combined into an executable program every day, and the program is then put through a "smoke test", a relatively simple check to see whether the product "smokes" when it runs. Project Server/Manager gets early notification of “smoke”. This simple process produces several significant benefits.
This is a group of roles directly involved in construction and development; constituting of designers, architects, developers etc.
Source Server is the source-code repository for version-control. This is the server that is the feeding ground for day-to-day development across projects. Suggestively, this isn’t just a single version-control, but could be a group based on implementation and process management requirements.
Project Server is the hosting environment for latest / recent builds submitted by Build Server. This environment is in feedback-loop with Build Manager, whereby each scheduled build is notified of its success status and possibly even hosted on the Project Server to re-affirm the changes being expected in respective build. This ensures early notification of broken integration, and hence early rectification.
This is a Build Management repository, ideal for continuous-integration, smoke testing etc., engaged in continuous and scheduled build management. Notably, this runs on a scheduler which extracts source from Source Server and builds in its environment, mostly resulting in binaries. Resulting builds are versioned and stored on its version-control environment. This not only reduces integration risks of Source Server, but also facilitates early notification to project team of broken integration-builds. Ideally, this is closely controlled and managed by Build Manager.
Build Manager could be a Toolset, Process or a group of role, based on technical feasibility of the environment and platform. The capabilities expected are:
Initial look at Build Manager might seem like a management over-head, but it goes a long way in segregation of Development, Testing, and Project Management. The intent is to automate most notification and build management tasks. Build deployment on various life-cycle servers could possibly be manually controlled.
There are various advantages of separating Build Server and Source Server in the life-cycle and running scheduled builds:
1. Static Code-Analysis: While generating scheduled builds, source-code could be statically analyzed and reports be made available to Project Team of the issues there-in, reducing code-review and feedback timelines and dramatically enhancing code-quality.
2. Code Documentation: Source-Code documentation can be generated for each corresponding build and versioned along-with. This shall ensure that we have actual mapping of source-code vis-à-vis source documentation. Availability of CHM/HTML docs for each version shall be a boon for developer/project-team reference. Project Manager can henceforth manage/ensure duly documentation.
3. No dependency on Development Team for builds: There shall be no need for Binary builds to be provided by development teams.
4. Focused teams, enhanced productivity: Clear segregation of tasks, and letting development team focus on construction rather than process life-cycle shall enhance productivity.
It is the hosting environment for selective builds hosted by Build Manager, based on build notification received by Project Manager or based on the defined process. This environment is not just a single box to host applications, but also constituted of Test Virtual Machines to support varied configurations required for testing.
Successful builds are notified by Test Manager to Build Manager, which are henceforth deployed on staging based on corresponding process definitions & program manager requirements. Prime subscriber’s of this environment is Program Manager or Customer.
Customer or Program Manager approved builds are deployed or provided in Production by Build Manager.
Proper setup of Configuration Environment as per this recommended architecture and with implementation of Build Management System, will not only reduce complexities of application distribution and release management, but will also help in controlling versions of release and will automatically setup an environment which will directly put processes in place thus making releases absolutely reliable and fail-proof.
References: Code Complete, 2nd ed., Steve McConnell and Article by Sharad Kumar