Build
Last updated
Last updated
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.
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.
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.
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.
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.
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).
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.
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.
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.
While 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 limitations, this format does not support the use of command files (needed to handle renames and other special operations).
