I'm currently using the ALZ Accelerator alongside Azure DevOps to establish my Azure landing zones, and I've customized the platform code to suit my needs. Recently, I successfully created a sample Azure Virtual Desktop (AVD) workload, deploying it from my local machine to a sandbox subscription, and everything is looking solid for production. However, I'm at a crossroads regarding the deployment strategy for this and other workloads. Should I keep everything in the same DevOps project and repository as the platform, or would it be better to separate them? Perhaps a new repository within the existing project would work? Also, if I later decide to deploy something like an Azure Data Factory in addition to AVD, how should I manage that? I'd appreciate any insights or practical examples regarding how workloads are typically deployed into landing zones as code.
3 Answers
In our setup, we decided that certain workloads, like Application Gateway and API Management, fit better under the platform rather than being separate landing zones. So, we created a new management group for these called 'SharedInternal'. This way, it's clear that these services are connected and managed together under the corporate landing zone framework.
Don't overthink it! Just use the same Azure DevOps project for all your deployments. Plus, there's an AVD accelerator that integrates with ALZ-Bicep. I just create a branch for any new work, do all the deployments from there, and after testing, I make a pull request to merge with the main branch.
I recommend keeping everything within the same DevOps project but managing workloads in different repositories. This approach allows for clearer separation and easier management of various workloads while maintaining cohesion in your DevOps processes.
Agreed! Segmenting your workloads helps manage them with different levels of risk and can make it easier to update your code.
Yep, that’s definitely the approach I believe in too.
It's great to see others considering centralized management for costly components like connectivity. It's often wiser than simply following reference architectures.