SA3-WI15-Release Management-Task Description
From GEANT2-JRA1 Wiki
Contents |
[edit]
Release Process
Explanation of The JRA1 fish:
- Project Plans
- The project plans include timelines for development, release and rollout of products. These timelines are specified based on resources available, technological challenges expected, dependencies, etc. These dictate the release strategies.
- User Experience
- Although not as significant as Project Plans, the User Experience that we aim to provide plays an important role in deciding our release strategies. For example, a complicated software (to install, to use, etc) might be introduced in steps to the user. Each step is more like an upgrade of the software. Each step will then contribute to dividing the complexity into bits.
- Development
- The Development process is timed according to release strategy. By doing this, the development process knows what is expected from their effort and by what time. The activities within the Development process can be timed and arranged in a manner which will help in speeding up the release process later on. For example, the Development process might begin with functional specification and interface specification. By providing these documents earlier on to the release team, the testing group in the release team (see more later) can start working on test scripts for the services in development. Any changes to these specifications during the development process will need to be notified to the testing team asap.
- Hand over
- Hand over is a crucial part of the release and support activity. Hand over ensures that the quality of software is kept upto expected levels so that support can be provided for this software. Hand over can be achieved with the help of quality documentation from developers, Specifications and conformance to agreed specifications and testing. Usually, hand over is not a one step process. Multiple iterations will be necessary. Because of the nature of perfSONAR software (i.e. many services in one release) Hand over process for perfSONAR actually consists of many hand overs amounting to the big one. This adds a bit more complexity to the process.
- Packaging
- Packaging or bundling involves putting all the services together into a package and possibly having some kind of 'wrapper' installations scripts. Packaging involves making the product's installation, configuration and usage process more 'user friendly'
- Release Candidates
- RC Testing
- Release
- Feedback
- Continuation...
[edit]
Hand Over process
[edit]
Hand over Process documents
- Document to be read by developers in order to understand the Hand over process and the requirements of this process
[edit]
List of Documents expected from developers
- Functional Specification of service
- Interface specification (XML Schema and examples of XML messages)
- Specification of Ant targets (Installation instructions - in case of perfSONAR services in perl)
- Sample configuration files (service.properties, config.properties)
- Sample Metadata configuration files
- Includes instructions on how to construct the metadata configuration files
[edit]
Templates for above Documents
- Template for Functional Specification of Service - .doc
- Template for Interface Specification - .doc
- Template for specifying Installation Actions - .doc
- Template for sample configuration files - .doc
- Template for sample metadata configuration files - .doc
[edit]
Verification of Documents provided by Developers
Task Includes:
[edit]
Functional Testing
- Definitions and Descriptions
- Pages on Functional tests status - here
[edit]
Performance Testing
[edit]
Packaging, Documentation
List of Documents to be included in Package are
- Whole Package related
- Readme.txt - consists of following sections
- Summary of all steps (short guide for the impatient ones)
- Details of each step (contains sub-categories, one sub-category for service?)
- Advanced installation notes (tomcat port changes, etc)
- FAQs
- License.txt
- What can you do & What can you not do, etc
- Readme.txt - consists of following sections
- For each individual service in a release
- Sample configuration files with comments
- Sample Metadata configuration files with clear comments
[edit]
Release Candidates (RC)
[edit]
RC Testing
- What to test?
- Go over the installation process, install all the available services
- Install and configure all the documented features (example if xml database is optional but documented, please install it to test out the process)
- Test the installation to see if it was installed ok
- Note down the time needed to do a basic installation of each service
- Provide feedback to the Release team at least about the following aspects of the installation process
- Ease of installation
- Installation document - easy to use? easy to refer to? easy to understand? good quality overall?
- Difficult/tedious parts of installation process
- Easy/friendly parts of installation process
- Comments on interaction between user and installation script (clear and understanable questios or a list of unclear, difficult questions)
- What else can be tested? TBD
- Volunteers
- Luis Marta - FCCN
- Szymon Trocha - PSNC
- proposed - Chris Welti - SWITCH (?)
- proposed - Joe Metzger - ESnet (?)
