Parallel Development of a Model for the Current and Next Release
A common use case when developing a model is wanting to make maintenance fixes for the current release of a model, while making more significant changes for the next release of that model.
A possible solution is to clone of the model so that you have two separate models, one for developing the current release, and one for developing the next release. Although this solution allows you to make changes for the next release of the model without affecting current release of the model, it is inefficient because the maintenance fixes will have to be made in both models.
A better solution is to use the sandboxing features of Modeler that support parallel development of a model. The current release of the model can be maintained in the trunk, while development of the next release can be made in isolation through a sandbox. The maintenance fixes that are made to the trunk can be merged easily to the sandbox through a rebase operation.
Usage
From Model Explorer, right-click the latest version of the model, point to New and then click New Private Sandbox.
Note that a trunk version number is an integer value, such as 1. A branch version number has three parts, such as 1.1.0. The previous use case describes how the sandbox version numbers are derived.
Use the trunk to make maintenance fixes for the current release of the model. use the sandbox to make changes for the next release of the model.
Maintenance fixes that are made in the trunk for the current release can be merged to the sandbox for the next release. You do this through a rebase operation. To rebase a sandbox, right-click the tip version of the sandbox, and then click Rebase.
When it is time for the next release of the model to be released, merge the sandbox to the trunk so that the next release in the sandbox of the model becomes the current release in the trunk. You do this through a reconcile operation. To reconcile a sandbox, right-click the tip version of the sandbox, point to Reconcile, and then click To Trunk.
To make further changes for the next release, you repeat the process by creating a sandbox from the latest version of the trunk.
Benefits
Efficiency: Maintenance fixes have to be made only in the trunk for the current release of the model. Rebase operations merge those changes to the sandbox for the next release of the model.
Parallel development: Changes made to the Next Release of the model in the sandbox do not affect Current Release in the trunk.
Recommendations
It is good practice to always rebase a sandbox before reconciling it, so that changes can be tested privately in the sandbox before being reconciled with the trunk.
If you rebase often then this creates frequent but smaller integration work. If you rebase infrequently then you increase the risk of larger integration work. This is known as the integration-versus-isolation conundrum. When using sandboxes, the goal is to achieve a balance, that is, do not rebase so often that it causes disruption to the development of the next release, but rebase often enough to keep abreast of the maintenance fixes in the current release.
After reconciling a sandbox, the tip version of the trunk will be protected. Do not unprotect the tip version of the trunk. This significantly improves the time taken to create and reconcile sandboxes and reduces contention. To continue development of the trunk, create a new version of it.
To make appropriate use of this architecture it is strongly recommended that Full Logging is enabled and the database is backed up regularly. It is also prudent to periodically test the integrity of the backup processes by exercising the restoration capabilities.