Deployment pipeline more agile between dev and test, and approval between test and prod?

[Mikael Karlsson]

Hi, just started with AES and AEMC and some questions have come up.

How could we configure Deployment Pipeline / AEMC to allow our developers to publish between Dev and Test without any approval? This could happen multiple times before finally deciding to deploy to production, i can't see that they have the option to choose if they intend the submission for test or prod.

Consider something like this which must be common:

1. Submit app in Dev
   1. Approval is created for deployment Dev-Test
      1. Approved, app installed into Test, approval task automatically created for Test-Prod
   2. Developer finds bug in Test which needs fixing in Dev (but the production deployment request is still pending and will be pushed to Prod if approved, how can the developer prevent this)

[Mikael Karlsson]

Thanks again, we are running AEMC but i can't seem to figure out how the developer from Dev while pressing Submit can express the intention of stopping at Test. I've read through all i could find on NowCreate and the product documentation pages but i'm not able to find such specific example.

By the way, fantastic video series you shared, we'll definitely share those when creating awareness of App Engine and our new pipeline setup.

[WORKFLOW-COWBOY]

The order of Environments in the Pipeline configuration should determine which environment is next. 

@Mikael Karlsson are you saying that after clicking Submit in Dev AES that the Deployment Request is created with an approval to deploy to Prod and skips over Test? 

Your Pipeline configuration should look sort of like this:

[Mikael Karlsson]

Hi @WORKFLOW-COWBOY .

What our developers are expecting is that they can freely deploy between Dev and Test multiple times until they or their testers are satisfied. And once that point is reached they decide to submit for deployment to production.

Currently since our pipeline looks as your example, dev-test-prod, each submission has the intention of going all the way to prod. There is no good way for the app engine admins approving to know if an app should be halted after test or not.

I was expecting perhaps two buttons within AES, or the ability to pick a pipeline at submission. Then we could have one called dev-test (no approval), and one called dev-test-prod (with prod approval and change request)

The risk now is that a developer submits from dev and finds an issue in test, but the admin still approves causing the app to go to prod anyway? Or how does other customers prevent that while keeping the agility and minimum overhead?

[WORKFLOW-COWBOY]

Hi @Mikael Karlsson, 

Solution #1 - Add Developers to the App Engine Admin Group in Prod

Would it be possible to add your developers to the App Engine Admin group in Prod? Since you are deploying Change Management for Prod deployments maybe that is enough separation of duties for your environment? This solution would allow you to keep the AEMC audit data of the failed deployments. 

Solution #2 - Allow Developers to Publish and Install with the App Repo in Subprod environments

If the developers already have the 'admin' role in any Subprod environment, then they can go to the old green Studio and manually publish the app to the App Repo. Then, go to any other Subprod environment and install the app.

If they do not already have 'admin' in Subprod (which really should be best practice, but that's another article/post), then you can grant them the role [sn_g_app_creator.app_creator] to do this. 

Since Developers should not have either the roles [admin] or [sn_g_app_creator.app_creator] in Prod, then they can't go manually install/upgrade apps in Prod. 

I have 10 minute YouTube video on this specific solution. The video is from Tokyo, but not much has changed regarding the old green Studio and App Repo since that time. 

https://youtu.be/AIbnDUtFkuA?si=sMIEwb0opgmZetiA

Another more complicated solution would be to either modify the OOB Pipeline Flows or copy and disable them. Not impossible, but I would try to consider the first two solutions first as they require less change on the instances. 

--------------------------------------------------
If my response proves useful, please indicate its helpfulness by selecting "Accept as Solution" and " Helpful." This action benefits both the community and me. Thanks!

[Mikael Karlsson]

Thanks @WORKFLOW-COWBOY , appreciate your input and in depth responses.
We are quite far ahead on citizen development with limited privileges and the last piece of the puzzle to get the developers off the core team's back we assumed to be AEMC and pipelines.

Our development teams and more advanced citizen devs work in dev, in their own scopes or in customization scopes and we most often use the delegated development approach in studio and almost none are admins. When they are done they publish their apps which we then have to install in test and subsequently production since we don't want them as admins in either of those environments. We want to make them even more self sufficient with automated guardrails and smooth production deployments if all looks ok.

I'm almost starting to think about a solution where we would require our developers to provide a certain phrase in the release notes, like [PROD INTENTION] or similar:

1. Developer submits
2. Approval for test is created
3. Our automated flow approves for Test automatically
4. Approval for prod is created
5. Our automated flow looks at the release notes to see if the prod intention tag is there
   1. If tag is not found: reject
   2. If tag is found, carry on with further automated sanity checks like app manifest, ATF and scan results from Test installation, automatically reject if violations are found, send for AE Admins approval if all looks ok.