SCM Getting Started
Prerequisite Steps for all BMC AMI DevX Code Pipeline Scripts
Instructions
Select Code Pipeline from the BMC menu.
Click on the Repository Explorer view.
- Click on the "Containers" view.
- Click "Refresh" icon
If you get the dialog "There is no HCI configured for Code Pipeline. Would you like to configure it now?", click "Yes"
This will bring up the "Preferences" dialog for Code Pipeline Connections. Click "Appy and Close"
If it is open, close the Outline tab.
Code Pipeline Terminology
During this Test Drive, you will encounter terms specific to Code Pipeline. Here is a glossary for your convenience.
Term | Description |
Application | Business Area |
Sub-Application | An extension of the Application that enables the management of different versions or releases of the Application or different subsections of an application. |
Stream | Development Life-Cycle used by one or more Applications |
Life-Cycle | Transitional Code States (DEV, QA, PROD) in the Development Life-Cycle |
Level | Instance of a Code State (DEV, QA, PROD) |
Component | SCM managed object such as a Cobol source member |
Component Version | An immutable version of a Component |
Task | An instance of a unit of work. For example, a change to a Component. |
Part | A generated object such as a load module, or a Listing or a DBRM |
Warehouse | Storage location for inactive historical or overlaid Component Versions (source and parts) |
Assignment Container | A package of one or more, usually related, Tasks. A development container that is used to organize and manage development work. |
Release Container | A package of Tasks from one or more Assignment Containers. An operational container that is used to organize and manage operational releases. |
Set Container | A package of Tasks at an instance in time. A special Code Pipeline container that is used internally to organize and manage work requests. |
Sandbox | A location where an isolated set of versions can be utilized for development. |
Codeline Path | Dynamically defined at non-production levels, it has its own separate datasets at each life cycle level (see Sandbox). |
Add Task | Make a statement of intent, often because of some impact analysis |
Checkout Task | Copy source to development area |
Edit Task | Make a change to the source in the development area |
Generate Task | Execute Compile and Link processes |
Promote Task | Move Task forward to the next Level in the Life-Cycle |
Regress Task | Move Task backwards to the previous Level in the Life-Cycle |
Delete Task | Remove a Task from the development area |
Fallback Task | Restore previous version of Task |
Deploy Task | Implement Task in one or more Run Time environments |