CDD - Multi Release of Same application shows missing token value for last_succesfull_change

Products

• Continuous Delivery Director SAAS

Issue/Introduction

We have created two releases A, B of same application having phases Dev, stg, prd with different release tokens. 

We have executed Release A and when we tried to execute Release B, we face an error of missing tokens values.
Please find the attached screenshots of both the releases in which one release getting the tokens and the other release is missing the tokens for the same application. Suggest for the steps to execute two releases of same application.

We have a release with three phases with FT -> STG -> PRD. We have executed version 1.0.0 in FT and STG, now we execute another version 1.0.1 in FT phase.If i want to execute the phase PRD with version 1.0.0, so what would be the value the "last_succesfull_change". Will it take the 1.0.1 version which is latest deployed in FT or the 1.0.1 latest deployed in STG as per the phase heirarchy.

Cause

Regarding the use case of having two release executions in CDD with different versions in parallel for the same application using FT STG and PRD environments.

Once a specific version of an application is deployed on a CDD environment, it is replacing the previous version of that application that was previously deployed. If a specific server machine is concurrently running 2 different versions of a specific application - you may associate 2 different CDD environments for this server machine ( FT1 and FT2 ).

Environment

Release : 7.1

Component : CONTINUOUS DELIVERY DIRECTOR

Resolution

 

 

A specific CDD environment is running only a single version of a specific application at any given time. It may run multiple versions of different applications.

 

Deployment Pipeline

 

• When running a build promotion CD pipeline - the build of a specific application version that was successfully deployed/tested on one environment is promoted to the next higher environment ( FT --> STG   or   STG --> PRD, etc... ).
• In order to promote a build of a specific application version - it should be successfully deployed/tested and available on the lower source environment.
• If this build/version is no longer present at the source lower environment - it cannot be promoted to the next higher environment.

 

Workaround:

 

Since in your use case,  the specific server machine is not running 2 different versions of a specific application concurrently  ( but sequentially ) - it is recommended to run the build promotion of this server machine in a pipeline mode.