ALZ-Bicep
ALZ-Bicep copied to clipboard
💡 Feature Request - PSRule for performing pre-validation of Bicep files & modules resources against Well Architected Framework
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.
- Cost optimization
- Operational excellence
- Performance effiency
- Reliability
- Security
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.
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.
Questions for you
- Is your request purely focussed on the ALZ-Bicep repo or is it wider than that, if so, please explain further?
- We have other implementations to consider here like the Portal & Terraform as well of which both do different testing today.
- Is there anything you've seen today that "causes concern" that has sparked this issue creation?
- Are we missing any tests that make you feel "less confident" in our solution?
- Do you have suggestions on the rules to run against the repo/s with PSRule?
- Azure
- CAF
- WAF
- Others?
Thanks again for raising this and looking forward to your replies 👍
Jack
@jtracey93
- It is first of all targeting this repository. Reason why is simply because organizations tend to fork/download this repo and as is/use with minor tweaking. Creating anything enterprise related or just Bicep related for that sake with good quality is hard, so many people tend and will use this repository. It is maintained by the team with some good practices&guidelines so you don't fall into the many traps of creating LZs and what is related to them.
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.
- Nothing particular besides PSRule and some Pester testcases are complaining a bit. I often tend to do customer implementations with ALZ and have to adjust accordingly to what tooling like PSRule&Pester are giving feedback about.
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.
- I would use the Azure ruleset on it. Currently has ish 270 predefined rules and branch is constant being pushed with awzm stuff and is based on the five (5) WAF pillars. CAF is only for tags I believe and those are often very individual and heated topics/discussions in organizations. There is Kubernetes ruleset as well, but that is deprecated more or less and functionality is being pused into Azure ruleset. PSRule.Rules.Azure would be great. 💯 👍
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.