Chapter 5 - Stabilizing the Build System
On This Page
.gif){kind=icon}
Introduction and Goals
Testing the Solution
Conducting the Pilot
Introduction and Goals
The purpose of the Stabilizing Phase is to improve the solution quality to a level that meets the acceptance criteria for release to production. The team completes tasks and creates deliverables toward this end. Although unit testing was conducted as the migration was being built, testers conduct testing during this phase on a UNIX build system migration solution whose features are complete. Stabilizing Phase testing emphasizes usage and operation under realistic environmental conditions. The team focuses on resolving and triaging (prioritizing) the bugs that Test discovers and on preparing the solution for release.
The phase culminates in the fourth major milestone, Release Readiness Approved. Passing the milestone indicates team and customer agreement that all outstanding issues have been addressed and the solution is ready to be released into the production environment. In migrations where the build migration is not a separate team, the Stabilizing Phase will not have a major milestone — there is no Release Readiness Approved milestone. However, the build system will be released to the end users.
When a build has been deemed stable enough to be a release candidate and preproduction testing is complete, the team deploys the solution to one or more pilot groups in the production environment.
The two major Stabilizing Phase tasks that are relevant to build migration projects are:
Test the solution
Conduct the pilot
The content of this chapter provides the technical information needed to enable teams to accomplish the Stabilizing Phase tasks and reach the Release Readiness Approved Milestone. Refer to the UMPG for general project guidance on how team members and work processes should be organized to complete this phase and meet the milestone.
Testing the Solution
After the build system builds the code in the sample site and has all features implemented, it is time to run the other tests from your testing plan, including whatever benchmarking and performance tests you have planned.
However, the build system at this point works only with a known set of inputs. Because your sample build source is only test data, you need to extend the range of test data, which means introducing more application source code. You can do this in either or both of the following ways:
You can copy some new part of the application source code into your sample site and work from there.
You can offer this version of the build system to the application migration team to try on a subsection of the application.
When the targets in the sample site are building correctly, you can take the solution to a larger set of source with the help of the application migration team. This is not a pilot of the solution; it is an attempt to expose the solution to less controlled input.
In some environments, these trials are patched and fixed: parts of the build system are upgraded and added to make the system work in this case. While this is understandable, remember that in the end you need something that can be deployed and installed.
On a regular basis, the team should attempt tests of their deployment package, whatever it is, including installation on a fresh computer. The testing during this phase should allow you to ensure that all of the quality criteria set out in your test plan have been met.
Conducting the Pilot
The pilot is an opportunity to test the documentation, the deployment approach, and the build system. This is also the point where unusual interactions may show up.
Testing the technology is an important part, but it is just as important to record the shortcuts that developers take while using the pilot system. A shortcut indicates a missed item in an analysis, a requirement that was not captured. That requirement should be identified and prioritized. Determine whether this missed requirement is something that should be added before release to developers.
If the application developers are doing the build system migration themselves, you may not have a clearly-defined pilot. The build system will move almost imperceptibly from the sample application into the production environment in the iterative development cycle mentioned in the "Building Phase" chapter. The danger of this approach is that the system will accumulate unrecorded changes to scripts and the environment. An individual developer's version of the build system starts to diverge from the standard product and will become something that cannot be deployed for other groups later. The process of updating the deployment mechanism waits until some new employee is brought onto the team and days are lost trying to get the build system working correctly.
If your build teams are not doing a pilot, they should do a regular check in which their build systems are backed up, scrubbed off, and then reinstalled using the latest deployment package and documentation. This serves as a useful reality check.
When the application team on the pilot is satisfied with the build system and their problems have been addressed, you can proceed to deployment.
Download
Get the Solution Guide for Migrating UNIX Build Environments
Update Notifications
Sign up to learn about updates and new releases
Feedback