Repository Overview

Overview 

The Designer Repository is a special type of Decisions server used for storing Project resources and version control. Its job is to help in storing Projects and to promote changes between environments. Unlike a traditional Decisions Server, a Repository is not used for developing or running applications. When a Project or application moves from one environment to another, change of management from one Administrator to the other also occurs. Account Permissions should be monitored so that the appropriate Accounts are given administrative access. 

Repository Methodology

There are two main methodologies for using a Repository:

• Projects are checked into the Repository when development on a feature is complete, and that feature is ready to be promoted to a test environment.
  • The Development Server is the source of truth for in-progress work, and the Repository is the source of truth for Projects that are ready to promote.
• Changes to a Project are Checked In as they are done (typically at the end of the day).
  • The Repository is the source of truth for in-progress work, and for Projects that are ready to promote.
  • In this case, users need to be Checking Out the latest updates at the start of the day to make sure they have up to date versions of dependencies
  • This method is needed when multiple developers are working on independent local development instances of Decisions.
  • When following this pattern, using Branches for completed versions becomes very important.
    • E.g. Branch is a slice to move in series of environment such as: Dev > QA > UAT > Performance Testing > Staging > Production

Project Setup/Structure

Key things to keep in mind when setting up Project structure:

• Will multiple people be working on the Project at the same time?
• Will resources from this Project be used in other Projects?
• What is the smallest group of resources that will be wanted for Check In or out from the Repository at one time?
• What data will be generated while building/testing the Project? Is this data that will need to be moved with the Project or should it remain on the Dev Server?

Checking In

Creating a New Project

The first time resources are Committed to the Repository from a server, a Project will need to be created for those resources.

• The action to Create New Project happens on the development server, not in the Repository. 
• To create the project, navigate to the folder containing the resources and use the Add To Project option in the Designer Repository section.

Checking In Changes

When Checking In changes to the Repository, by default Decisions will attempt to Check In all resources for that Project that has been modified since the last Check In. Decisions will show a checklist of all items with changes. Select or deselect as needed before confirming the Check In. The Repository also offers the ability to only Check In items that have been modified by the current user.

• If a user is Checking In everyday dev changes on a Project with multiple developers, they will most likely only want to Check In for the current user.
• If a user is Checking In final development changes for a migration, they will most likely want to Check In all changes.

Checking Out

Checking Out A New Project

Checking Out a Project for the first time is very similar to Importing a Project for the first time.

• On any Folder, navigate to the Designer Repository option and select Check Out Project.
• Select the desired Project to check out, and then follow the normal Import process.

Checking Out Updates

When updating resources from the Repository, (either deploying changes to QA or Prod, or getting updates on a Dev Server) those changes will need to be Checked Out from the Repository.

• Decisions will compare the Local Project resources against the Project resources stored in the Repository.
• A list of resources will be shown to the user to download.
• After downloading the resources, the check out will proceed like a normal Import.

Deleting Resources

One of the advantages of using a Repository to manage deployments is that it provides the ability to delete resources from a Project as part of a code migration. However, deleting a Flow from a Project and deleting the resource from the Repository are two different things.

• Checking In a Project with a deleted resource will mark the resource as deleted in the Repository.
  • This is the recommended method for deleting items from a Project in the Repository.
• When Checking Out the Project, the deleted item will be deleted from the server where the Check Out occurs.
• The resource remains in the Repository as a part of the Project in a deleted state.

How to Delete From the Repository 

• Items can be deleted directly from the Repository by right-clicking a resource and selecting the Delete action.
• This will prompt the user to determine whether to Delete the resource from all Branches of the Project or only the current Branch.
• It is recommended to Check In deletes for a Project rather than deleting directly in the repo, as this ensures consistency between the source environment and the Repo with the least chance for errors occurring.

Branches

What Is A Branch?

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. Unlike a normal Development Server which does not allow two versions of the same Flow, using Branches can produce this behavior on the Repository.

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 from most traditional Repositories where work is done in a Branch and Merged back to Trunk. 

When To Use A Branch

Use a Branch when:

• A specific version of a Project needs to remain unchanged while changes are still being Checked In to the Repository from a Dev Server.
• The ability is needed to update the version of a Project on QA/Prod, but additional work has been done on Dev that is not yet ready to be promoted.
• The ability is needed to keep distinct versions of a Project.

Common Branch Use Examples

A Development team has been checking work into the Repository, and the Project is now at a stable point and ready to promote. A Branch is created for this version. QA or Prod is pointed to this version Branch. Development continues on new features that are checked into Trunk. As testing progresses, an issue is found on the Branch that needs resolved. The Development Server can be pointed to the Branch to make the fix, and then pointed back to Trunk. This way new dev work is not lost to revert to the stable version.

A similar case is that a Branch has been cut for testing. Additional work continues to be checked into Trunk. When QA is finished the branch can be promoted to Production independent of the changes that have been made in Trunk and have not yet gone through QA.

How To Use A Branch

New Branch

• Creating a new Branch is done on the Repository Server.
• Navigate to the Project that needs the Branch.
• Right-click and select Create Branch.
• Resources in the New Branch are copied from the currently selected Branch.

Changing Branches

• Each server points to a specific Branch.
• To change the Branch, go to System > Designers > Repository.
• Clicking on a Project will give the option to change the Branch.

Important Notes On Using Branches

• Changing a Branch will update the server to match the Branch in the Repository.
  Warning on Switching Branches Without Check In

   Always make sure to Check In changes before switching Branches or work will be lost.
• Because a server can only be pointed to one Branch, changing the Branch will change it for everyone on that server. Please be sure to let others know if they are working on the same Project.

How To Move Changes Between Branches

• Changes made in Branches can be merged to Trunk or other branches using the Merge to Branch action.
• Selecting this action on the Branch with changes needing to be merged will display a list of available Branches for the Project.
• Selecting one will provide a checklist of objects listed as differences between the two Branches.
• All selected items will be merged into the selected Branch.

To manually move changes between Branches:

• Log in to the Repository.
• Navigate to the Folder for the Branch with the change that needs to be merged.
• Download the component that needs to be merged from the Branch.
• Import the component on the server that needs the changes.
• Check the changes into the Repository.

If there is no access to log into the Repository or if the server is already pointed to the branch with the changes that need merged, use the following method instead:

• Point the server to the Branch with the change that needs to be merged.
• Manually Export the component that needs to be merged.
• Point the server to the Branch that needs the changes.
• Import the component.
• Check changes into the Repository.

Features and Highlights

• Transfer Decisions Projects/Resources to and from the Repository.
  Note on Port Communication
  When communicating between the Designer Studio server and the Repository server, ports 80 or 443 are utilized depending the browser. The servers communicate via a service call to the ports based on the browser's URL of the Repository server.
• Store Historical Versions of each Project.
• Store and track changes to Projects across multiple developments and release Branches.
• Compare the differences between a Project in the Decisions environment and the copy stored in the Repository.
• Update a Decisions environment to match a Project Branch at a specific point in time, including the removal of any components deleted from the Project.

Reference Articles

For more information regarding the Designer Repository, please visit any of the related articles in the knowledge base below.

• Repository Installation
• Repository FAQ
• Repository Features and Functions
• Repository Revisions
• Using the Repository
• Repository Action Flows
• Connecting a Decisions Server to a Repository Server