Cloud Manager: Add optional approval step before deploying to a Dev or Stage environment

Avatar

Avatar
Boost 1
Level 1
robertr19819541
Level 1

Like

1 like

Total Posts

2 posts

Correct reply

0 solutions
Top badges earned
Boost 1
Shape 1
View profile

Avatar
Boost 1
Level 1
robertr19819541
Level 1

Like

1 like

Total Posts

2 posts

Correct reply

0 solutions
Top badges earned
Boost 1
Shape 1
View profile
robertr19819541
Level 1

05-07-2021

Request for Feature Enhancement (RFE) Summary: Add (optional) approval step (or something similar) before deploying to a Dev or Stage environment
Use-case: The environments are used by a different company to test the software and therefore requires alignment of the deployment maintenance. As the build time could vary a lot, this maintenance window needs to be quite large. (With this option the 15 minutes of the deployment step + 10 minutes smoke test as maintenance window would already be sufficient as the pipeline and its long running build and unit testing steps could be started much earlier.)
Current/Experienced Behavior: After "Code Scanning" step the pipeline will immediately start deploying the new software package.
Improved/Expected Behavior: Option to pause the pipeline before executing the deployment step. This option should be available for non-production as well as production pipelines.
Environment Details (AEM version/service pack, any other specifics if applicable): not applicable
Customer-name/Organization name: Volkswagen
Screenshot (if applicable):  
Code package (if applicable):  
3 Comments

Avatar

Avatar
Employee
clatimier
Employee

Likes

0 likes

Total Posts

0 posts

Correct reply

0 solutions
View profile

Avatar
Employee
clatimier
Employee

Likes

0 likes

Total Posts

0 posts

Correct reply

0 solutions
View profile
clatimier
Employee

21-07-2021

Hello @robertr19819541 

Thanks for your idea

This request has been raised to the product team via the Jira CMGR-19166. The product team will triage this request to verify feasibility based on the prioritization model. This post will be updated according to the Jira request status.

Status changed to: Investigating

Avatar

Avatar
Boost 1
Employee
justin_at_adobe2
Employee

Likes

2 likes

Total Posts

2 posts

Correct reply

1 solution
Top badges earned
Boost 1
Affirm 1
View profile

Avatar
Boost 1
Employee
justin_at_adobe2
Employee

Likes

2 likes

Total Posts

2 posts

Correct reply

1 solution
Top badges earned
Boost 1
Affirm 1
View profile
justin_at_adobe2
Employee

22-07-2021

@robertr19819541 could you explain a bit more the relationship with the aligned deployments?

Avatar

Avatar
Boost 1
Level 1
robertr19819541
Level 1

Like

1 like

Total Posts

2 posts

Correct reply

0 solutions
Top badges earned
Boost 1
Shape 1
View profile

Avatar
Boost 1
Level 1
robertr19819541
Level 1

Like

1 like

Total Posts

2 posts

Correct reply

0 solutions
Top badges earned
Boost 1
Shape 1
View profile
robertr19819541
Level 1

22-07-2021

In our current process we are developing in sprints and deploying daily to an AMS environment where our QA is testing. At the end of the sprint we are deploying to a different AMS environment which is used by an external company to test the new release. Some days before the production deployment we are also deploying to an additional environment that is used for integration testing. This environment is also used by the external QA company, but mostly by outside people to test various integrations.

Deployment to these two environments must be coordinated and aligned with all the external users. Since the execution times of the Cloud Manager pipelines vary greatly, especially recently, a fairly large maintenance window must be used. However, a large maintenance window is problematic to coordinate with so many stakeholders. It also starts to impact the amount of tests that can be run on the environments.
Therefore, an approval step before the actual deployment to the dev or stage environment would be very helpful. You could then start the pipeline in the morning, for example, and the deployment would be ready at the agreed time. The maintenance window could then be relatively fixed and small, and it would also no longer be so tragic if something is restarted within the pipeline and the execution time increases.
In principle, the manual approval step for code quality issues already offers something like this, but we do not want to commit major code issues in the software release as a workaround only.