Change and release process describe the steps and the tools used when a platform's change is required

1 - Some examples of changes

• New component release
• Infrastructure rework and consolidation
• Manual Changes to web server configurations and other individual components
• Generally speaking, any changes involving manual infrastructure change or SSH access

2 - Change and release process

2.1 - Change process

The same process is applied to any product release or infrastructure change. Changes will usually involve specific steps that - while they may be automated - require advanced technical validation from subject matter experts

• Change ticket raised in JIRA (Enterprise Support Desk) - (ticket: Upgrade or change a component)
• Agreement on a deployment date between Maestrano Support Team and our customers - with a communication plan if an outage is expected
• Approval from Maestrano Quality Assurance, from a Maestrano Peer, from Maestrano Operations Management

If the change is not performed by the Enterprise Customer himself, then a validation will be required from him (Status: "To be reviewed by Business"). The Enterprise Customer review step is important not only technically and functionally speaking - to prepare the testing phase - but also if a communication needs to be sent to the end users (e.g.: outage).

• Change performed, based on deployment procedure
• Testing performed by the Enterprise Customer (+ Maestrano QA if needed)

If the change is performed by the Enterprise Customer himself, the reporter of the ticket will be changed to the relevant JIRA user on the status "To be Released", otherwise, the Enterprise Customer can wait for the ticket status to be moved to "In Testing" before starting the testing

2.2 - Change JIRA ticket workflow

If Maestrano performs the release, the status waiting for an action from the Enterprise Customer are:

• To be Reviewed by Business
• In Testing

Otherwise:

• To be released
• In Testing

Testing on UAT environment is based on:

• Regression and progression tests scenarios described in the Change ticket
• Tickets included in the release/change scope (make sure that a bug is no more reproducible for example)

During the testing in UAT environment, if new issues are raised or if existing issues included in the release's scope are not closed, a discussion will take place between Maestrano and the Enterprise Customer to decide if the change needs to be rolled-back (following the roll-back plan detailed in the ticket) or if another release is necessary on top of this one before a production release. In both cases, the release will be moved to "Done" by the Enterprise Customer at the end of the testing phase.

2.3 - Change ticket structure

1. high level summary of the change

2. components impacted

3. impact (outage? how long?)

4. tickets raised on the support desk that will need to be tested and validated with this change

5. changelog (all features and bug fixes developed between the version on the environement and the version to be released)

6. deployment procedure

7. rollback procedure

8. tests scenarios (progression and regression) to perform post-release

9. a checklist to confirm that all relevant tests have been performed before the release (unit tests, regression testing, progression testing, performance testing, etc.)

4 - Steps followed by a ticket before a release

4.1 - Process followed by the team

This diagram describes the different statuses of a ticket between "To Do" and "To be Released" statuses.

4.2 - JIRA ticket workflow

• Whenever a ticket is opened, the default value is set to WAITING FOR SUPPORT
• If no technical intervention is needed, the statuses are updated automatically between WAITING FOR SUPPORT and WAITING FOR CUSTOMER
• If a technical intervention becomes necessary, the ticket will be moved to TO DO, IN PROGRESS and TO BE RELEASED

• If Maestrano performs the release, the status waiting for an action from the Enterprise Customer (and therefore a transition performed from the desk by the customer) are:

  • WAITING FOR CUSTOMER
  • IN TESTING

  Otherwise:

  • WAITING FOR CUSTOMER
  • TO BE RELEASED
  • IN TESTING
• Bugs raised or features developed for the enterprise customer are attached to a change when they are ready to be released. As soon as the change has been performed, all these tickets are moved to IN TESTING and needs to be tested then by the Enterprise Customer. Depending on the testing results, the Enterprise Customer can move these tickets to DONE or comment them to send them back to WAITING FOR SUPPORT
• The status ON HOLD is used when a ticket has been deprioritised by the Customer and the Support team but still needs to be kept in the queue