5This is the fifth article from a series covering the use of vRSLCM with source control.  Links to the other articles in the series can be found at the bottom of the page.

In part 4 of this series I covered capturing and testing content with vRLSCM as well as placing that content under source control using Gitlab integration with vRSLCM.  In this article I am going to continue with the two user scenario that I started previously and examine how the introduction of the second user impacts everything.

 

1.  User 2 – Process Flow

User 2 is going to execute the following steps to simulate multiple people utilising shared content within their services.

• User 2 develops new content utilising configuration used in user 1s’ blueprint
• User 2 updates some of the shared content to make it work for them
• User 2 captures their content and tests it
• User 2 places their content under source control

 

2.  User 2 – Blueprint Content

The blueprint I am using to represent user 2s’ work is a copy of user 1s’ blueprint (see part 4 of this series).  Everything within the blueprint is the same however I have made a small amendment to the vRO action that powers one of the dropdown lists on the request form.  I have also incremented the version number of the action.

 

3.  User 2 – Capturing New Content

As this is a new blueprint I am going to capture it into vRSLCM in exactly the same way as we did for user 1.  The vRO action has been updated so the dependencies will also be included (note you could capture the one vRO action separately however if your developed service is working correctly then you would normally want to capture all the components to ensure the service will work in the same way wherever it is tested/deployed).

Once the capure into vRSLCM has been completed (and in this case tested as well) the first version should be listed as follows.

 

4.  User 2 – Placing Content Under Source Control

The new service and updated code is ready to be placed under source control (i.e. added to the Gitlab respository).  This is done in the same way as user 1s’ content, using the “Check In” option on the appropriate version in vRSLCM.

The master branch in Gitlab remains un-changed however there are now 2 new branches within the repository.  Each branch contains a copy of the master branch contents as a basis plus the updates of a specific content type.

The first of the additional branches contains all of the master branch content plus new orchestrator content (we’ll dig into this shortly).

The second additional branch also contains a copy of the master branch plus user 2’s composite blueprint.

Each new branch has also generated a merge request which the Gitlab maintainer would need to accept or deny.

The acceptance of the merge request is exactly the same as was for user 1.

Once the merges have been completed the repository is left with a single master branch which now represents the new baseline for the code repository.

Browsing within the “Orchestrator-Package” folder of the master branch shows 2 vRO package folders.  Although the same action was used for both user 1 and 2s’ blueprint the vRO packages were named differently as part of the capture process (the package names were left blank and therefore automatically named after each respective blueprint).  Rather than an updated common action with user 2s’ content, we now have 2 copies.

If a common package name had been used for both captures then the vRO action content would be represented as a single folder and single action within Gitlab with the action being the version which user 2 amended.

As the 2 blueprints have different IDs’ they are treated as individual items within the Gitlab repository as shown below.  However, once captured from Gitlab and deployed to an endpoint, whichever one was deployed last would overwite the previous version.  This is because within vRO they would have the same object ID’s, module names and paths.

User 2s’ source controlled composite blueprint and its dependencies can now be captured out of Gitlab, back into vRSLCM using the same method as we did for User 1s’ content.  This will add the Gitlab commit hash values to all the new component versions within vRSLCM for traceability.

 

5.  Gitlab Version History

One of the powerful features of Gitlab is the ability for all changes to the master branch to be tracked, controlled and reverted (if required).  Alongside this, differential analysis enables a user to compare code changes across commits.

In this example, User 2s’ composite blueprint yaml file can be seen.  Everything with a “+” symbol has been added by the commit action.  The “Revert” option can be used to generate new merge requests to roll-back individual commits if required.

In the following example I have updated a property definition used by a blueprint, re-captured the blueprint and dependencies and performed a “CheckIn” to Gitlab.  Looking at the history of the property definition from the last commit I can see what was added and what was taken away.  In this case the version number and timestamp from the previous version were removed (left window) and a new timestamp, updated version number and new dropdown options added (right window).

6.  Other Articles in this Series

• Part 1 – Installing Gitlab
• Part 2 – Configuring Gitlab
• Part 3 – Linking vRSLCM to Gitlab
• Part 4 – Capture, Testing & Source Control