Source control best practices

Setup guidelines

• •Use different organizations for development, testing, staging, and production.
When you maintain different organizations, you maintain isolation across environments so that changes in one environment do not affect other environments. For example, changes to assets in the testing environment are not accidentally deployed in the production environment.
• •Configure development organizations with read/write access to the source control repository, and configure non-development organizations with read-only access to the source control repository.
This ensures that only users in a development organization can make changes to assets. It also prevents users in a non-development environment from accidentally pushing changes to the source control repository.
• •Ensure that only one development organization uses a particular source control repository.
Maintaining separate repositories ensures that users in one organization do not accidentally change or overwrite assets in a different organization.
• •When you enable source control for the organization, select an empty repository.
Ensure that the repository does not contain a folder named "Explore" because Informatica Intelligent Cloud Services stores assets under the Explore folder in the Git repository.
• •Do not share source control credentials among multiple Informatica Intelligent Cloud Services users.
Separate credentials maintain security and make it easier to track which user made a particular change. Additionally, each user gets their own rate limit in GitHub.

Development guidelines

Guidelines for managing dependencies

Use the following guidelines to manage assets with dependencies:

• - Create connections and runtime environments before you pull assets from the repository.
When required connections and runtime environments exist in the target organization, you can run tasks immediately after you pull them from the repository.
• - Ensure that reusable assets such as mappings and components are present in the repository before you use them.
Informatica Intelligent Cloud Services does not allow you to save an asset such as a mapping task when the dependent mapping does not exist in the organization.
• - Avoid moving or renaming source-controlled assets that are used by other assets.
If you move or rename a source-controlled asset, references to the asset can break.

Guidelines for checking in and checking out assets

Use the following guidelines when you check in and check out assets:

• - Identify all dependencies before you check out reusable assets such as mappings, mapplets, and user-defined functions.
Source control operations such as check out, check in, and pull do not automatically include dependent assets.
• - When you need to update a reusable asset such as a mapping or component, check out the asset and all dependent assets.
For example, when you need to update a mapping, check out the mapping and all mapping tasks that use it to ensure that changes to the mapping are propagated to the mapping tasks.
• - Check in a reusable asset and all dependent assets in one operation.
This ensures that changes to the asset and dependent assets are committed to the source control repository at the same time. It also ensures that users get the latest versions of the dependent assets when they pull the assets.
• - Enter comments when you check in assets.
When you check in assets, you might enter a release tag name in the Summary field and enter more descriptive comments in the Description field. When you do this, the Git Summary field in Informatica Intelligent Cloud Services shows the release tag that is associated with the asset.
• - When you check in multiple assets at one time, limit the number of assets to 1000 or fewer.
Checking in more than 1000 assets at one time can degrade performance between Informatica Intelligent Cloud Services and the GitHub repository service.