Installation > Appendix 1: Configuration Management Use Cases > Developer Isolation in Support of Code and Debug Cycles
Developer Isolation in Support of Code and Debug Cycles
During an implementation phase when the model is used for code generation, it is important that it can be changed in isolation from other users in a controlled manner. Isolation allows a developer to compile and debug generated code generated from the model without being affected by, and without affecting, other users working on the same model. Isolating developers supports concurrent development on the same code base and is therefore an enabling factor for increased team productivity during an implementation phase.
Modeler's private sandbox supports the ability to create, branch and merge private workspaces at model-level. This technique applies a branch-per-change policy, so when you create a private sandbox from the model, the trunk is protected by default to provide a stable baseline. Developers work in isolation using a new private sandbox for each change. The sandbox represents a private view of the configured data in the model, rather than a copy of the data, and by default the sandbox is visible only to the user who created it (and Database Administrators).
When work is complete in a sandbox a Reconcile operation is used to publish the changes into the trunk model. This uses the new merge engine in Modeler to resolve conflicts where the same items have been changed by different users. This process is known as a 3-way merge. The 3-way merge uses the trunk version of the model from which the sandbox was created, the latest trunk version and the sandbox version. The 3-way merge automatically applies all non-overlapping changes from each version. If any changes were overlapping, then these are brought to the attention of the user for resolution.
Whenever a rebase or reconcile is performed the trunk version is protected during the merge. After being reconciled the sandbox is protected and hidden from the normal Model Explorer view. A new sandbox needs to be created for the next change and the process repeats. The sandbox version prior to a Reconcile is available when the Show Versions toolbar button is selected in Model Explorer.
When sandboxes have been created from the same version of the trunk, those sandboxes can be reconciled with each other before reconciling the resultant model to the trunk.
In addition to the Reconcile operation a new Rebase operation is provided in Model Explorer for a user to update their sandbox with changes in the trunk. A Rebase is normally performed prior to a Reconcile so that the merge can be tested in the sandbox without affecting other users, and any conflicts can be resolved.
Differencing functionality is also provided to assist with the review of changes. Optionally, you can also use Change Tracking to document and track changes to the model.
Usage
From Model Explorer, right-click a model, and select New and then click New Private Sandbox to create a personal branch of the selected model.
Notice that trunk versions of a model have an integer value, starting at 0. The sandbox versions of a model have three parts delimited by periods, such as 1.1.0. The value of each part is determined as follows:
The first part is set to the model version in the trunk from which the sandbox was created. For example, if a sandbox has a version number of 2.1.3, you know that it was created from version 2 of the model.
The second part is determined by how many sandboxes have been created from the same trunk version. For the first sandbox that is created from a trunk version, the value is set to 0, for the second sandbox that is created from the same trunk version the value is set to 1, and so on. For example, if a sandbox has a version number of 2.1.3, you know that it is the second sandbox to be created from version 2 of the model.
The third part is determined by how many times the sandbox has been versioned. When the sandbox is created, this value is set to 0. For the next version of that sandbox, the value is set to 1, and so on. For example, if a sandbox has a version number of 2.1.3, you know it is the fourth version of that sandbox.
From Model Explorer, right-click a sandbox, and select Reconcile > To Trunk to merge the changes from a private sandbox into a trunk model. Conflicts where the same model item has been updated in parallel will be reported and can be resolved before creating a new version of the trunk.
From Model Explorer, right-click a sandbox and click Rebase to merge changes in the trunk into a private sandbox. Conflicts where the same model item has been updated in parallel will be reported and can be resolved before creating a new version of the sandbox.
Benefits
Storage efficiency: Private sandboxes represent a view of the configured data objects, rather than a copy. This means that private sandboxes are much more disk efficient than replica models (the previous technique used by PTC to support isolation).
Model consistency: The merge process is designed to ensure that all dependent changes are merged together. Deleting an Operation on a Class, for example, will affect that Class as well as any diagrams where that Operation is referenced. This means that model consistency can be preserved automatically for a given Rebase or Reconcile operation.
Recommendations
Use a private sandbox for each separate change or set of dependent changes made by one user. A sandbox should only be shared with another user when very close cooperation is needed. Although access permissions can be changed, by default a sandbox is private to the user that creates it.
It is good practice to always rebase before reconciling, so that changes can be tested privately in the branch before being reconciled to 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 your tasks but rebase often enough to keep abreast of changes that may affect your work.
Do not unprotect the trunk model. The trunk model will be protected by default. This significantly improves the time taken to create and reconcile sandboxes and reduces contention between users.
If the changes need to be abandoned, the sandbox can be kept without being reconciled or deleted.
After a milestone is reached, old reconciled sandbox versions can be deleted by the Database Administrator or Model Owner, if desired, as the reconciled changes can be constructed by comparing the trunk versions.
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.
The Modeler Help has a topic on database-based configuration management; including a review of terminology and working with branches, see the Database-based Configuration Management section of the Modeler Help.