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:
- Identify dependencies
- Specify how the assets are used and found, and what assets are
used for, by defining and categorizing the asset types. See Category schemas.
- 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.
- Define dependencies
- 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.”
- 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.
- Govern dependencies
Apply policies to govern dependencies by
following these steps:
- Define the processes and policies for
creating assets, artifacts,
and new versions of assets and artifacts. See Policies for lifecycles in Rational Asset Manager.
- 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.
- 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.