<-Previous || RM Table of Content

Release to Production Environment

On receiving the email notification from Jira to move changes to Production, the RM would do the following:

1. If the RM has a development role (Cuong)
   • Proceed the Create a Tag sub-process (see the description in the previous page)
   • Proceed Create a Change Order sub-process (see the description in the previous page). Once approved by the Functional Approver (Lara), assign it to the 2nd (aka back-up) RM who doesn’t have the development role and communicate to the back-up RM. If the 2nd RM isn’t available, the CO will be assigned to the Scheduling Group (Jo-Ann Desautels), and proceed Jira Ticket Update sub-process  (see the description in the previous page) to inform the developer once the release is completed.
   • Notes:
     • If the release is made based on an existing CO, the new tag information is entered in Append New Description text box. Make sure by email with the 2nd RM (Ruben or Jo-Ann) that the new tag is released, not the initial tag in the CO. This is because the Additional Notes in FootPrints Service Core Calendar Appointment Confirmation isn’t updated.
2. If the RM do not have the development role (Ruben or Jo-Ann)
   • If the primary RM is available, the pre-work was already completed by the primary RM. The (2nd) RM would
     • Proceed Production Release sub-process (see the description in the previous page) to release changes from to Production, using the tag number from the CO.
     • In Append New Description text box, update the Change Order with status of the release (for example, “SUCCESS: Release (famis__vxx.xx) has been checked-out”)
     • Assign it back to the primary RM.
   • If the primary RM isn’t available (so the Jira ticket goes directly to the 2nd RM)
     • Work with the Functional Approver (Lara) and the developer to make sure the changes were approved. The CO will be done later by the primary RM (Note that the Functional Approver will update the CO status to Change Completed after all)
     • Proceed Create a Tag sub-process
     • Proceed Production Release sub-process (see the description in the previous page) to release changes from to Production.
     • Update the Jira ticket to inform the developer that the release is completed.
     • Communicate and work with the primary RM regarding the move of changes to Production, to make sure a CO will be in place later when the primary RM is available.

The Functional Approver will update the CO status to Change Completed after all.

In case the release doesn’t work, the RM uses the Production tag just before the released tag to roll back the environment, or the next tag for fixing if available.