*Deprecated* See https://wiki.duraspace.org/display/VIVODOC/All+Documentation for current documentation

 

Development and Release Process

  1. Development team meets to plan release
    1. add release to Jira
    2. assign Jira issues to this release
    3. make sure that all issues in this release have reasonable time estimates
    4. prioritize issues in this release
    5. schedule code freeze date
    6. schedule release date
    7. add end date to Jira release with date of code freeze
    8. schedule a release review meeting
    9. add an issue for a press release
    10. add an issue for a set of release notes
  2. Work on issues
  3. Have a mid-release review meeting for the development team.
    This meeting should happen about 1/4 of the way between the start of
    the release and the code freeze date. The purpose of this meeting is
    to review the progress of the release, to check that the original
    goals are being met, to check that the original goals are still
    valid, to adjust priorities, to change the code freeze or release
    date, to clear up any ambiguity in the issues.
    1. team members should have time estimate up to date for this meeting
    2. schedule a meeting on the freeze date for the first release candidate
  4. Continue working on issues
  5. Release candidate meeting, the team meets to decide whether to create a release candidate
    1. If this is the first release candidate for this release, create the maintenance branches as described below.
    2. Are there any blocking issues? If no, proceed
    3. Can their priority be downgraded? If they can all be downgraded, proceed
    4. (extreme) Should we go ahead in spite of the blocking issues?
    5. If there are still blocking issues:
      1. adjust time estimates to remaining blocker issues
      2. schedule meeting to create a release candidate
      3. go to step 4 (continue work)
    6. If there are no blocking issues:
      1. schedule testing
      2. schedule next meeting to decide to create a release candidate or a release
  6. Produce release candidate distribution files as described below
  7. Test the release candidate distribution files
    1. Failed tests will be entered in Jira as blocking issues, the will later be reviewed by the team and re-prioritized
  8. Repeat steps 5 - 7 as needed until team determine that the release is ready
    1. A release is not ready while there are blocking issues
    2. the team may downgrade issues from blocker status
  9. Release
    1. Execute Jira "Release" operation
    2. Create final tags in Git (e.g. rel-0.9)
    3. Post final distribution files on SourceForge
      1. e.g. rel-0.9.zip and rel-0.9.tar.gz
      2. This requires a SourceForge account that is an Admin for the Vivo project at SourceForge, and an account on vivoweb.org
      3. The project site is at https://sourceforge.net/projects/vivo/files/
      4. Copy the final distribution files from the ftp server to SourceForge
      5. Upload/attach the public ontology file (checked in to vivo/productMods/WEB-INF/ontologies/public) to http://vivoweb.org/download and to SourceForge.
      6. On vivoweb.org, modify the URL redirect for ontology/core to point to the file on vivoweb.org.
    4. Distribute press release
      1. Send it to vivo-dev-all@lists.sourceforge.net
      2. Also send it to holmeskr@wusm.wustl.edu in a separate email.

Deliverables

Documents

Press Release

Release Notes

  • What: a list of the major features/enhancements/fixes that are included in this release.
  • Who: Jon, with help from all developers
  • Note: Usually the Release Notes are a delta - listing the differences from the previous release.

Deployment Guide

Distribution files

  • Zip file of the source tree
  • Tar/GZip file of the source tree
  • The core ontology file

Testing

  • Failed tests will be entered in Jira as blocking issues, the will later be reviewed by the team leads and reprioritized.
  • Test team may test on whatever machine is convenient.
  • A "sandbox" will be created for informal testing by the entire team.

Manual testing

Installation

  • Follow the deployment guide.
  • Deploy on Linux and on Windows (maybe Macintosh as well)

Operation

  • After the code freeze, developers will work with testers to devise tests for new features, or to adjust existing tests to suit any changes.
  • There will likely exist code features for which no automated tests exist. These should be tested manually, according to a written test plan.

Licensing

  • During preparation of the distribution files, a process is run which inserts licensing information in the source code. The testers should do spot checks to be sure that this process has run.

Automated testing

Continuous Integration

  • The "continuous integration" server (Jenkins) is configured to run the build script every time the code changes in the "develop" branch. It also runs the optional build steps that pre-compile JSPs to check for errors, check for license tags in the source files, and check the container-neutrality issues in web.xml.
  • These scripts are run only against the "develop" branch. If they are to run against the maintenance branch also, this must be configured in Jenkins.

Acceptance tests

  • Many of the manual acceptance tests have been converted to Selenium-based tests.
    • It would be good to have these tests run periodically on the "continuous integration" server (Jenkins), but this has not proven to be practical as yet.
  • These tests should also be run under supervision of the testers as part of the testing of the release candidate.

Unit tests

  • These are executed every time the build script runs.
  • There is no need to repeat these tests while testing the release candidate.

Steps to Produce a Release Candidate

These are detailed on Building a release of VIVO.

Git Branches and Tags for Releases

When the first release candidate is created, several branches and tags
need to be created in the Git repository.

  • Create a branch to be used for the rest of the release process in
    the vivo Git repository, e.g. release/rel-0.9-maint
  • Create a branch to be used for the rest of the release process in the Vitro project, e.g. release/rel-0.9-maint
  • Create release tags in Git for the NIH VIVO project, e.g. rel-0.9-rc1
  • Create release tags in SVN for the Vitro project, e.g. rel-0.9-rc1

Notify developers that the tags have been created and provide pointers to their use. Email this to vivo-dev-all@lists.sourceforge.net.

Any change for the release must be applied to both the release branch and the trunk, and may require re-deploying, re-testing. Changes just for the trunk that are not intended to go in this release don't need approval and should be applied only the the trunk. This permits development that is unrelated to the release to continue.

 

  • No labels

*Deprecated* See https://wiki.duraspace.org/display/VIVODOC/All+Documentation for current documentation