Skip to content

Releasing Tests and TEAM Engine

Jump to bottom Edit New page
dstenger edited this page Feb 14, 2024 · 17 revisions

Summary of test releases in the OGC testing infrastructure

Releases of new revisions of tests and TEAM Engine follow a time boxed model. There is one monthly release with new revisions of tests in beta and at the same time a release in production. The release should happen in the week 2 or 3 of the month. If there are any changes on a test, the test lead should have the test ready by the first week of the month, and inform before the deadline for that particular month. See Release-Schedule for the exact dates. If there are no updates on a particular test, no new releases of the test will be performed. The tests that are released in the production website are those that have been in beta and no issues were reported related to that particular beta release.

The test lead informs of a test release by posting an issue in the OGC release tracker. OGC staff associates a milestone (month) to the issue providing information about the month the issue will be released. For example, the test WMS 1.1 revision 1.10 was released in the beta release 2015-06

Test lead release checklist:

The test lead should prepare and inform about a new release of a test following the Release-Schedule. The process check list is as follows:

Prepare release (for each test suite individually)

  • The master branch should contain the latest "stable" version. Make sure all verified pull requests are merged.
  • Make sure it builds properly running mvn clean install site -Pintegration-tests,docker.
  • Test locally the master branch with the reference implementation, if there is one. If there is none, any other implementation can also be used for a local test.
    • If it is OK, continue, if not create or update an issue, in the issue tracker of that test.
  • Review closed issues to be included in the release.
    • Update title if appropriate.
    • Tag, if they are not tagged with the milestone number.
  • Update release notes, usually the file is at src/site/asciidoc/changelog.adoc.
    • Add a new title for the revision, if there is not one already.
    • Copy the issues to be included in the release, link and title.
    • Add any other highlights.
  • Create a new issue in the OGC release tracker and set label approved-by-test-lead.
    • Write a title for the issue. It should contain: [Abbreviation] [version] revision [revision] in Beta. For example: WFS 1.1 revision 1.23 in Beta. It should always be in Beta. OGC staff will create the issue related to making the releases in the production, official web site.

OGC Validation Tools Release Manager checklist:

Beta

Create release (for each test suite individually)

  • In the OGC release tracker assign the issue to a milestone.
  • Do the release. Process involves creating a revision based on the pom.xml version, updating the GitHub page, tag, and updating the revision on the pom for the next release.
  • Close milestone in the ETS issue tracker.
  • Set label ready-for-installation.

Install and advertise releases (for all test suites together)

Production

  • Review which tests were in beta and can be moved to production. If no issues were reported in the forum, the tests can go to production at the proposed schedule.
  • Create revision 1.0 of all test suites which are moved to Production for the first time.
  • Proceed same steps as documented in previous chapter Beta.
    • Install newly created revisions 1.0 on Production and Beta.

Summary of TEAM Engine Release

Announce maintenance of Production

  • Updates of Production environment shall be announced one week prior via mailing list (cite-forum).
  • After the maintenance is done, a following email is sent confirming that maintenance is complete and TEAM Engine is back to normal.
Add a custom footer
Add a custom sidebar
Clone this wiki locally