Improve this page

Introduction

An important part of the CloudBoost library is the knowledge what is in the templates, this knowledge evolves, the same as the capabilities of the underlying Cloud providers. To make sure the templates are always up to date and executable to create the needed Cloud infrastructure the CloudBoost Guardians are continuous validating and updating them. Not only the Cloud templates but also the scripts, pipelines and guidance.

The Cloud CloudBoost library supports different ways to provide these updates to teams who are using the templates in the library in a controlled way. THe different methods bring also different levels of supported customizations by teams.

Connect the CloudBoost GIT Repository

It often happens that while working on one project, you need to use another project from within it. Perhaps it’s a library that a third party developed or that you’re developing separately and using in multiple parent projects. A common issue arises in these scenarios: you want to be able to treat the two projects as separate yet still be able to use one from within the other.

Git Submodule

Git addresses this issue via SubModules. SubModules allow you to keep a Git repository as a subdirectory of another Git repository. This lets you clone another repository into your project and keep your commits separate.

Teams working in a connected way with the CloudBoost library are using the templates, scripts and pipelines as is. A connected team will get access to the CloudBoost Library via a GIT SubModule. This gives teams full access to the library and updates of the library.

Team Branch or Master Branch

The team can choose if they want to work and synchronize with the master branch or if they want to have their own branch in the CloudBoost GIT repository.

Having a own branch gives the team the freedom to add and change templates without having to wait on the review board of the CloudBoost library team. Changes from one or the other can be accepted via Pull Requests. The specific team branch will be protected and only a Sogeti team member can have access.

Working with the CloudBoost library from the master branch will give the team the control to pull direct the latest versions.

Setup a CloudBoost GIT Submodule connection

References: https://git-scm.com/book/en/v2/Git-Tools-Submodules

High-level steps:

  1. Create a GIT repository for the business project.
  2. Decide if the team wants to do customizations.
  3. When customizations are needed ask for a Branch in the CloudBoost repository.
  4. Add the CloudBoost Git Repo to your Git Repo.

Create a GIT repository

Clone your Git repository local. ‘GIT clone '

Create a Branch (or not, see above) in the CloudBoost repository and set proper security and policies

Goto CloudBoost.VisualStudio.com/CloudBoost.ServiceCatalog/_git and Clone the git repository to create a branch. ‘GIT clone https://dev.azure.com/cloudboost/CloudBoost.ServiceCatalog/_git/CloudBoost.ServiceCatalog’

When you want to do customizations you need to create a branch in the CloudBoost Repo first. Create a Branch. ‘GIT branch “Customer or Project name”’

Push the Branch ‘GIT Push remote ….’

Set the security, or ask the CloudBoost Guardians of the new branch. Create a team with the customer or project name in cloudboost.visualstudio.com/ and add the Sogeti project members. Assign this group to specific branch as contributes.

The GIT SubModule command

To add a Git SubModule you use the ‘GIT SubModule add’ command with the absolute or relative URL of the project you would like to start tracking.

First go to the root of your project and execute the git SubModule add command.

When working from a CloudBoost branch add the ‘-branch “branch name” to the command.

$ git SubModule add https://dev.azure.com/cloudboost/CloudBoost.ServiceCatalog/_git/CloudBoost.ServiceCatalog
Cloning into 'CloudBoost.ServiceCatalog'...
remote: Counting objects: 11, done.
remote: Compressing objects: 100% (10/10), done.
remote: Total 11 (delta 0), reused 11 (delta 0)
Unpacking objects: 100% (11/11), done.
Checking connectivity... done.

By default, SubModule will add the Sub project into a directory named the same as the repository, in this case CloudBoost.ServiceCatalog. You can add a different path at the end of the command if you want it to go elsewhere. If you run Git status at this point, you’ll notice a few things.

         $ git status
         On branch master
         Your branch is up-to-date with 'origin/master'.

         Changes to be committed:
         (use "git reset HEAD <file>..." to Un stage)

	     new file:   Git module
	     new file:   CloudBoost.ServiceCatalog

