Closed BenjaminEngeset closed 1 year ago
Hey @bengeset96,
Thanks for raising this 👍
For the ALZ-Bicep project we are certainly considering PSRule as some additional tests on top of what we already do today, its on our backlog internally.
For clarity however I want to share that we lint, build and test deploy all changes via various pipelines today and these are enforced via branch policies on the repo.
Thanks again for raising this and looking forward to your replies 👍
Jack
@jtracey93
I do believe that each organization should of course have their additional CI/CT/CD strategy, but finding not optimal/un-enterprise configuration is nice to catch early in the coding loop.
When using heavy-hitter orchestration ALZ module (have to split it up because of the ARM limitation) I have to do some "minor" adjustments I would like to see preconfigured.
Simple example from running some of the ALZ NW modules with baseconfig provided.
I would feel more confident in ALZ if it was based/taken in consideration on predefined rules that are being updated continuously to make sure that the repo is in sync with WAF pillars etc.
Could some sort of PR from my side be interesting around implementing PSRule workflow and workflow dep for the files & modules where you and your team will triage and feedback/tweak it? PR might have to target some sort of feature branch based on main so modules can be adjusted accordingly by you and your team. Then new PR to main 😊
Thanks @bengeset96, I'll be chatting with the PSRule team today internally and will report back here 👍
Please rest assured we also perform deployment E2E testing as well on changes to modules to test a deployment on all PRs that amend .bicep files. But these are run in Azure DevOps due to secret/credential protection measures. The pipeline can be seen here: https://github.com/Azure/ALZ-Bicep/blob/main/tests/pipelines/bicep-build-to-validate.yml
On the PSRule front we'd also need a way to exclude/mute certain rules and provide info as to why, due to keeping parity across all ALZ implementations (Portal, Bicep, Terraform) we cannot just make changes without assessing if its something we should do across the board 👍 (just setting some additional context)
But I agree adding it is a nice idea and we are also planning to create a new alz-bicep-accelerator
repo that contains production ready pipelines etc. which we plan to release before we make alz-bicep
"GA (v1.0.0)"
Awzm stuff, thanks for taking the time and responding so quickly!
Just an update here. Spoke to the awesome @BernieWhite himself this morning and we are going to slowly start adding PSRule, in an isolated branch, called ps-rule
on this repo for now (whilst we refine the tests).
Keep your eyes peeled for updates there.
Once we are happy with the testing we will PR the branch into main 👍
Superb! Great news.
@bengeset96 just an update on this. You may of seen the PSRule PR got merged last week and we will start adding more tests for each module in the samples
folders in each module directory over time 👍
Ado sync
@bengeset96 just an update on this. You may of seen the PSRule PR got merged last week and we will start adding more tests for each module in the
samples
folders in each module directory over time 👍
Great work from @BernieWhite and you together! I am really happy to see this now has taken place.
Describe the solution you'd like
Hi project maintainers and contributors.
Is it planned in the short-term roadmap to advance the CI/CT/CD for ALZ?
Before Bicep files&modules are merged into main branch (and then ACR), they should be validated with PSRule for Azure. This ensures that ALZ code is alligned with the framework.
These rules exist across five WAF pillars.
Describe alternatives you've considered
Branch policy for PRs where target branch is main (ideally these problems would have surfaced earlier in the coding inner loop, but sometimes mistakes can happen and bad files can make it back into source control etc).
CRON for main as well (when main is DRY and PSRule is constant being updated to align with WAF).
Policy consists of PSRule traversing through the parameter file or Bicep directly.
All Bicep code should be checked and not only input based on the PR. PRs often tend to focus code review solely on new code. Instead of looking at code as a whole and working to improve it as such..
Additional context
Nothing in particular for now.