...

Delete Model and Commit Changes

...

Create Branch

Users will click the workflow button to create a new branch, which executes the ed3d_create_feature_branch template.

...

Close Branch 

Users will click the workflow button to close a branch, which executes the ed3d_close_branch template. 

...

...

CONFIGURING WORKFLOWS

Users will find the GIT integration tools within the Workflow pane. Depending on the type of model you are currently viewing, there may be different buttons available by default.

All existing WhereScape 3D workflow functions remain available. However, a maximum of 12 functions can be visible at a time, so users with pre-existing Workflow set-ups may need to manually reconfigure the Workflow to pick and choose which functionality they want to keep or replace.

Users can update their Workflow sets by doing the following:

1. Click on Tools > Manage Workflows.
   Image Added
2. The user will be presented with a list of customer model versions. Click on a version to view the Workflow configuration in the panel to the right.
   Image Added
3. The user can either create a new Workflow set from scratch or edit an existing Workflow set.
   
   1. To create a new Workflow set the user can click on the 'Add Workflow Set' icon. Give the workflow set a name, select the Type from the dropdown and select 'OK'.
      Image AddedImage Added
   2. To edit an existing Workflow set, the user can highlight the set they would like to edit by clicking on it, to bring up the Workflow configuration panel.
4. Users can add new buttons by clicking on the 'Add Button' icon positioned above the Workflow configuration panel.
   Image Added
5. The user can then provide the details of their Workflow:
   1. Provide the name for the workflow button you are adding.
   2. Provide a description for the workflow button (optional)
   3. Select an Icon to represent your workflow button.
   4. Select the Type of workflow item you want to add. All GIT integration Workflows are kept as type 'Script'.
   5. Select the script from the dropdown which represents your required Workflow.
   6. Once you are happy with your Workflow button, click 'Apply'.
      Image Added
6. The user will see their new Workflow button in the Workflow configuration panel.
   Image Added
7. Users can reposition or delete any workflow buttons by right-clicking on a button and choosing the required action.
   Image Added
8. Once the user is happy with their configuration, they can click 'OK'.

3D FAQS

Conflicts when merging branches

The Development Lead creates two feature branches, one for Developer A and one for Developer B.

Monday: Developer A completes their development within their feature branches, then merges the feature branch into Development.

Tuesday: Developer B completes development within their feature branches and then merges the feature branch into Development. This merge fails because both developers have made changes to the same model, resulting in a complex change that can not be automatically merged. In other words, there is a lack of understanding about which changes should be kept and which should be overwritten.

Therefore, the “close and merge” function will produce an error with a list of failed objects (within WhereScape 3d).

The “Import Model” function within 3D enables the developers to handle this situation.

The Development Lead starts by connecting to or switching to the Development branch.

Then, using the list of objects and the “Import Model” workflow, the Development Lead starts to import each model version from the feature branch into the current repository.

The developer will use 3D’s existing merge model function to ensure the right changes are kept and discarded. Once the issues have been resolved, they are committed to the Development branch.

Finally, the feature branch is closed.

WhereScape RED

By default, WhereScape RED’s metadata is held in a separate PostgreSQL database from WhereScape 3D.

GIT holds the master version of the WhereScape metadata. Therefore, to keep the Developer machine WhereScape repositories aligned, they are rebuilt from GIT after the metadata files are pulled directly from the remote GIT repository.

This ensures that both WhereScape applications are built to the same commit ID, ensuring the integrity of the data models & WhereScape application configuration across both applications.

Using WhereScape RED Workflows

Committing ALL to GIT

Currently users are only able to Commit *all* changes to GIT in WhereScape RED. This workflow will look at all objects and settings within WhereScape RED, and extract them from the command line before pushing them to GIT.

To do this the user can right-click the 'All Objects' folder, and selecting 'Commit_All_to_GIT' from the workflows.

Image Added

This workflow is used for the following reasons:

1. After making any changes to objects or settings within RED which need to be saved to the remote repository.

This workflow will perform the following tasks:

1. Verifies connection to GIT Repository.
2. Brings in the latest changes from the remote repository so your local setup is up to date.
3. Reviews recent changes made within the WhereScape RED repository.
4. Extracts the current configuration & stores them within the local GIT repository folder.
5. Adjusts files to make them reusable for different developers.
6. Creates a full backup of the repository (excluding the connection details).
7. Necessary files are zipped whilst temporary files are removed.
8. The user will be prompted to add their own commit message:
   Image Added
   
   1. If the user would like to link their commit to a backlog item or bug in GIT, they can use development tags in their commit message. Simply add a '#' followed by the backlog item ID. For example: '#123', will automatically associate the commit with the corresponding work item in your backlog.
