How To: Unabandon changes

This solution is needed when some changes were previously abandoned in a release but now need to be allowed to proceed forward as part of a new release. 

Considerations

As you plan to unabandon changes, take the following into consideration:

1. Are the previously abandoned changeset ready to be promoted without any modifications?
2. If previously abandoned changeset require modifications then bring a "fix" script.
   1. Can the fix be applied together with the previously abandoned changesets such that original changesets and the fix changeset be applied together all the way to PROD?
   2. Or does the fix script need to be applied to remove previously deploy changes? In this case, you would only need to apply the fix script only into those environments where previously abandoned changes were already deployed. This can be controlled using "contexts". Follow the steps described in How To: Abandon changes in order to fully abandon your changes. This would effectively clean your environments from abandoned changesets. You would then bring a modified version of the abandoned script to package and deploy into the pipeline.

Step-by-step guide

Following steps guide you towards unabandoning your changesets assuming that those changesets do not require any modification. 

For the purpose of the document, we will assume that the Datical project has the following pipeline and that all changesets generating from "temp_table.sql" were previously abandoned for release 1.0.0. And prior to getting abandoned, those changes had been deployed up until the QA environment. We now need to unabandon changesets from this script so that those can be deployed to STAGE and PROD environments as part of release 2.0.0. As such, you will remove the label "abandoned" from those changesets. And you will add the new label for the release (release/2.0.0).

You can perform this task in automation, however, the user will need to provide two input parameters: 1) the script name to unabandon and 2) the new release label. In your automation system (Jenkins, Bamboo, UrbanCode Build, etc.), create a new job which will perform following operations:

1. Checkout Datical project from your source control (Git, TFS, SVN)
2. Run "hammer removeLabels" command. This command takes two arguments:
   1. lookupChangesets - This is the script name which you want to abandon, e.g., "abandoned,temp_table.sql". The "temp_table.sql" will be the FIRST user provided argument.
   2. labels - This is the label you want to remove from your changesets, e.g., "abandoned"
      1. Once you agree on what naming convention to use to abandon changes, this argument can be programmatic (e.g., "abandoned/1.0.0") or hard-coded (e.g., "abandoned").
3. Run "hammer addLabels" command. This command takes two arguments:
   1. lookupChangesets - This is the script name which you unabandon, e.g., "temp_table.sql". The "temp_table.sql" is the FIRST user provided argument.
   2. labels - This is the new release label you want to give to your changesets, e.g., "release/2.0.0". The "release/2.0.0" is the SECOND user provided argument.
4. Commit and push Datical project back into source control

Here is the complete sample script with some additional code for before and after status:

• Perform SCM operation so that you can check-in your changes back into SCM ("git branch --set-upstream-to ...")
• "hammer findChangeSets" used to identify labels before and after applying the "removeLabels" command (note: This code is for Windows batch command):

• Perform SCM operation to commit and push the code and provide a relevant commit message ("git commit ..." and "git push ...")

echo -------------------------------
set PATH=%PATH%;C:\apps\Datical\repl

git clone http://user@bitbucket.datical.net/scm/bbu/ddb.git
cd ddb

git branch --set-upstream-to=origin/master master 
git status

call hammer findChangeSets --lookupChangesets="abandoned,%lookupChangesets%"
echo
call hammer removeLabels --lookupChangesets="abandoned,%lookupChangesets%" --labels="abandoned"
echo
call hammer addLabels --lookupChangesets="%lookupChangesets%" --labels="%newReleaseLabel%"
echo
call hammer findChangeSets --lookupChangesets="%lookupChangesets%,%newReleaseLabel%"

REM add steps to commit Datical project into Git.
echo commit new changes back into Bitbucket
call git add -A
call git commit -m "Automations:UnabandonScript-%lookupChangesets% - build number=%BUILD_NUMBER%"
call git push -u origin master
echo -------------------------------

Here is how your automation job would report your unabandoned changesets:

• Notice that one changeset was identified with lookupChangets="abandoned,temp_table.sql". Later, the same changeset was identified when lookupChangesets="temp_table.sql"

hammer findChangeSets --lookupChangesets="abandoned,temp_table.sql"

_______________________
| Change Set ID| Author|
|======================|
| Temp_Table   | amalik|

hammer removeLabels --lookupChangesets="abandoned,temp_table.sql" --labels="abandoned"

Labels removed for change set Temp_Table
Updating labels for change set Temp_Table
hammer findChangeSets --lookupChangesets="temp_table.sql"

_______________________
| Change Set ID| Author|
|======================|
| Temp_Table   | amalik|

Here is how the abandoned changeset looks like in Datical GUI:

Now that the "abandoned" label has been added, you want to make sure that you alway deploy using "!abandoned" label (notice the "!") with your deploy automation tool. Here is a sample deploy command you would use:

1. 1. hammer deploy STAGE --labels "release/2.0.0 AND !abandoned"
   2. hammer deploy PROD --labels "release/2.0.0 AND !abandoned"

Related articles

• Page:
  How To: Remove abandonded changes from Liquibase Enterprise and lower environments
• Page:
  How To: Negate changes
• Page:
  How To: Abandon a Single Changeset from a Script
• Page:
  How To: Unabandon changes