Versions - bcgov/PIMS GitHub Wiki

PIMS Versioning

The solution will use Semantic Versioning 2.0 to version all components.

  1. MAJOR version when you make incompatible API changes,
  2. MINOR version when you add functionality in a backwards compatible manner, and
  3. PATCH version when you make backwards compatible bug fixes.

[major].[minor].[patch].[build]

This will result in a versions like the following 1.0.34.3435, or when preparing for a new release 1.0.34-alpha.3435. Each new build should automatically update the build number (this does not yet work).

Versions

Version Name Date Description
0.0.1 Bones March 24, 2020 Initial PoC release
1.0.0 MVP July 31, 2020 Minimal Viable Product release
1.1.0 Re-engage Oct 31, 2020 Bug Fixes
1.2.0 Pacing Nov 15, 2020 Bug Fixes
1.3.0 M2M Nov 30, 2020 Property relational complexity
1.4.0 Mapping Dec 15, 2020 Improvements to the map
1.4.1 Hotfix-01 Bug Fixes
1.4.2 Hotfix-02 Bug Fixes
1.4.3 Hotfix-03 Bug Fixes
1.4.4 Hotfix-04 Bug Fixes
1.5.0 Inventory Jan 15, 2020 Submit Property Workflow
1.5.1 Hotfix-05 Bug Fixes
1.5.2 Hotfix-06 Bug Fixes
1.5.3 Hotfix-07 Bug Fixes
1.5.4 Hotfix-08 Bug Fixes
1.5.5 Hotfix-09 Bug Fixes
1.5.6 Hotfix-10 Bug Fixes
1.5.7 Hotfix-11 Bug Fixes
1.6.0 Polish Jan 31, 2020 Bug Fixes
1.7.0 Dispose Feb 15, 2020 Disposal Project Workflows
1.7.1 Hotfix-11 Bug Fixes
1.8.0 Sidebar Feb 28, 2020 Map Property Information
1.8.1 Hotfix-12 Bug Fixes
1.9.0 Re-engage Mar 15, 2020 Disposal Projects
1.9.1 Hotfix-13 Bug Fixes
1.9.2 Hotfix-14 Bug Fixes
1.10.0 Templates Apr 30, 2020 Bug Fixes
1.10.2 Notify May 6, 2020 Bug Fixes

Rollback

All releases should have permanent tags applied to them by our build/deploy pipeline. See Managing Images for more details. A permanent tag may either be added manually or using the corresponding step in the CICD Jenkins Pipeline.

Openshift Image streams maintains the history of tracking tags (ie. Dev, Test, Latest) and prunes images periodically based on age and usage. However, in most cases we should be able to rollback to a previous version of a tracking tag before it is pruned. However, in order to keep a complete release history all pushes to prod should be tracked with permanent tags.

In order to rollback a deployment, use oc rollout undo dc/* (to rollback the most recent deployment only) or oc rollback *. oc rollback supports --to-version x as well which can be used to rollback multiple releases at the same time. Both of these commands will revert the deployment configuration to the configuration used for that release, including the image, tag and image id. --dry-run works for both commands to see what changes will be made by the rollback.

In order to see the id (sha hash) of a given tracking tag, either navigate to the desired deployment config # and click Edit Yaml the sha will be under spec->template->spec->containers->env->image. The equivalent CLI command is oc rollout history dc/pims-api-dev --revision=x

The above process would need to be repeated for all deployment configurations that need to be rolled back (ie. pims-app, pims-api). The database may require migration(s) to be rolled back manually in addition to the oc steps above.

Be aware that oc rollout undo and oc rollback disable automatic deployment on image change. This flag should be re-enabled as required when the rolled back deployment is no longer required.