Software Release Planning Guide and Plan Template
This page describes a proposed policy for organising the production and deployment of successive software releases within any organization.
This plan presents a proposed policy for iterative software releases including milestones, time-scales and supporting techniques and tools to be employed.
Scope of Software Release Plan
This plan concerns the technical co-ordination of the software releases by any Organization. It has a consequence on the manner in which the software developed by developers, integrated by release management and tested by testing group.
Role of the configuration manager
It is the role of the Configuration Manager to organise and oversee the software release planning of the projects in consultation with the project management, developers. These tasks include:
- Proposing a software release policy and procedure to drive the development of each software release;
- Defining a software release calendar including release dates and content outlines;
- Organising a forum so that technical issues involving multiple developers can be addressed;
- Working with the Project Managers to ensure developer specific work-plans are harmonized with overall project plans.
- Establishing with developers a basic software infrastructure and toolset to facilitate software development, integration and testing;
- Tracking the progress of the work to ensure the software release schedule progresses as smoothly as possible.
This plan provides an overview of the proposed approach for many of these tasks.
The proposed procedure for the planning and deployment of successive software releases is intended to ensure development remains focussed on the highest priority issues and to improve the manner in which subsequent releases are produced.
The software release procedure is composed of the following steps:
- Coordination meeting – project participants provide feedback on the previous release and develop a basic work-plan for the next software release.
- Software Release work-plan coordination – the Configuration Manager consults with the Project Managers and takes the output of the coordination meetings to establish an overall plan for the next release.
- The developers integrates the middle-ware and external software packages and testers perform integration tests.
- An integrated software release is made available to the end user for acceptance testing.
- The release roll-out is accompanied by documentation for the end users and software developers. A meeting is hosted by the developers to present the contents of the new software release and indicate the changes made since the previous release.
In order to support more frequent software releases, a number of tools and techniques need to be put in place by developers. Such a toolset will provide a convenient, standardised, project-wide mechanism for building, distributing and documenting the software. It is important that all the developers adopt the toolset as early as possible.
As a means of providing feedback on integration issues to software developers in each project as early as possible, mechanisms to automatically build, test and document all the software on a daily basis will be put in place. A development testbed consisting of a few PCs is required to support iterative development, integration and testing without interfering with the testing activities performed by the testing team.
Software release planning
Frequency of Releases
Frequency of releases depends on the actual project completion time defined in the project plan. Adding more releases to the project plan increases the total work-load for the developers and testing team alike but allows more frequent feedback to ensure development concentrates on the most relevant points and reduces the time required for the integration phase of each release. One of the goals of the proposed approach is to maximise the advantage that can be gained from iterative software releases while reducing to a minimum the extra work required.
Given the size of the project in terms of software packages and groups of people involved, the following iterations of software releases between testbed 1 and testbed 2 are proposed:
- Testbed 1
First integrated release produced by the project
- Release 1.1
Contains bug-fixes, modifications as a result of feedback from use of testbed 1 and first use of release infrastructure by the middle-ware
- Release 1.2
Contain bug fixes, modifications as a result of feedback from use of the previous releases by applications, further use of the software infrastructure by middle-ware packages and extensions/improvements foreseen by developers.
- Testbed 2
A similar release schedule will be planned for the period between testbeds 2, 3 & 4 at a later date when more experience has been gained with iterative releases.
In order to support more frequent software releases, a number of supporting tools and techniques need to be put in place. A sub-set of such tools and techniques are already deployed by developers to support the testbed 1 of the project. developers are responsible for establishing and managing the toolset.
The developers plays a vital role in the production of software releases. In order to support more frequent software releases the developers must continue to be active between the scheduled testbed integration phases.
developers had already put in place a number of tools and techniques to ease software integration and the production of the software release for testbed 1. These include a code repository (CVS), related tools for software browsing and an incident tracking tool (such as an IR manager). Further steps can be taken to reduce integration effort by catching potential conflicts earlier in the development cycle. Such measures, as with the software itself, will be extended with each release and subject to more detailed planning
Centralised Code Repository
Many of the tools and techniques foreseen within the software infrastructure are linked to the use of a code repository. In the build-up to testbed 1, developers have committed the changes to source code to the cvs repository.
This repository will act as the core facility on which the automated building, testing and documentation tools will be based. It is essential that all developers adopt the code repository as an integral part of their daily working practises. Sustained software development without committing modifications to the repository for extended periods (weeks) will undermine the functioning and value of the build procedure.
It is expected that detailed documentation including API descriptions, class hierarchies and dependencies can be extracted from comments in the source code and by auto-documentation tools. More high-level documentation will still need to be written by hand. All documentation, both extracted and hand-written, will evolve with each software release. To ensure users get the correct version of the hand-written documentation for a software release it will be necessary to archive the documentation, preferably in the same repository as the code itself. This implies using documentation formats (e.g. separate latex, Linux Doc, SGML, POD or JavaDoc etc. style documentation files) that lends themselves to archiving tools such as CVS. Consultation with the developers and investigation of the possibilities supported by the toolset is necessary to reach agreement on appropriate formats.
A development testbed is required in order to support iterative development, integration and testing without interfering with the validation activities performed by the testing team. The daily development versions of the software can then be tested on this facility. The development testbed will be managed by developers.
Recommendations including guidelines/templates and examples for the use of tools and techniques to support automated building, testing and documentation should be defined. Such a toolset will provide a convenient, standardised, project-wide mechanism for building the software and documentation. It is important that all the developers adopt to the toolset as early as possible.
- mark-up techniques (e.g. Javadoc style comments) for document generation from source code
- IR manager for problem reporting and tracking
- coding style recommendations (coding checklist)
The tools at the top of the list are the highest priority to make them available to the developers.
Project Manager should ensure setting up of such tools and techniques. In this manner, developers can concentrate on exploiting such tools and techniques in their daily work without worrying about the installation and support issues for the tools they use.
This section outlines the software testing procedures foreseen within the project. The basic approach is to address software testing in a bottom-up manner via three distinct phases:
- Unit tests
Performed on individual software modules of a WP to test their basic functionality
- Integration tests
Performed on integrated software components from all developers to verify their correct inter-operation.
- Acceptance tests
Performed using application groups’ applications and test scenarios. The acceptance tests correspond to the validation tests currently being organized by testing team.
To drive the testing procedure a set of testplans are required. The testplans outline the goals and priorities of the testing and list the set of test scenarios foreseen to meet the goals. A description of the tests to be performed for each phase should be documented in the test-plans.
For unit tests, it is the responsibility of the developers to produce a test plan document based on the recommended template. Each developer should produce one testplan. The project test plan should include details of testing individual software modules and their integration within the project.
A separate test plan for the project-wide integration tests is to be produced by developers.
Documentation for acceptance tests is already foreseen as part of the project deliverables.
The three phases of the test procedure are to be performed for each release of the software delivered to the testing team. The details of each testing phase are described below.
Unit tests address the basic functionality of a single work product. They are to be provided and executed by the developers on their own machines or the development testbed before delivering their software to developers for integration. The individual tests should make use of the test harness software to be provided as part of the toolset and may need to simulate services provided by other developers according to the build dependencies. A subset of the unit tests should be run as part of the build procedure.
Details of the unit tests should be documented as part of the individual work product test-plans. Sufficient documentation should be provided to allow other people (i.e. not the developers) to execute the tests and interpret the results.
The integration tests verify successful integration of the middleware developed within the project and underlying external toolkits. Integration tests are executed on the development testbed whenever new software for a release is received from developers and built by developers. Their development (though they may be gathered from elsewhere), management and execution is the responsibility of developers.
It is expected that the set of test scenarios should be expanded as the project gains more experience with the software and requirements from the users.
Initially the test scenarios will be run by hand but it is hoped that a subset can be automated (e.g. via scripts etc.) once their usefulness has been proven and integrated as part of the build procedure.
Details of the integration tests should be documented as part of the developers test-plan.
Acceptance tests are to be performed in conjunction with the end user using scenarios provided by the users. Such tests are to be executed on the testbed machines. The definition of the test scenarios and their execution is the responsibility of the end user and will be supported by the developers. The acceptance tests correspond to the validation tests which will be organized by testing team.
Software Release PROCEDURE
A well-defined procedure related to the planning and deployment of successive software releases will be established.
As part of the software release production procedure, there must be the opportunity for all the stake holders involved to provide feedback on the software and the release procedure to ensure development remains focussed on the highest priority issues and to improve the manner in which subsequent releases are produced.
The planned contents and schedule for subsequent releases should be reviewed by the Project Manager to ensure the plan remains as accurate as possible.
An overview of the proposed software release procedure is described below as a sequence of steps:
The purpose of the coordination meeting is to allow the project participants to provide feedback gathering their experiences from working with the previous release and outline a work-plan for the next software release. It should be scheduled after the previous software release has been deployed and used by the applications groups but long enough before the next release to enable its findings to be taken into account. The product of the coordination meeting should be an appraisal of the previous release’s quality and suitability including how it has been used and a prioritised list of requested modifications/extensions from the next release.
The coordination meetings will be organised by the Configuration Manager and are open to everyone involved in the project but the participants should include:
- Project Managers
- Testing Team
- System Administrators and Network Administrators
- End Users
The agenda for the coordination meeting should include presentations by each of the end user, testing team and the developers with sufficient time for discussion to establish a list of agreed priorities for the next release. The plan for the next release should include:
- software components to be included along with their modifications/extensions relative to the previous release;
- operating system and compiler versions to be part of the reference platform;
- versions of external toolkits and supporting packages to be used by all developers.
All developers should remember that their input must be collated with the other developers and hence relative priorities may change in order to establish the most suitable plan for the project as a whole.
In preparation for the coordination meeting, it is assumed that each of the developers will hold internal meetings to gather input from their members and clarify their position.
Developers should also hold a preparation meeting where the developers may raise release production issues and make suggestions about how to simplify or improve integration for the next release.
Software Release work-plan coordination
The Configuration Manager will, in consultation with the Project Managers, take the output of the coordination meetings to establish an overall plan for the next release. The overall work-pan will be published and made available to all participants of the project.
The rest of the software release procedure should be similar to that used for testbed 1:
- The individual developers should perform unit tests before it is submitted to testing team. The proposed development testbed can be used for this purpose. The submission of the software should be made via the code repository and clearly tagged for subsequent retrieval.
- The developers integrate all the source code from all the developers. Basic integration tests are performed. The integration step is deemed to have been successfully completed when a stable version of the software passes the integration tests as defined in the test-plan. During this time the associated documentation for the release (including release notes) is prepared by developers.
- An integrated project software release is made available to the end users’ testing team for acceptance testing. During this time the developers are available for consultation and support of the new release. The acceptance-testing phase is deemed to have been successfully completed when the set of test scenarios defined by the end users execute correctly.
- The release rollout is accompanied by documentation for the end users and software developers. A meeting should be hosted by the developers to present the contents of the new software release and indicate the changes made since the previous release.
A build is the phenomena of constructing usable software from original source files. Following key practices are observed:
- Source + tools = product: The only ingredients in a build should be source files and the tools to which they are input.
- Check in all original source: Make sure that the build includes the original source code and makefiles, setup scripts, build scripts, build instructions, and tool specifications.
- Segregate built objects from original source: Organize builds so that the directories containing original source files are not overwritten by built objects.
- Use common build tools: Developers, testers, and release engineers should all use the same build tools.
- Keep build logs and build outputs: Archive build outputs and logs, including source file versions (e.g., a label), tool and OS version info, compiler outputs, intermediate files, built objects, and test results, for future reference.