Dependencies

Use relationships to manage dependencies. Many assets have dependencies, or requirements that are beyond the asset itself in order to be complete, to work, or to build. For example a Build or an Implementation asset type might have dependencies that are required for the asset to be complete or valid. Assets may require certain binary and jar files that are dependencies for the build or implementation.

Managing dependencies includes both defining the dependencies and then governing them by using policies. You must first identify what dependencies are part of your assets, then define them and then apply policies.

You can manage dependencies by creating related assets and by using dependency relationships. You can also define dependencies by creating assets or related assets based on sets of components to manage requirements for dependencies and traceability.

These guidelines are the general steps to manage dependencies:
  1. Identify dependencies
    1. Specify how the assets are used and found, and what assets are used for, by defining and categorizing the asset types. See Category schemas.
    2. Determine the dependencies for your asset types.

      Review dependencies and decide who controls them. Review existing dependency relationships for libraries and required common files that teams use. Validate that files for given versions are accurate and that the correct version information is specified for dependencies. Review existing relationships between teams and components. Identify conflicts where multiple projects might be using different versions of the same components. Avoid conflicts by controlling official versions of dependencies and enabling updates to a workspace that contains those versions. Also, distinguish between the dependencies in your development and production environments. See Asset review and governance.

  2. Define dependencies
    1. Determine and define the required files and dependencies to be bundled in assets. Include versions and other information that may change over time. For example, you might specify, “Version A goes with Version C and is used in products 1, 2, and 3, for platforms A, B, and C.”
    2. Save the dependencies as artifacts in the asset or as related assets.

      Use relationships between required files or components. A dependency can define how an asset version depends on another version of another asset. For example, a dependency might state, “Use version, 1.4.2 vs. 1.4.1 of common component A” or “Use the latest approved and tested version or latest build” . Specify an approved version of each required common library or component so that multiple versions are not used. See Asset relationships.

      You can use a "Depends on" relationship to specify a dependency. See Defining relationships between assets.

  3. Govern dependencies
    Apply policies to govern dependencies by following these steps:
    1. Define the processes and policies for creating assets, artifacts, and new versions of assets and artifacts. See Policies for lifecycles in Rational Asset Manager.
    2. Define the asset lifecycles for reviewing, approving, certifying, publishing, and retiring assets.
      Define the governance for these roles and resources:
      • Who can add new libraries as assets
      • What security scans are needed
      • Who can create draft versions and approved versions
      • Who checks license compliance for commercial and open source components
      • What policies are used to remove older versions
      See Asset development and lifecycles.
    3. Apply policies to govern how new assets, artifacts, or versions are made available. See Defining policy processes.

For a demonstration of how to use Rational Asset Manager to manage dependencies and build a service, see Developing Services with Rational Asset Manager .

Stakeholders in a development or business environment have information that can be centralized in an asset management system. Architects suggest components that can be used globally. Developers know all the project dependencies. Change management teams set policies for what is allowed. Quality engineers know what has been tested. Operations personnel know what is approved for production use.

You can use IBM Rational Asset Manager to manage the information of all stakeholders and create assets and relationships for dependencies. You can use relationships in several ways, including the following examples:
  • Make components available as assets.

    Develop tested sets of common components that are used together in your organization. Create assets based on these sets. Create one asset of common components for each application type or operating system.

    Test versions of those sets and create an asset as a version of the group of components. If you build your application on this group, it should work in your environment.

  • Use asset relationships to specify dependencies.
  • Use asset lifecycles and apply policies to govern what is allowed and what is tested and approved.

    You can also generate reports to audit asset reuse, including dependencies.

Consider using aspects of ownership to determine whether to create assets or artifacts. For example, if an Implementation asset depends on open source components or other required components or resources, you can manage dependencies in the following ways:
  • If you or your organization controls the source content, you can create related assets. For example, you can create a required component or type library or collection of libraries for developers to use.
  • If you bundle a set of versions of resources and maintain this set for reuse, you can create related assets. For example, you can create a collection of open source components and libraries for developers to use.
  • To manage specific required files, libraries, and other dependencies that your organization does not own or maintain, you can create artifacts. For example, you can create an open source component or type library.