Incremental

Overview

For development teams wanting to pilot new ways of working, this strategy builds upon the Fundamental approach by incrementally updating the repository after each production release.

This approach reduces migration risk by aligning repository updates with existing release cycles, allowing teams to validate JadeGit incrementally without immediately replacing established deployment processes.

When to Use

This strategy is appropriate when:

• A pilot phase is required prior to full adoption of JadeGit.

• The team prefers to align repository updates with existing production release cycles.

• The team can accommodate moderate operational overhead, including repeated extract and registry update cycles during the transition period.

• Parallel operation of JadeGit alongside existing deployment processes is acceptable for a defined period.

• Some traceability of past releases is desired, but full deterministic reconstruction of historical commits is not required.

• Release-boundary snapshots may exist, but full historical reconstruction is not required.

It is best suited for teams that want to maintain release-aligned updates while piloting new workflows.

Approach

Following each production release (using pre-existing deployment processes):

• Take a snapshot of production (or equivalent).

• Repeat the Fundamental extract process without resetting the branch back to the initial commit. This creates a new commit reflecting the latest release.

• Apply the updated registry file to production (or equivalent).

Even if there are no immediate plans to use JadeGit to build production deployments, applying the latest registry to production is recommended. This ensures it is preloaded when production copies are used to refresh test systems, where it will be required to build deployments using JadeGit.

Release Preparation

Rather than waiting until a release has occurred, the above steps can also be carried out using a snapshot of a staging database where a release deployment has just been tested. Depending on how deployments are currently handled, the updated registry file can then be included/applied during the production release.

Post-Release Reconciliation

Following production release, you'd still repeat the steps above, but before extracting:

• Save the current commit (created during pre-release extract using staging database).

• Reset branch to the prior commit (created for the previous release).

• Extract from the post-release production snapshot, using the original commit option to specify the current commit saved above.

If there are no differences detected during the extract, the original commit is preserved. Otherwise, a new commit is created to replace the original. If recreated, you can compare with the original to see what changes have occurred in production since the release was prepared (or unexpected differences in the staging database where release was tested).

When the commit is recreated, this may be disruptive for developers already working on feature branches based on the original (which would need to be rebased). The likelihood of this depends on how frequently emergency or unplanned changes are made directly in production. Even if this occurs regularly, the disruption may be tolerable if it is outweighed by the benefit of aligning developer workspaces with the upcoming release state.

Advantages

• Reduces migration risk by aligning repository updates with existing release cycles.

• Creates a structured pilot period without immediately replacing established deployment processes.

• Builds meaningful commit history based on real production releases.

• Provides visibility into changes included in each release, including interim or production-only modifications.

• Allows teams to validate JadeGit’s ability to deploy and revert complex changes using actual release scenarios.

• Enables gradual process and pipeline updates before fully transitioning to JadeGit-based deployments.

Disadvantages

• Requires ongoing extract and registry update cycles after each release until full adoption.

• Introduces double-handling of changes when work developed in local JadeGit workspaces must still be progressed through existing shared development environments (even with the help of patch extracts).

• May result in an extended pilot period if entrenched processes are not actively phased out.

• Commit recreation during release reconciliation can disrupt feature branches and require rebasing.

• Without automation, the repeated migration cycle may become operationally burdensome.