Integrations Change Management

1. You are here:
2. Business Technology
3. Enterprise Applications Team
4. Enterprise Applications Integrations
5. Integrations Change Management

On this page

• Workato changes
• Nestjs changes

The integrations change management process is an extension of the Business Technology Change Management process which is tailored to the SDLC of the integrations team.

The team develops integrations with two tools; Workato and Nestjs and the change management process currently differs between them.

Workato changes

Workato is a tool that helps you manage your integrations. It is a web application that allows you to manage integrations, environments, and deployments. All of this is done using a drag and drop interface which makes it an easy tool to quickly get started with, however it also makes change management more difficult. The current process for change management is this;

1. Follow the BT change management process but create the change issue within the Platypus project.
2. Add the appropriate change management label to the issue using the approval matrix. If the change is comprehensive, add the Business Owner Approval::Needs Approval label.
3. Receive approval from the business owners of any affected systems in the change and have them comment their approval and add the Business Owner Approval::Approved label to the issue.
4. Once the change is made in development, link the relevant recipes and changes in a comment on the issue and request peer approval from someone else on the integrations team. Have them comment with their approval and add the label Peer Approval::Approved to the issue.

Nestjs changes

For Nestjs the process is the same, except that for peer approvals, we utilize Merge Request approvals instead of labels. The merge request template will guide devs through applying the right labels and linking the relevant change management issue.

To ensure that we don't have long lived merge requests, we have the option to use feature flags to toggle the change / feature. That way we can maintain the prior functionality in production until the business owner has approved the change management issue. The benefit of doing this is that we reduce the need for constant conflict resolution and peer reapproval due to MR approval resets on all commits. Feature flag toggling should be performed by a different person to the author of the MR.