Portal versioning display to the user

[fedorov]

For the purposes of debugging etc, and to allow referencing a specific release, I think we should add some versioning of the portal to the idc-dev and idc-testing pages. Thoughts?

@wlongabaugh @G-White-ISB

[wlongabaugh]

Yes, we can probably do something, but how does it sit on the MVP priority list?

The issue is not so much showing a number, but implementing the formalism behind it. For example, the viewer, the proxy, all the configuration file settings, the solr configuration, database contents, etc. all influence the behavior of the system. So what are we trying to capture by the version number?

The version of the currently running webapp is available here: https://console.cloud.google.com/appengine/versions?project=idc-dev&serviceId=default. And if we know the time of the issue, we can back out the version, and the deployment time, and thus GitHub state if the problem cannot be reproduced by the current version.

To display to the user, we would need to stick a number in a config file during deployment. @s-paquette what is your take on creating a version stamp for display in the web app?

[fedorov]

I think exactly because the problem is so complex, and we need to keep track of updates to various interconnected components, it is important to think about this.

Where can I learn about the deployment process and individual components involved? Is deployment automatic or there are manual steps? Are all components deployed at the same time by the same process or not?

I think that although the entire problem is difficult to address, we should start with keeping track versions of the individual components, if nothing else. It is just "good manufacturing practice". Providing transparency to the user about when the system changes, and what the changes are, is just one of the "use cases" motivating versioning.

[fedorov]

@wlongabaugh would it also be controversial to show the date and time when the current portal was deployed?

[wlongabaugh]

Production deployments are very fixed. We typically only make changes to the production system when we do an official sprint release, so by practice a production release timestamp would capture all changes. However, sometimes a redeploy is needed to fix Google issues, so a changed stamp might not indicate a changed system. And if a backend component needs a hotfix (e.g. database), we don't necessarily roll the webapp. Within the development environment, there are too many moving parts to make it easy to track.

[wlongabaugh]

No, it is not controversial to do so... it does not capture all the moving parts that might change, but should be relatively straightforward.

[s-paquette]

@fedorov This is now available on the dev site.

[fedorov]

Much better, thank you!

Should we plan to have some tags assigned for the MVP and release notes, or that's too much work?

For the reference, release notes examples from other resources:

• PDC https://drive.google.com/file/d/1k_sPoPuhusZPRDJWkVecWEnyCqvQm8nA/view?ths=true
• GDC https://docs.gdc.cancer.gov/Data_Portal/Release_Notes/Data_Portal_Release_Notes/

[s-paquette]

We do release notes for CGC as well, but typically they're a delta from a prior version, which we don't have yet. I'm not sure it'll be useful to do tagging and release notes until we've actually released the MVP.

[fedorov]

Yes, I agree, this will be important for the MVP. Should we make a separate ticket for that?