JadeGit
DownloadsSource
0.14.0
0.14.0
  • Welcome
  • Developers
    • Getting Started
      • Repositories
      • Branches
      • Remotes
    • Making Changes
      • Adding Schemas
    • Deployments
      • Scripts
    • Platform Support
  • Troubleshooting
  • Deployment
    • Overview
    • Registry
  • Console
    • Overview
    • Install
      • Clone
      • Fetch
    • Open
      • Switch
    • Extract
      • Commit
      • Backfill
    • Registry
    • Build
  • Migration
    • Overview
Powered by GitBook
On this page
  • Revision
  • Registry
  • Merging
  • Formats
  1. Console

Build

PreviousRegistryNextOverview

Last updated 3 months ago

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 to build the deployment from.

Revision

This may refer to a single commit, in which case a complete deployment will be built.

jadegit build --revision <latest> ...
jadegit build --revision <previous>..<latest> ...

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).

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 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\build

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.

The --revision option may be used to specify a for the deployment. By default, HEAD is used to refer to the current branch/commit.

This may also refer to a , 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 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 option depends on using the (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).

The mul subcommand provides the ability to build a standard .

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 command would still need to be handled after loading the schema files.

revision string
range of commits
extracted
registry
multiple schema file extract
registry load
opening a repository