Lifecycle stages and actions

Every lifecycle should comprises several stages 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 as per the assigned permissions.

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 Create a lifecycle stage and Edit or delete a lifecycle stage.

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: Change 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: Delete a package. The package will be removed permanently from the system. A package can only be deleted if all associated deployed instances are canceled and deleted.
• Refresh: Retrieves current package status.

Package states

Packages have the following states:

• Active
• Rejected
• Transitioned
• 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 will be 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 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 a selection of a service design for provisioning in the deploy package wizard. These service designs can be grouped for different lifecycle stages so that the package deployment in the lifecycle stage lists only those grouped service designs from the respective 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. For example, you can create a Development tag and associate it with all required designs in the Development lifecycle stage.