Domain specific language #495
Description
We currently have many self-designed components which we deploy through one-off Azure Pipelines with specific input parameters.
Examples to name a few:
- devops environments - a combination of dtap Azure resource groups and an Azure DevOps project with Azure service connections
- App service environments
- Isolated service environments
- Custom roles
- Shared app service plans
Actually, even more deployments are done through custom components if I think of it. At decentral team's level we provide custom tasks to deploy Azure resources. E.g. app service, virtual machine, kubernetes service, etc.
Downside is that it does not cater for versioned desired state. I am looking for a GitOps based solution where we are just able to commit domain specific language specifications which will then be picked up by a CI trigger and processed into Azure deployments.
If we were to build this ourselves, it should revolve around git diff in order to only process the changed desired state. I am trying to get my head around testing this all. During pull request one would run a whatif analysis. And in main it would run the real thing. But what to do when the deployment fails? I see examples that pick the commit of the last successful build as the basis for comparison where it left off.
Another design question would be how would you proceed if and when you move a component to version 2?
And how can you repair/refactor the desired state description without running any deployments? Just temporarily switching off all CI triggers does not make full sense to me.
Any guidance from your AzOps perspective on this?