Best approach for a 1 repo - multi team members about enterprise-azure-policy-as-code HOT 7 CLOSED

There are a few different ways to handle this, skip to the last line if you prefer:
Slightly different "test" pipeline files used by people that they maintain. These use different service connections, with different scoped rights, so as to prevent bumping into one-another. Each dev would have their own EPAC-Dev hierarchy for testing in that scenario. This requires that they maintain their own pipeline, as well as connection settings.

Pointing to different tenants of course, but that doesn't seem like a good fit in your (or most) situation.

However, I do have a question: The development area is intended to be volatile, and have no subscription contents to evaluate. Based on that, we are really only interested in confirming that the policies deployed properly.

I think that the best solution would be to add a step to your pipeline that will export the current assignments for that epac-dev scope to a json artifact for review by the person that ran the pipeline. That way you get the snapshot at the end of that run before the next run starts. This does assume you don't let multiple people run that pipeline simultaneously, which should be a fairly safe assumption as it's not going to do you many favors in that setup. It'll run faster, but add so much more confusion that it's not adding value.

from enterprise-azure-policy-as-code.

from enterprise-azure-policy-as-code.

Excellent point @brianmooremsft , you don't necessarily have to test the full scope deployment at that point if that isn't the goal of your test. Using a smaller scope for validation testing is a good idea too. You don't necessarily have to use the EPAC-Dev MG hierarchy for some tests.

from enterprise-azure-policy-as-code.

@rowbot-99 please let us know your thoughts. Thank you!

from enterprise-azure-policy-as-code.

Thank you both; your help is greatly appreciated.

To clarify, are you suggesting that deploying each branch to a different scope will resolve the issue? Or shall i combine that with pipeline restrictions?

My understanding was that with the strategy set to "full," any policy deployed with the pacownerid set wouldn't be deleted regardless if the policy code is present in the branch or not.

from enterprise-azure-policy-as-code.

Some more thoughts on how to test this:

• Set up sandbox subscriptions for developers to test policy with
• Each developer has an EPAC folder with global-settings.jsonc pointing to their own sub - and a unique PAC Id.
• Set desired state to OwnedOnly - so that when they push they only affect their own area
• When development is complete move the policy definitions into the main folder
• Separate pipelines for devs - or give them owner permissions on their subscription so they can test locally (quicker)

from enterprise-azure-policy-as-code.

Thank you for the suggestion, having multiple subscriptions for the devs is not the ideal scenario unfortunately. I will try out both options and see which one is best suited. Thanks

from enterprise-azure-policy-as-code.