Skip to content

Launch

Jump to bottom Edit New page
Kyle Braak edited this page Oct 19, 2017 · 45 revisions

New IPT Version Launch Procedure

Table of Contents

Introduction

A checklist documenting the ordered steps of the release and launch procedure of the IPT. Learn as you go - review and adjust the process to streamline it.

Many players are involved in the process, not least the GBIF Communications team and GBIF Systems Administrator. Make sure they are on standby ready to help before embarking on the launch.

Pre-release steps

  1. Label all issues related to version
    • Label issues with issue type (Bug, Enhancement, Duplicate, Won't fix, Type-Task, Type-Other, etc.), used in statistical reporting.
    • Label issues requiring a change in the UserManual/Wiki with UserManual.
    • Assign milestone to each issue, used to group all issues addressed since last version was released. For example, here are all issues addressed in version 2.3.5.
    • Assign project to issues worked on, used internally and externally to transparently show work done for this version. For example, here is the project for 2.3.5.
  2. Finalise work
    • Work on each issue should be considered "Done". The meaning of "Done" being understood and agreed on by the entire team, but ideally this also includes having written automated testing, performed code reviews as well as UI testing.
  3. Finalise translations
    • Work translating each language (by volunteer translators in Crowdin) should be both 100% translated and approved.
    • The translations should be exported from Crowdin and committed to the IPT repository following the instructions found in each properties file, e.g. ApplicationResources_fr.native.
    • Open the UAT IPT to volunteer translators to verify their work in vivo (see step below).
  4. Test release candidate
    • Update the UAT IPT with the release candidate
    • When it makes sense, invite volunteer testers to join efforts by sending an invitation to the IPT mailing list explaining how to request an account on the UAT IPT and what areas of testing to focus on.
    • Test new features - issues labelled as Enhancement. Directly involve the reporter of the enhancement in testing, to verify its implementation meets their expectations.
    • Test bug fixes - issues labelled as Bug. Try to reproduce the bug following the detailed instructions provided in the issue description.
    • Test all areas possibly affected by code changes. Build a list of affected areas to test by scanning the commit history.
    • Always ensure that GBIF can index the data published by the IPT, for example using the new GBIF Data Validator.
    • Put on different user hats, testing as an 'Admin', 'Manager' and 'Manager with registration rights'.
    • Where applicable, test the IPT in both production and test mode.
    • Where applicable, perform cross-browser testing.

Release and public launch steps

  1. Release new version using Jenkins
    • Note: comment out the integration tests (ITs) for Jenkins to release the IPT successfully. Remember to uncomment the ITs in master afterwards.
  2. Update GBIF IPTs to new version
    • Update production instances:
      • BID IPT - customized (see below for help).
      • EU BON IPT - customized (see below for help).
      • ALA IPT - customised (see below for help). Note this instance runs on ALA's server.
      • EIA IPT - vanilla.
      • GIASIP IPT - vanilla. Note this runs in test mode but is treated like it's in production.
      • TEST EU BON IPT - vanilla. Note this runs in test mode but is treated like it's in production as it's embedded in EU BON's portal.
    • Update Test/Sandbox instances:
      • DEMO IPT - vanilla. Note It is always a good idea to cleanup old resources to save disk space.
      • UAT IPT - vanilla
      • DEV IPT - vanilla
    • Simple customisations for the above IPTs are done by a) changing the logo image in menu.ftl#L12, b) removing the test image in menu.ftl#L20 (where applicable) and c) tweaking the CSS in main.css#L297. Note: before an upgrade, the custom logo image(s) and CSS need to be backed-up/preserved and then copied back to the expanded data directory.
  3. Update User Manual and Wiki
    • When major changes are expected, archive the User Manual before applying any changes. For example, here is the archived copy of the User Manual for version 2.0.5.
    • Add/update User Manual or wiki content - see issues labelled as UserManual.
    • State the IPT version that the manual corresponds to underneath the title.
    • Add a link to the former version(s) of the manual to make it easy to find.
    • After applying all changes in English, request Spanish translators (e.g. SIB Colombia) to apply all changes to the Spanish User Manual also. As highlighted in the GBIF Data Publishing Analysis, the updates from v2.3 to v2.3.4 are still outstanding.
  4. Create/update Release Notes
    • When major changes are expected, create a new Release Notes, otherwise extend the existing notes as has been done for the 2.3.3 Release Notes.
    • The Release Notes should contain all the information needed to properly upgrade their IPT to the latest version. Typically it contains the following sections:
      • Upgrade instructions
      • Post-upgrade instructions
      • New Features / Other
      • Dependency Notes
      • Viewing the IPT change log
      • When all else fails
  5. Publish blog post
    • Publicise in some detail, select improvements that users will value. For example, here is an example blog post for IPT v2.2.
    • Be sure to acknowledge volunteer translators and coders that contributed to the release.
    • Review the blog post with the help of the GBIF Communications team before publishing.
  6. Update release history
    • Add section for new version including a link to the .war download, release notes, user manual, how many issues were addressed broken down by type, blog post and a short summary of what changed.
  7. Update Roadmap
  8. Update Github IPT Readme
    • Advertise the new version, highlighting what changes will be interesting and valuable to users linking to blog post when applicable.
  9. Update GBIF.org IPT page
    • Mirror relevant changes made to IPT Readme in step above
    • Update IPT uptake statistics, e.g. number of installations and number of countries having installations displayed at bottom of map.
  10. Announce to IPT mailing list
    • Keep the message short so that people actually read it, linking to the blog post when applicable that has more detailed information about the release. Here are a couple example announcements for 2.2 major release, 2.3.3 minor release and 2.3.4 security patch release
    • Highlight GBIF's vigilance in keeping the IPT secure, while reminding people of the importance of updating their instance with this latest version.
  11. Broadcast on social media
  12. Reward volunteers
    • Say thank you again, in addition to saying it in the blog post and mailing list announcement.
    • Encourage volunteers to include this experience on their CV

This IPT wiki is no longer maintained. Please refer to the IPT User Manual.

© 2021 Global Biodiversity Information Facility
The content on this site is licensed under Creative Commons License

Para la versión en español

Clone this wiki locally