- 25 Jul 2024
- 3 Minutes to read
- Print
- DarkLight
Repository Overview
- Updated on 25 Jul 2024
- 3 Minutes to read
- Print
- DarkLight
Overview
The Designer Repository provides a centralized location to promote and store changes to Designer Projects, acting as a form of version control. This is highlighted in the image below, where Projects can be deployed from the repository and shared across different environments. Unlike a traditional Decisions Server, a Designer Repository is not used for developing or running applications.
Features and Highlights
- Deploy Decisions Projects/Resources to different environments from a centralized location.
- Store and track changes to Projects through Revisions
- Rollback changes made to Projects to specific Revisions.
- Compare differences between a Project in a linked environment to the copy stored in the Repository.
- Maintain different versions of a Project through Branches
Deploying Projects to the Repository Server?
In version 8, all settings were system-wide. However, in version 9, these settings have been moved inside the Project and have become Project-specific. It is important to note that upgrading from version 8 to version 9 will not move these settings to the Project, even after Project conversion. Instead, these settings will still be present in the system settings and function as intended in version 8.
If users want to make changes to these settings, such as updating the CSS, they will need to move these settings inside the Project using the "Move Folder to Project" user action and make the necessary changes. Failing to do so, the changes may not be reflected in the other environment.
This is because the changes made in the system settings will not be attached to the Project. Therefore, when the project is checked-in (moved) to the Repository, those changes will not be pushed to the Repository Server. As a result, when checking-out (pulling) the Project from the Repository Server, these changes will not be pulled along with it to the Production Server.
In general the folders in the Manage section of a Project will not export during a check-in. However anything created through a dependency or a module, such as message handling related folders and scripting (R, Python, etc) will have its folder and contents exported at check-in.
Also note that Sub Projects are no longer supported in version 9.
Repository Actions
Once a repository environment is connected, Repository Actions become available to Designers. These actions can be found by right-clicking a Project Folder or Designer Element > Designer Repository, and provide the tools needed to move a Project between environments.
Any Designer Element, such as Flows or Rules, checked into a Repository will be labeled as a Resource.
Repository Actions | Description |
---|---|
Checkin Changes for Project | Checks in recent changes made to the Project to the copy stored on the repository. |
Checkout Updates for Project | Check out a copy of the Project from the Repository. |
Show Project | Displays any recent changes for a specific Project on the environment. |
Show All Recent Changes | Highlights any recent changes to all Projects made on the environment |
Revert Changes in Project | Reverts any recent changes to a Project to the copy stored on the Repository. |
Add Dependencies to | Searches for any dependencies that need to be added to the associated Project. |
Remove From Project | Removes the selected element from the Project. |
Checkout Project | Lists all current Projects that can be checked out from the Repository |
Open Repository Server | Opens the Repository server on a new tab. |
Deleting Resources
One of the advantages of using a Repository to manage deployments is that it can delete resources from Projects as part of a code migration.
- When checking a Project with deleted Designer Elements, the related resource will be marked as deleted in the Repository.
- This method is recommended for deleting items from a Project in the Repository.
- When checking out a Project, resources marked as deleted will be removed from the server where the check-out occurs.
- The resource will remain in the Repository in a deleted state. The item will not be checked in.
Branches
Repository Branches are used to create a copy of a Project at a snapshot in time. Each Branch maintains a version of all the resources of the Project independently, allowing multiple versions of a Designer Element to exist within each branch.
Connected servers can only point to one Branch for a Project at a time. Using Branches does not allow connected servers to run two versions of the same Designer Element simultaneously.
Decisions Repository Trunk / Branch structure is set up to do all new development work in Trunk and make new Branches as needed. This is opposite to most traditional Repositories, where work is done in a Branch and Merged back to the Trunk.
Revisions
A Revision is created each time a change to a Project is checked in/committed to a Repository. Revisions are records of changes made to the Project at the time, similar to Checkpoints, but for all Designer Elements in a Project.
Revisions can be used to create Branches for and reverted/rolled back to earlier versions of the Project within the Repository.