Explained: Executer Stage

During the Executer stage, SQL --previously created by the Templater stage-- is executed to one of the DTAP environments. More precisely, only the files that are changed in the preceding Templater commit are executed in full. We refer to the contents of these files as the actual change. The deployment order is as follows: → Test → Acceptance → Production. Note that every arrow requires a manual approval; a users needs to confirm that the next environment is ready for the change.

A Deployment is performed by the Executer as follows. First, the Executer determines the files involved in the Change. Next, these files are executed from top to bottom and in alphabetical order. From this precedure, it follows that SQL files need to be designed with multiple execution in mind. Otherwise, an execution of a full file with a minor change would not be succesful.

If an error occurs during the Deployment, the Executer logs the error and skips the remaining statements in the file it is executing. It continues with the next file if one exists as shown below. Numbers illustrate the order of execution.

Execution logs of a Deployment are added to the repository after the Deployment is complete. The Executer creates one execution log per SQL file it executed. An execution log is the original executed SQL source annotated with a color. Green colored SQL statements are executed succesfully, visa versa for red colored statements. NOTE: At most one red statement can be found at the end of an SQL file, because the executer skips statements after a failing statement

ADM guarantees that when conflicting changes deployed similtaniously, a risk is introduced that tests are invalid.

It takes time to deploy a change first to Development, followed by Test, followed by Acceptance to finally be deployed in Production. When multiple changes are simultaniously in transit, one change can overtake another, introducing the risk that a test can be made invalid. Take the following example as illustration:

The above mentioned cases can occur on Acceptance in the following scenario:

Our solution is simple: before any change is deployed by the Executer, we execute to the DryRun environment first. This will ensure that if the order of execution is inverted and an error would occur, that this error would be caught in the DryRun environment, enabling the developer to make a fix.