Developing multiple feature branches in parallel

[kevball2]

Hi All,
Looking for suggestions of allowing multiple team members to develop policies in different features at the same time.

with the process right now to 2 different features would overwrite each other using the same PAC selector for testing. Some ideas I had

• Different MG and Subscription for the feature branch
• Same MG and Subscription with a different Resource group for each feature branch

I am leaning towards the different resource groups per feature branch to minimize the number of MGs and subscriptions that would need to be created.

• Team members would add a PAC selector for their resource group based on the feature name
• The pipeline would deploy the Dev jobs to their PAC selector.
• The PAC selector would be removed during the PR to the production branch.

Any feedback or suggestions would be appreciated!

[techlake]

1. Let's first address the MGs: Under a common epac-dev root, you should create a "root equivalence" MG for each developer. This will be surfaced in global-settings.jsonc as separate epac environments. Resource groups only work for Assignments. At least you need a subscription per developer to hold the definitions (Azure cannot create definitions at RG)
2. Create a feature branch standard as "feature/initials-of-developer
3. Depending on your CI/CD tooling, create a separate stage for each developer triggered on the above feature branch naming which deploys Policies to the corresponding epac environment.

Notes:

• You will have a small developer group
• No need to add/remove the PAC selector

[kevball2]

Thanks for the feedback!
Hadn't even thought of the definition requirements yet, thanks for the reminder. Some questions based on your suggestions:

• Would there be any benefit to adding steps to create and destroy the MG and subscription once the feature branch is completed?
• Am I overthinking the process, would it be better to have the development testing done via the portal then confirm deployment from the pipeline? (I would prefer all the development to be done in a feature branch)

[techlake]

• No benefit on creating/destroying the MG/subscriptions/rgs. They cost nothing
• Yes :-); however, using EPAC is a better approach instead of Portal. I always use EPAC for my development work.
• Yes, all development/testing should be in a feature branch