BuildMaster Documentation


  • Last Modified: 2019-12-04

BuildMaster does not have a special "rollback plan" that's used only in emergencies. Since such a plan would only get tested in rare cases (i.e. when something went wrong), chances are it will be out of date and likely make things even worse.

But what we can do is perform a "Re-Deploy", which can effectively be used to rollback changes. Assuming you have your deployment plan configured correctly. Let's consider the state of a given application.

Performing a Rollback

You'll note below that Release 1.0.3 (Build 1) was deployed to Production.

Step 1: Navigate to Promotion Details

To go back to Release 1.0.2, navigate to the promotion details of the production-promoted build for that release.

Step 2: Re-Deploy to Production

You'll notice there's a big button called "Re-Deploy to Production". Clicking on that will run the production deployment plan using 1.0.2 Build 3's context.

Step 3: Deploy the Artifact

You'll have the option to deploy the artifact immediately, which is common for most rollbacks as they are generally considered emergencies, or at a specific time in the future.

The actions in a deployment plan are designed to look at the execution context to determine what to do. In this case the plan will deploy the artifact associated with Release 1.0.2 Build 3. This will ensure that whatever files were deployed with Release 1.0.2 Build 3 will always be deployed with Release 1.0.2 Build 3.

Once the Release 1.0.2 Build 3 has been re-deployed, that information is reflected in BuildMaster.

And like that, your changes are rolled back. Of course, this isn't a time machine and nothing (not even a time machine) can reliably and perfectly rollback all changes while keeping existing data.

So, be careful using re-executions / rollbacks.

Is this documentation incorrect or incomplete? Help us by contributing!

This documentation is licensed under CC-BY-SA-4.0 and stored in GitHub.

Generated from commit bd2ce6f3 on master