Configuration Environment Architecture

Based on experience, as well an industry acceptance that development teams are construction driven and are always less focused to Software Process. This has been identified and henceforth the inspiration behind the proposed architecture, as a remedy, by keeping build management beyond developer’s domain.

Modern configuration environment is getting complex due to rising nature of applications to be distributed whereby they are dependent on their functionality on other applications. Such scenarios create enough complications of version control and matching, resulting in dire need of dedicated build management system integrated with the said configuration environment. Henceforth, in the proposed recommendations for Configuration Environment Architecture, Build Manager is an integral entity serving various requirements of configuration control, process and management.

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.

It minimizes integration risk. One of the greatest risks that a team project faces is that, when the different team members combine or "integrate" the code they have been working on separately, the resulting composite code does not work well. Depending on how late in the project the incompatibility is discovered, debugging might take longer than it would have if integration had occurred earlier, program interfaces might have to be changed, or major parts of the system might have to be redesigned and re-implemented. The daily build and smoke test process keeps integration errors small and manageable, and it prevents runaway integration problems.
It reduces the risk of low quality. Related to the risk of unsuccessful or problematic integration is the risk of low quality. By minimally smoke-testing all the code daily, quality problems are prevented from taking control of the project. You bring the system to a known, good state, and then you keep it there. You simply don't allow it to deteriorate to the point where time-consuming quality problems can occur.
It supports easier defect diagnosis. When the product is built and tested every day, it's easy to pinpoint why the product is broken on any given day. If the product worked on Day 17 and is broken on Day 18, something that happened between the two builds broke the product.
It improves morale. Seeing a product work provides an incredible boost to morale. With daily builds, a bit more of the product works every day, and that keeps morale high.

Development Teams

This is a group of roles directly involved in construction and development; constituting of designers, architects, developers etc.

Source Server

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

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.

Build Server (Build Manager)

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:

Create, Version and Deploy builds
Notify various managers of build availability and their status.

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.

Test Server & Test Virtual Machines

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.

Stage Server

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.

Production Server

Customer or Program Manager approved builds are deployed or provided in Production by Build Manager.

Conclusion

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, 2^nd ed., Steve McConnell and Article by Sharad Kumar

Posted on Wednesday, September 26, 2007 8:28 AM Build / Release , Technology Articles | Back to top