Using Moves - Procedures

This document outlines recommended procedures for using the Moves build and release management tool.

Normally, deployments to Test and Production are steps that continue an existing workflow that was initiated by a "Build a Release". So the "Deploy to Test" and "Deploy to Production" links on the Workflows page should not usually be used, as they start their own new workflows.

The situations where these top-level links should be used are limited to re-running failed deployments.

Workflows that have reached the "deployed to test" stage and are not going to be taken any further should be terminated so that the list of active workflows remains manageable. The time at which it becomes known that such a workflow should be terminated is typically when a new release is to be built. So part of the process for building a new release should be to terminate any previous active workflows for the app.

Typical Process (on the trunk):

1. Build a Release (select trunk)

2. Deploy to Test

3. SIT/UAT takes place - issues raised, fixes made.

4. Terminate previous workflow

5. Repeat 1-3 until SIT/UAT passes

6. Deploy to Prod

Typical Process (on branch)

1. Branch a release

2. Build a Release (select branch)

3. Deploy to Test

4. SIT/UAT takes place - issues raised, fixes made.

5. Terminate previous workflow

6. Repeat 2-4 until SIT/UAT passes

7. Deploy to Prod

Typical Process for QA deployment

This requires a release to have been built

1. Deploy to QA

Typical Process for re-deploying to Test

This should only be necessary if a deployment to test failed.

1. Terminate failed test deployment

2. Deploy to Test from top-level Workflows link

Typical Process for re-deploying to Production

This should only be necessary if a deployment to prod failed.

1. Terminate failed prod deployment

2. Deploy to Prod from top-level Workflows link