HOWTO Add a CR to SEAD change control system

[roger-mahler]

Add a new SEAD database change request (CR)

** NOTE: This instructions are outdated. Will be updated soon. **

Prerequisites

• Latest version of humlab-sead/sead_change_control repository.
• The sqitch system installed on the same server as the repository.

Steps to add a new CR

1. Create a new change request

% cd path/to/sead_change_control
% sqitch add SPECIFIER -n "A short description of name" -C ./target_folder

where

• SPECIFIER is the name of the CR should for consistency purposes be formatted as YYYYMMDD_DDX_SPECIFIER (all capital case), where DDX is DDL or DML and specifier is a short identifer of the change request.
• The short description should be a one-liner (could also reference a Github issue)
• The target folder is a high level sorting of the change request) and must be one of those stated below.

Valid target folders are:

• bugs Changes related to the migration of Bugs data to SEAD
• report Deprecated.
• sead_api Changes related to external access interfaces to the SEAD database.
• submissions Submissions of new data to SEAD clearinghouse.
• general General updates and patches to the SEAD data.
• security Changes related to users and security.
• subsystem Deploy script of subsystems e.g. the clearinghouse subsystem.
• utility Changes and updates to utility features.

Each target folder contains three subfolder:

• deploy SQL scripts that implements the change requests
• revert SQL scripts that reverts the change requests
• verify SQL scripts that verifies the effect of applying the change request.

Executing the sqitchcommand adds a file named SPECIFIER.sql into each one of the three subfolders.

Example:

% sqitch add 20200429_DDL_UDF_FACET_UPDATE -n "Better handling of updates to an existing facet" -C ./sead_api

2. Implement the change request

Implementing the deploy script i mandatory, whilst the revert and verify isn't (at least for the moment). Please make the deploy script idempotent, i.e. successive runs of the same script should have no effect. Simply put a guard at the start of the script to prevent subsequent executions.

3. Deploy the change request

No further action is needed, the change request will be deployed at the next monthly release.