First you should notice the new Git module file. This is a configuration file that stores the mapping between the project’s URL and the local subdirectory you’ve pulled it into:

        [SubModule "CloudBoost.ServiceCatalog"]
	     path = CloudBoost.ServiceCatalog
	     url = https://dev.azure.com/cloudboost/CloudBoost.ServiceCatalog/_git/CloudBoost.ServiceCatalog

Create a Build CI

A Git Submodule is not automatically cloned on a new environment.

The CloudBoost.ServiceCatalog directory is there, but empty. You must run two commands: git submodule init to initialize your local configuration file, and git submodule update to fetch all the data.

On your development environment the Git Submodule connection is using your Git Credentials and you must have access to get the data from the CloudBoost repo.

When configured and running a build, that build agent doesn’t have credentials to access the Cloudboost Repo. A Sogeti team member needs to make a Personal Access Token in the cloudboost.visualstudio.com account and give it read rights on the Git repository. This access token is used to execute the command on the build server.

To get the correct value for the secret, first add a user to the token, ‘user:pat’ and BASE64 encode this keyvalue pair.

See this Microsoft documentation for more details, authenticate sub modules.

Add this command, with your onw Base64 encoded PAT as an additional step in your build to get the latest templates from the CloudBoost library:

git -c http.https://dev.azure.com/cloudboost/CloudBoost.ServiceCatalog/_git/CloudBoost.ServiceCatalog.extraheader="AUTHORIZATION: basic QWNjZWxsOjZyNTU3dW9jeXVlZ3M3cWo2YjNxbDd3Mzc3cGRmeXM2amI2YmRrYnVkdG5kZm51c3B4amE=" submodule update --init --recursive

To clone the repo with the same authentication settings can be done via the command: git -c http.extraheader="AUTHORIZATION: Basic QWNjZWxsOjZyNTU3dW9jeXVlZ3M3cWo2YjNxbDd3Mzc3cGRmeXM2amI2YmRrYnVkdG5kZm51c3B4amE=" clone https://dev.azure.com/cloudboost/CloudBoost.ServiceCatalog/_git/CloudBoost.ServiceCatalog

This will get the latest items from the library, you can add an additional build step to get the template you need for provisioning the you Cloud infrastructure. See ARM to Drop folder build step.

Work with the CloudBoost library

A Git submodule behaves as a normal Git repository, changes needs to be pulled before you can see them and this pull (the hash changes from the submodule) needs to be committed to the local Git project to tell which version needs to be pulled.

Only when there is a change in the CloudBoost library these steps needs to be done.

  1. Go to the root of you project.
  2. Make topic branch (default practice when you are making a change).
  3. Go to the CloudBoost directory ‘cd CloudBoost.ServiceCatalog’.
  4. Check the branch with Git Status, you will see it mentions the CloudBoost.ServiceCatalog branch.
  5. Check if on the right branch, the specific project branch or master.
  6. Pull the latest version of the CloudBoost.ServiceCatalog.
  7. Go back to the root of you project ‘cd ..’.
  8. See the changes ‘Git Status’, you will recognize the hash of the CloudBoost.ServiceCatalog is the only change.
  9. Commit this change and make a pull request.

Disconnected

Package manager

Disconnected teams get the artifacts from the Cloud Boost Library via the Universal Package manager in the CloudBoost DevOps account.

Either templates are taken via the CLI or via a Release step in Azure Pipelines. THe release step requires a service connection with the CloudBoost DevOps account which only can be made when you have access to this account.

Your Own Library

When a team want specific customization which impact all templates, for example a different naming convention. There are two ways this can be accomplish. The CloudBoost team make a specific Azure repo with the customized templates and makes these via the above mentioned ways available. THis can also be done in an other Azure DevOps account or even in a different Git tool.

The other way is to set up a complete new library, based on the original templates and adjusted to the customer Cloud reference architecture, and run it for a customer. You can imaging this is a time consuming activity which requires a lot of work at the customer site. Setting up the customers Cloud Reference Architecture can fiy in this as additional work.

Please contact the CloudBoost team via SogetiGitHubAdmins@capgemini.onmicrosoft.com when you have any doubts or technical challenges.