Lifecycle stages and actions

Lifecycle actions contribute to the initial deployment of a service, communicating with the service provider through a process engine such as HP Operations Orchestration. Lifecycle actions also provide other important functions, such as actions required to modify the service upon request or actions required to remove the service from deployment.

Every lifecycle comprises a stage and every stage has roles associated with it. It means that all users who belong to the roles in a particular lifecycle stage can perform operations defined in the role during that stage. For example, if the Development lifecycle stage has the Application Architect role associated with it, then users belonging to the Application Architect role can perform tasks associated with the role in the Development lifecycle stage.

The following are the out-of-the-box lifecycle stages available in Codar:

• Development: This is usually the first stage in which the code is developed and application artifacts are created.
• Testing: Stage in which test cases are executed against the code developed in the Development stage.
• Staging: Pre-production stage that replicates the production environment; used to test the code and artifacts.
• Production: This is usually the final stage in which the application is deployed in a live environment.

Apart from the out-of-the-box lifecycle stages, there are custom stages that you can create. For information about creating, editing, and deleting custom stages, see the Codar Online Help.

The following table lists the actions pertaining to a package that take place in each lifecycle stage:

Stage	Promote	Deploy, Redeploy	Edit	Delete	Reject
First stage (usually the Development stage)	Yes	Yes	Yes	Yes	Yes
Intermediate	Yes	Yes	Yes	Yes	Yes
Final stage (usually the Production stage)	No	Yes	Yes	Yes	Yes

You can access lifecycle stages by using the Release Automation > Pipeline Configurations sidebar menu item.

Use the following actions to deploy or move a package through the stages. These actions describe the flow when release gate actions are not defined.

• Promote: Moves the package to the next lifecycle stage. The package state remains Active.
• Deploy, Redeploy: Deploys the package. See Deploy a package.
• Edit: Changes the properties of a package. See Edit a package.
• Reject: Stops the package from advancing to another stage. The package will remain in its current stage, its state will be set to Rejected, and the action buttons will no longer be available.
• Delete: Deletes a package. The package will be removed permanently from the system.

• Refresh: Retrieves current package status.

Package states

Packages have the following states:

• Active: the package is active in the current lifecycle stage
• Rejected: the package has been rejected and will not move to the next lifecycle stage
• Transition: the package is in transition to the next lifecycle stage
• Failed: the promotion of the package has failed

If you reject a package, then it remains in its current stage, its state is set to Rejected, and no further actions can be applied; however, it can be deleted and is removed from the system.

When a package is promoted, it moves to the next stage and remains in the active state. Packages are always created in the first lifecycle stage. If the Codar Jenkins plug-in is configured, then after a successful build the Jenkins plug-in talks to Codar and creates a package.

Grouping service designs by lifecycle stage

A partial design with an active package requires you to select a service design to provision in the deploy package wizard. These service designs can be grouped for different lifecycle stages. This grouping enables package deployment in a lifecycle stage to list only those grouped service designs from that lifecycle stage.

To group the service designs for a lifecycle stage, create a tag with the name of the lifecycle stage in each topology design. When a lifecycle stage is created, a tag with the lifecycle stage is automatically created. Hence, only the designs need to associated with the right lifecycle stage tag. For example, you could create a Development tag and associate it with all required designs in the Development lifecycle state.

Note: The test run wizard in the Test tab lists all designs and does not group by tag.