Release Management within the Microsoft Solutions Framework (MSF)

The Microsoft Solutions Framework has very specific process guidance on release management. In the MSF for Agile Software Development process, you can break down release management tasks using the following steps:

• Execute a release plan - A release plan includes all the steps needed to successfully release the product, including scheduling quality assurance tests, creating a series of steps for your rollout (which you can document using work items), and so forth. By setting up your plan as a series of work items, you can then track the progress using a cumulative flow diagram (just like the project manager wanting to manage a software development effort). Some agilists would scoff at the idea of all this documentation and tracking. To those individuals, we can say that the work item database at the very least provides the benefit for a centralized area to manage your work items (much like story cards). The release plan could include the coordination of sales and marketing efforts, but should focus primarily on the delivery of the application to the target environment and the logistics around deployment.

• Validate a release - This phase involves final quality assurance (QA) on a release. You should test the release using customer or user acceptance tests and requirements validation tests. From a functional perspective, you can create a specific branch for testing the release and run regression tests on your unit tests. Basically, unit tests verify the fidelity of data coming in and out of your classes and methods. On a conceptual level, you can use unit tests to enforce business requirements. For example, if you are creating a credit card processing application, you can verify that the input contains only numerical data, has only a certain number of digits, has specific prefixes, and so forth. By incorporating business requirements as unit tests, you can run both regression and validation tests on the application. If bugs are found, bug work items can be created to forward to the rest of your development team.

• Create release notes - This is the documentation step that involves writing down the environment requirements, installation steps, new features, and bug fixes from the previous versions, known bugs, and limitations. If you are creating a commercial product (for example, a shareware application) the documentation is typically leveraged to create part of the marketing package for the software release.

• Deploy the product - This final step of the process involves creating a deployment package. If you are commercial software development company, you may need to create a master CD or DVD for your product to ship to a mass manufacturer.

The MSF for CMMI Process Improvement release management process has more complexity and auditing requirements to take into account. Figure 17-1 shows the release manager documentation in the CMMI process template.

Figure 17-1

The CMMI process template begins with entry criteria such as user acceptance tests, build, system test results, critical quality factors, and requirements. You need, for example, a stable build to establish as a release candidate (if it fulfills the customer requirements). The release management activities for MSF for CMMI Process Improvement include the following:

• Establish a user acceptance test environment - You need to set up a location and equipment to run your tests. This involves planning up-front to book the rooms and coordination with the operations team to get the needed resources.

• Establish validation guidelines - This step involves the establishment of a test plan framework (including test cases) to check the stability of the software and make sure it conforms to the customer's specifications.

• Select a release candidate - This involves selecting a stable build that will be subject to user acceptance testing (in other words, the build that most satisfies the customer requirements). You need to designate a set of functional exit criteria and validate the release against those criteria.

• Create a rollout and deployment plan - The rollout and deployment plan has a strong training component; it should include the end users, trainers, sales staff, helpdesk, and operations. A project management component involves a list of requirements for deployment, assessing risks and issues, and working closely with operations to capture the operational and management challenges before deployment.

• User acceptance testing - These tests allow you to evaluate the end product against the vision statement outlined at the beginning of the project. They also help you determine if the release fulfills a need in the market (in the case of commercial software), and meets the quality standards that are expected by the customer or end user.

• Analyze user acceptance test results - In this step, you are measuring your test steps against the tests. This includes critical-to-quality (CTQ) factors as determined by the customer. The CTQ are represented in a project as a series of scenarios capturing the customer requirements.

• Accept product for release - In this phase, you set up a meeting with all stakeholders to agree to a specific release and demo of the product. The easiest way to gain consensus is to get everyone to physically sign off on the release.

• Package product - You decide on the right packaging and sales approach for the product. It will differ based on the type of development project. If you are working on commercial software, it may be boxed or distributed online. In-house software development projects don't require packaging per se, and may only need a brochure explaining the core features to upper management. The exact makeup of the package depends greatly on the software being produced.

• Execute rollout plan - If you instantiate a rollout plan in work item form, all you need is to assign the tasks appropriately and work through them with your team. You can also track variation (much like a software development plan) to mitigate risks and issues in future rollouts.

• Create release notes - As in MSF for Agile Software Development, the release notes contain any upgrade details or bug fixes for the new release. They also provide installation information and a list of new features.

The exit criteria for the CMMI release management process are that change requests are generated for usability and testing, notice is created that a release is available in package form, the product is available, and the release candidate has been certified by the team in a milestone review.