I am deploying the stackit-landing-zone to an existing stackit organization with existing workloads. My intention is first to deploy a "dev" stage of the LZA so that I can play around with the landing zones and gain confidence in my use case. This also required so that my platform team can verify any changes we make to the landing zone core, like the firewall appliance etc.
Then I want to deploy a "prod" version of the landing zone with my configuration to the same STACKIT organization. Yes, ideally I'd have multiple STACKIT organizations to play around with but getting them set up with billing, admin accounts, IDP federation etc. is cumbersome. Also, I have brownfield projects already that I'd like to migrate int my productive deployment of the stackit-landing-zone eventually, so keeping it in the same organization would simplify my life.
The stackit-landing-zone already includes company_name company_code variables for prefixing deployed resource names. This is already solving part of the problem. In addition it would be useful to have an optional parent_id that I can supply so that resources can be placed underneath a folder instead of directly under the organization root.
We use a similar pattern for our other cloud foundations on Azure and GCP as well.
I am deploying the stackit-landing-zone to an existing stackit organization with existing workloads. My intention is first to deploy a "dev" stage of the LZA so that I can play around with the landing zones and gain confidence in my use case. This also required so that my platform team can verify any changes we make to the landing zone core, like the firewall appliance etc.
Then I want to deploy a "prod" version of the landing zone with my configuration to the same STACKIT organization. Yes, ideally I'd have multiple STACKIT organizations to play around with but getting them set up with billing, admin accounts, IDP federation etc. is cumbersome. Also, I have brownfield projects already that I'd like to migrate int my productive deployment of the stackit-landing-zone eventually, so keeping it in the same organization would simplify my life.
The stackit-landing-zone already includes
company_namecompany_codevariables for prefixing deployed resource names. This is already solving part of the problem. In addition it would be useful to have an optionalparent_idthat I can supply so that resources can be placed underneath a folder instead of directly under the organization root.We use a similar pattern for our other cloud foundations on Azure and GCP as well.