Release Process

Owned by Dave Alburger, created
Last updated: Feb 17, 2023
7 min read

Here is a step-by-step guide about how to release a new version RSIG to production.

Due to issues encountered over the summer regarding last minute requests for testers, Rail Safety have asked us to document the release process.

Release Steps

 Instructions

  1. Person or team performing Product Owner role reviews backlog items and decides which will go into next release.

  2. Dev team and PO decide number of sprints for the release and which items should be completed in each sprint.

  3. Dev and QA estimate dev and test times for each set.

  4. Scrum master creates a Release Plan in DevOps based on sprint estimates.

  5. QA to outline a Test Plan at the outset and fill in as details become available.

  6. QA to create a UAT plan at the outset, fleshing out documentation for users as details become available.

  7. During sprints, complete QA testing, log bugs, fix bugs. Add extra sprint(s) at the end if estimating was off or critical bugs not fixed in time.

  8. Final sprint should be regression testing - all hands on deck.

  9. Plan release target date to be 6 weeks after completion of last sprint.

  10. Send request for UAT testers to RSIG Help Desk (QMS) no later than 6 weeks before target release date. Provide UAT plan and user documentation, including specifics on what needs to be tested, how many testers are required, etc.

  11. RSIG Help Desk to schedule and invite testers for UAT testing 3 weeks before target release date.

  12. Once UAT registration complete, Service Desk should send user list to RSIG QA team. QA team will coordinate the user authorization setup.

  13. Arrange user training session for people conducting UAT for any new features that need to be tested before testing date.

  14. Create SMGS ticket to Refresh UAT and ACC database and set up user access and authorizations for UAT and ACC testing.

  15. Create RSIG ACC SMGS ticket 4 weeks before target release date.

  16. UAT testing 3 weeks before target release date.

  17. QA testing of ACC Desktop and Citrix version.

  18. If UAT and QA testing passed, then close all ACC SMGS Testing tasks, Create RSIG Production release SMSG ticket 2 weeks before target release date

  19. Actual Release on a Friday/Saturday (Friday, have few RSIG users do smoke test with the newly deployed app; Saturday, Citrix version is deployed, QA does smoke test).

  20. Close all RSIG production-related release SMGS testing tasks. Once they have been closed, the release can be marked as complete.

Release Schedule

Dev team, QA team, scrum master and PO work together to create a release schedule in advance of UAT testing and release to production.

Our standard release schedule outlines tasks and approximate timelines required for release. The 2022 Winter Release Schedule provides an example of the release schedule in practice.

UAT Test Plan

In advance of UAT testing with RSIG users, QA creates a UAT Test Plan for users to follow and complete during the process.

In future test plans, RSIG users should also be asked to complete tasks they are required to do on a regular basis in order to uncover any additional issues that may not be found by the test scenarios outlined in the test plan. And if there is any performance issue.

UAT Testing

Prior to Test sessions

RSIG Help Desk (aka QMS group) does sanity test to ensure Test environment is working as it should. Reason: They have mostly the same kind of access rights as RSIG users so they would catch things the Dev team wouldn't, due to their elevated rights. (other option, Dev team creates some dummy accounts for this kind of testing)

On test days

At least one QA staff from RSIG Dev team to be online during sessions in case of questions. Testers are asked to report issues found immediately to the QA team so they can be addressed. One QA team member is designated the contact, and will triage reported issues as they are found with the QA team.

Prod Release Plan

  1. RSIG Create Change request on Wednesday/Thursday two weeks before targeted release day, prepare release packages and put in a specified location as defined in the first task of the change request. Or create the folder if the task is still not available Friday.

  2. Create notification to inform users when RSIG will be offline (e.g. Friday September 17th through Saturday September 18th). Message is displayed to users each time RSIG is opened until release day.

  3. On RSIG desktop application release day:

  • RSIG is locked down. If a user tries to use RSIG, a notification is displayed indicating that the system is down for maintenance, and when it will be available again (e.g. RSIG is offline for maintenance, and is expected to be available again after 4:00pm on Saturday, September 18th).

  • RSIG users at HQ & different regions test the new version, and notify web group if the release is a go or no-go

  1. On RSIG Citrix release day:

  • RSIG users will see the same notification message as the desktop application indicating the system is down for maintenance

  • RSIG team members test in Citrix Prod, and notify the Citrix team if the release is a go or no-go

  1. If there is an issue with the release, initiate rollback procedures.

  2. Once the system is confirmed ready to go, RSIG is unlocked and can be used by Rail Safety. Users are also notified that the RSIG upgrade has been completed.

  3. Close the production release task in the production environment to confirm the release is complete, and the release is working as expected.

Script of emails

To request testers:

Hi Folks,

We are seeking RSIG users from <All or specified groups> to test the following functionality on <insert dates>:

<insert functionality to be tested here>

We are also seeking a few RSIG users to do sanity checks on existing functionality.

Info to testers that have volunteered:

Subject: Step-by-Step UAT testing instructions

Listed below is a step-by-step process outlining software requirements and the testing process. <insert steps> outline software requirements that must be available on the testers machine to begin testing. It is important for testers to complete, <insert steps> before RSIG testing begins in <insert step>, as the user may need to contact the Service Desk to install software. DS’s team is also on hand to answer any software installation (and testing of course!) related questions. Please take a look at steps 1-4 as soon as possible to ensure you have the correct software installed.

During the testing process, the RSIG team requests that testers report bugs/issues that they find right away to the RSIG Help Desk and CC Jane at Jinzhi.xia@tc.gc.ca.
If you would like, DS can also schedule a Teams meeting with you to review the testing process early next week! Please let us know if this would be helpful to you.

Thank you,
RSIG Team

 

Additional Instructions to help testers find their Computer Name (if needed)

If you do not have Crystal Report 64-bit with version number v13.0.30.x installed, please let us know your Computer Name. Instructions to find your Computer Name are listed below.

Click your computer’s “Start” button (if needed).

Click on the Search icon to the right, and type “Computer”.

In the left-hand column, select “This PC” and then in the right-hand column “Properties.

 

Find “Computer Name” in the right-hand column.

On Release Day

It is best to plan a production release over a two day period, and taking place on a Friday and Saturday. RSIG is released to desktop on Friday, with a few RSIG users taking part in a smoke test to ensure the newly deployed app is working as intended. On Saturday, the Citrix version is deployed, and the QA team performs the smoke test.

After the app has been deployed, the team needs to close all production-related SMGS testing tasks. Once they have been closed, the release can be marked as complete.

Highlight important information in a panel like this one. To edit this panel's color or style, select one of the options in the menu.

 Related articles