Create Translator Release Process Details

[tursynay]

@NCATSTranslator/tact-voting-members, these are Translator Release Process Details that outline the step by step release order. Please review and comment by the end of November 14. We will merge then.

[saramsey]

L46 addresses hotfix deployments to PROD during the coding window, but doesn't specifically address hotfix deployments to TEST during the coding window. What are the requirements to be able to deploy a hotfix to TEST during the coding window? Are they different than the requirements to be able to deploy a hotfix to PROD? I could see an argument for being more permissive for a hotfix to be deployed only to TEST during the coding window (i.e., to fix a bug that would otherwise make it difficult for SMEs to evaluate the new release candidate for Translator).

[sierra-moxon]

@saramsey - can I clarify your comment in my head? :) I think you might be asking two questions, but I am not sure:

1) is the process for push to PROD during the "code window" the same as the process for push to TEST? This is the phase in our cycle where TEST is a mirror of PROD.

My vote here would be yes. We can use the same templated changelog as a request for pushes to TEST as we do for the same issue being pushed to PROD.

2) is the process for pushes to TEST during the "freeze/slush and plan window" the same as during the "code window"? This is the phase in our cycle when TEST becomes the site where we manually test the new release.

My vote here would be no. Once we get to the "slush and plan window", there will be lots of small bug fixes going into TEST from all the teams as testers manually find issues with the new release (to fix a bug that would otherwise make it difficult for SMEs to evaluate the new release candidate for Translator).

We have not identified a process for deciding which things identified in the "slush and plan window" (via manual testing) to fix before release. I would vote to keep the process very light in this phase; our collective "best judgment" as component developers could be the baseline.

[saramsey]

Thank you @sierra-moxon. That's very helpful.

I do have a follow-up question. I'm a bit confused by the statement that we would want TEST and PROD to be mirrors of one another during the coding window. Suppose that during the coding window, we (Team Expander Agent) propose to deploy a hot-fix for ARAX to address a high-severity bug that for whatever reason previously wasn't caught earlier in the Translator release process. I assume we would solicit and obtain approval from TACT and ITRB to deploy the patch to ARAX in TEST. Then we or others would verify that the patch is working in TEST, before there would be any discussion of deploying it to PROD. Right? So there would be a period of time (perhaps short) in which TEST and PROD would not be mirrors; TEST would have the patch and PROD would not. Perhaps it's pedantic, but during that window, the two deployment environments would not be mirrors, by my way of thinking. (perhaps I misunderstand).

As for having a lightweight process for deploying fixes during the slush/plan window, that's fine with me. I presume deployment requests during that window would be limited to bug fixes, just as they are in the coding window.

In summary, to see if I understand it right-- Translator is moving to a model where for new features and "performance enhancements", we only do deployments four times a year, during official releases (right?). Outside of those four deployments at specific quarterly intervals, it's only bugfixes, and only with approvel -- lightweight approval if it is a SME/TAQA affecting issue during the slush window, and more heavyweight approval during the coding window.

Do I have that right?

[sierra-moxon]

@saramsey - I think this is right - let me echo it back to you with slightly different terms to confirm :) :

I'm a bit confused by the statement that we would want TEST and PROD to be mirrors of one another during the coding window.

I should have been more specific: TEST and PROD should be mirrors of one another in the code window except when we do a hotfix. Then TEST will be the place where we verify that the patch is working so that it can be deployed to PROD. I imagine this turn-around cycle to be short and once the hotfix is released, TEST and PROD again are mirrors of each other.

Translator is moving to a model where for new features and performance enhancements, we only do deployments four times a year, during official releases (right?)

This is our current proposal, right - four planned releases each year where new features, fixes, and planned enhancements are deployed. But, I want to reiterate that the timing of these releases can and should iterate -- we need to get through one cycle to see if it is too long or too short or needs to be completely refactored based on feedback from the teams.

Outside of those four deployments at specific quarterly intervals, it's only hotfixes, and only with approval -- lightweight approval if it is a SME/TAQA affecting issue during the slush window, and more heavyweight approval during the coding window.

yep! this is what I think our proposal is as well. :)

[edeutsch]

I'm a bit confused how this is different from #4

[karafecho]

Note to all:

If approved, the Translator Release Guidelines doc will be archived with the other Translator Guidelines as a G-doc. Here is a link to the current draft of the guidelines in human-readable non-md format.

The Translator Release Process Details doc contains detailed steps regarding the release process that are not appropriate for the high-level guidelines doc, but rather are intended to inform Translator team members on how things are expected to work in practice. Sort of like an SOP.

Apologies for the confusion!

[tursynay]

During the winter 2024 release schedule retrospectives relay session, this process will be updated and finalized. Will merge this PR then.