Build
The build command provides the ability to build either a complete or incremental deployment, which can then be deployed to a target Jade database.
This command depends on opening a repository to build the deployment from.
Revision
The --revision option may be used to specify a revision string for the deployment. By default, HEAD is used to refer to the current branch/commit.
This may refer to a single commit, in which case a complete deployment will be built.
jadegit build --revision <latest> ...This may also refer to a range of commits, in which case an incremental deployment will be built, including any commands required to rename, delete, move classes, and any other special operations needed to upgrade schemas from the prior version.
jadegit build --revision <previous>..<latest> ...Registry
The --registry option is used to supply the registry file extracted from the target database. For a fresh database, the registry data extracted is empty, so a complete deployment would be built, otherwise an incremental deployment is built based on the prior version info stored within the registry.
jadegit build --registry <path> ...This may be used in combination with the --revision option to specify the latest version to deploy (HEAD by default), but not a range of commits as the previous version info from the registry is used.
jadegit build --revision <latest> --registry <path> ...The --init-registry flag may be used to build a deployment which initializes the registry. This could be used for preparing initial deployments for new databases where the registry will be used to track version info going forward (without needing to extract/use the registry option above).
jadegit build --init-registry ...This may be used in combination with the --revision option to specify either the latest version to deploy (HEAD by default), or a range of commits to setup the registry in a target database for which the previous version has been stored separately, for which the registry will be used going forward.
jadegit build --revision <previous>..<latest> --init-registry ...Merging
The --merge flag may be used to build a deployment which merges the current branch being deployed with those previously deployed to the target database (if possible), rather than implicitly removing them at the same time.
This option is intended to help in situations where there are limited test environments available, or where there's some other benefit to testing experimental feature branches together, without needing to formally merge/integrate them into a common branch prematurely. This option is not intended for deploying multiple branches to a production database (for which deploying a single branch/tag is recommended).
This option depends on using the registry (supplied using --registry option above), from which the list of branches/commits deployed previously are retrieved. These are evaluated to determine if the current branch being deployed is based on any of those deployed previously, in which case, the current branch will replace them (otherwise it is simply added to the latest list of branches for deployment).
When this option isn't used, but was used previously, the list of branches/commits deployed previously is still retrieved & evaluated, as any changes merged previously which are not included in the current branch being deployed will be implicitly removed (with the latest list of branches for deployment essentially being cleared/replaced by the current branch).
During the build, when there were and/or will be multiple branches deployed, they're merged together to form the basis of the previous/latest versions that are used to build the deployment as usual (with the registry being updated to reflect when there's multiple branches/commits deployed). If there are any merge conflicts, the build will fail as this indicates there's overlapping changes which need to be formally merged/integrated into a common branch before they can be deployed together.
This feature is experimental. The current implementation needs improvement to use a more appropriate merge strategy that will avoid merge conflicts wherever possible.
Formats
The format of the deployment to build is specified via a subcommand.
The mul subcommand provides the ability to build a standard multiple schema file extract.
The destination output directory is required, and an optional name may be specified which defines the name of the *.mul file created.
jadegit build --revision v0.1..v0.2 mul --name "Update" C:\temp\buildWhile registry options can be used for building, this format does not generate the file needed to update the registry in the target database. Support for this may be added in future, however executing the registry load command would still need to be handled after loading the schema files.
Due to Jade platform limitations, this format does not support the use of command files (needed to handle renames and other special operations).
The pwsh subcommand provides the ability to build a scripted deployment using PowerShell.
Use the following command to run the deployment from the output directory (copying to host of the target database beforehand if required).
.\deploy.ps1 -bin "C:\Jade\bin" -path "C:\Jade\system" -ini "C:\Jade\jade.ini"By default, this will deploy changes in an offline manner with the use of the 'singleUser' server mode when opening the database, where it's expected the database server will have already been stopped before deploying (and then restarted afterwards).
To deploy changes in an online manner without needing to stop the database server entirely, you can specify the use of the 'multiUser' mode using the server option.
.\deploy.ps1 -bin "C:\Jade\bin" -path "C:\Jade\system" -ini "C:\Jade\jade.ini" -server "multiUser"While the database server doesn't need to be stopped, applications using schemas affected by a deployment do still need to be stopped/restarted in order to allow for reorg's during the deployment.
The jari subcommand provides the ability to build a Jade Authorised Release Instruction (JARI), for deployment via JSM (JadeCare Systems Manager) to managed environments.
The --environment option is required to specify the JSM environment name.
The --description option is required to specify a short description for the deployment.
The --developer option is used to specify the JSM username for the developer to be notified, which is also used for authorisation by JSM (hence this is currently required).
The --working-directory option is currently needed to define what directory the deployment files will be copied to & submitted to JSM from.
The --defeat-backups, --defeat-pre-backup or --defeat-post-backup options may be used to suppress backups JSM may otherwise take before/after deployment.
The xml subcommand provides the ability to build a generic deployment, with an XML instruction file intended to be transformed/processed as needed by third parties to handle deploying/publishing updates in a customized manner.
This format doesn't currently support the use of registry files. The structure of the XML instruction file will likely change when support is implemented in future.
Last updated