Fetching latest changes Scenario 2 Module library and CI environment

In this scenario you have onboarded both the module library and the CI environment, as described in Getting started Scenario 2 - Onboard module library and CI environment and you would therefore need to fetch latest changes for both.

Depending on the DevOps environment you are using (GitHub or Azure DevOps) the number and implementation of the required steps may vary.

The update process is the following:

1. Backup your local copy of the library
2. Sync your copy of the library
3. Apply specific settings to files
4. (Optional) Convert library to ARM
5. Manual dependencies
6. (Optional) Customize modules and CI environment
7. Test and publish modules

1. Backup your local copy of the library

Rename your local repository. Assuming the local repository location is 'D:\ResourcesModules' rename it in 'D:\ResourcesModules_Backup'.

2. Sync your copy of the library

GitHub public repository

You have a public fork of public CARML source repository in your target organization.

1. Keep your fork synced to the fork upstream repository, on the GitHub web UI or through the GitHub CLI or the command-line, as explained in Syncing a fork documentation.
2. Sync your local copy of the fork taking care of eventual customizations you can have in place.

GitHub private repository

You have created your GitHub target repository and uploaded there the content of the CARML repository.

Clone/download CARML repository to create a local copy of it, as explained in Azure DevOps Repository section in Getting started - Scenario 2 Onboard module library and CI environment

Azure DevOps private git

You have created your target repository and uploaded there the content of the CARML repository.

Clone/download CARML repository to create a local copy of it, as explained in Azure DevOps Repository section in Getting started - Scenario 2 Onboard module library and CI environment

3. Apply specific settings to files

Personalize files with your specific settings:

1. Update default name prefix
2. Update settings file (settings.yml) as explained in Set up variables file

4. (Optional) Convert library to ARM

Follow instructions in (Optional) Convert library to ARM

5. Manual dependencies

In special cases, manual actions may be required to provision certain resources whose deployment is not covered by the module test files. Based on the modules you require to test, follow the Manual dependencies guidance.

6. (Optional) Customize modules and CI environment

The backup folder from step 1, can be used to compare your local copy with your synced copy coming from the latest version. For example, the 'Compare selected' function in Visual Studio Code can be leveraged for that purpose.

If your copy deviates from the upstream version due to customizations you applied to the code, you'll have to re-apply those customizations to the updated code. This process may be automated, by script or CI, if customization tasks are repeatable.

Note: If customizations are general improvements which may be useful for the public, the recommendation is to contribute to the public CARML repository so that your updates can improve the public library. This way, your changes will already be available the next time you fetch from upstream, as modules would already been tested, and would not conflict with your customizations.

7. Test and publish modules

Push the updated local code to your remote repository. If actions are enabled, test and publishing of modules will start automatically.