9. Commits the changes to the remote GIT repository.

Committing to GIT

Currently users can only Commit *all* changes to GIT.

Committing Configuration Changes to GIT

Currently users can only Commit *all* changes to GIT.

Create Branch

This function is currently available within WhereScape 3D. See WhereScape 3D Create Branch.

Close Branch

This function is currently available within WhereScape 3D. See WhereScape 3D Close Branch.

Switch Branch

This function is currently available within WhereScape 3D. See WhereScape 3D Switch Branch.

Pull from GIT

This function is currently available within WhereScape 3D. See WhereScape 3D Pull from GIT.

Upgrades

When the MSI is required to be updated, two options can be considered:

Option 1

Use this for partially complete development activities or code not ready to merge to the parent branch.

1. Developer A is connected to a feature branch. Developer B is connected to the development branch.
2. Both developers should commit our changes back to the branch they are connected to, ensuring their changes are within the GIT repository.
3. The MSI is updated on all developer machines.
4. Each developer would either:
   1. Use the desktop shortcut to reconnect to the GIT repository and their branch, or
   2. Open WhereScape 3D and click the "Pull" workflow button.

Option 2

This option can be used if all development activities are complete. It is not recommended for partially completed development activities.

1. Developer A creates a feature branch for Developer B.
2. Developer B is connected to a feature branch.
3. Developer B completes development activities.
4. Developer A merges the feature branch into the development branch.
5. The MSI is updated on all developer machines.
6. Developer A would either:
   1. Use the desktop shortcut to reconnect to the GIT repository and development branch, or
   2. Open up WhereScape 3D and click on the "Pull" workflow button.
7. Developer A creates a feature branch for Developer B.
8. Development activities continue.

In either option, the files from the remote GIT repository are pulled to the local machine, which is then used to reconfigure the local environment and the PostgreSQL repository used by WhereScape RED and 3D.

Other Considerations

The following list are known issues:

WhereScape 3D

• Importing XML Model Version files that contain custom UI source connections. This results in
• Command line performance issues – memory leakage when running parallel tasks.
• RED Discovery & profiling connection is not compatible with the CICD/GIT functions at present. Users can create this separately, but it must be manually refreshed.
• Target Storage Locations are added to WhereScape RED via the Python Scripts, not the WhereScape command line.
• It is possible to create duplicate Data Type names. However, this will produce an error when the command line interacts with the Data Types (duplicated name).
• Templates: Templates with XML contents can result in an error when imported/exported using the command line.

WhereScape RED

• It is not possible to change the Script Launcher options and commit them to GIT. This is only possible as a change request as it is possible within the Python Scripts.
• Passwords can be stored within WST. It is recommended that any new repositories are set NOT to store passwords within WST. Within WhereScape RED, go to the Options to make these changes.
• WST File – If a table or view object contains a duplicate column name, it is possible to commit these changes to GIT; however, it will produce an error when deploying the WST file.
• If the initial build fails and the log file returns an error relating to the License Agreement, open WhereScape RED and agree to the license agreement when prompted.
• PostgreSQL command line
• Ensure that the command line applications, found in `C:\Program Files\WhereScape\RED\Tools` are kept in line with the version of the PostgreSQL database being used to host the WhereScape RED & 3D applications.
• It is not recommended to mix versions of PostgreSQL across WhereScape applications.

Python

• Changes to the Python version may change how the script operates.
• Python will execute PowerShell script to create/remove ODBC (DSN) for the WhereScape RED repository. This may require the user/Developer machine to grant permissions for unsigned PowerShell script to be executed.

GIT

• File size is limited to 50 MB. AS WST files can exceed this limit, the Python script compresses the WST files into a ZIP file (binary) before committing to GIT. Other files may exceed this limit in the future.
• Ensure that the GIT runner folder allows the account executiong the Python scripts with Full Control permissions. Failure to do this, may result in the WST deployment script from working correctly.
• Ensure that the default branch within the global gitconfig file (`C:\Program Files\Git\etc\gitconfig`) is set to the default branch within the Python config settings. This will avoid issues when cloning the remote GIT repository to the Developer machine. This must be completed with administration privileges.
  • For example:
    [init]
defaultBranch = main[safe]
directory = *