To ensure that your organization configures and uses source control effectively, use the following guidelines as best practices.
Setup guidelines
Adhere to the following guidelines when you set up source control for your organization:
•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 pushes to a particular source control repository.
Maintaining separate repositories for development organizations ensures that users in one organization do not accidentally change or overwrite assets in a different organization. Maintaining separate repositories also avoids conflicting asset ID references from different organizations.
•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
Adhere to the following guidelines as you develop and work with assets:
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.
Guidelines for checking in and checking out assets
Use the following guidelines when you check in and check out assets:
- When you rename or move an asset, check out the asset's first-level dependent assets and include them in the same check-in.
For example, if you want to rename a mapping that a mapping task uses, and the mapping task is used in a taskflow, check out the mapping and the mapping task. You don't need to check out the taskflow. After you rename the mapping, check in the mapping and the mapping task in one check-in action.
- 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 Git repository service.