Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 4 Next »

Sometimes it is necessary to make manual changes into database environments.

For example, a release went out to PROD environment, however, there was an issue which impacted the PROD database. The issue is immediately root caused and the solution is applied manually to PROD database. How then do you make Datical aware of those manual changes?

Note that any manual changes made to a Datical-managed environment should ultimately be deployed to all environments in the pipeline. This will allow the pipeline to remain in sync with respect to changes deployed over time. 

Solutions

There are three different paths to accomplishing this:

1. No manual changes - fix issues like all other changes

This is applicable when you have the sufficient time window to root cause the issue, script it, commit into SCM, package and deploy into your pipeline just like normal changes/ This means you will always leverage your automation framework.

2. Use a "hotfix" process to package changes and deploy directly to STAGE and PROD. 

This allows you to bypass deploying into your DEV and QA environments and hotfix changesets can be deployed directly to STAGE and PROD. You will be responsible for eventually deploying your hotfix changes back into DEV and QA environments, typically performed after hotfix changes have released to PROD.

3. An emergency fix is necessary 

You only have a small time window to fix the PROD database. In this case, you will root cause your issues, test your fix in STAGE and once validated, deploy to PROD.

Start by capturing the hotfix in a SQL script. Commit the script into SCM so that it can be packaged, converted into a changeset and deployed (i.e., backfilled) into all other environments. Since PROD environment already contains the change, there is no need to deploy the changeset there. Instead, you will use Datical's "Change Log Sync" feature to mark the hotfix changeset as EXECUTED in PROD environment. This will create an entry in PROD's tracking table (DATABASECHANGELOG) and the audit database. This results in Datical becoming aware that the change from hotfix changeset already exists in PROD.

Step-by-step guide

For the purpose of the document, we will assume that the Datical project has the following pipeline (see table below). The hotfix is captured in the script called "hotfix_aug.sql". Changes from this script have been manually executed in STAGE and PROD environments. We now need to package this script so that it can be deployed to REF1, DEV and QA environments.



REF1

DEV

QA

STAGE

PROD

hotfix_aug.sql

UNDEPLOYED

UNDEPLOYED

UNDEPLOYED

MANUALLY DEPLOYED

MANUALLY DEPLOYED


  1. Instruct Datical to abandon the script "temp_table.sql". This will require adding the label "abandoned" to all changesets that generate from this script. You can perform this task in automation, however, the user will need to provide the script name as a parameter. In your automation system (Jenkins, Bamboo, UrbanCode Build, etc.), create a new job which will perform following operations:



  • No labels