DEV Community

Discussion on: Multi environment AZURE deployments with Terraform and GitHub (Part 1)

Collapse
 
pwd9000 profile image
Marcel.L • Edited

Hello @mostafaameenhashim :-)

Key vault secret names have a limitation and only allows Alphanumerics and hyphens. Special characters such as “_” is not allowed in key vault secret names. And thus I have set it with hyphens “-“.

The key vault secret “names” is not meant to be used as-is in GitHub directly, the key vault secrets are meant to be used as a reference to set up the GitHub secrets later in the tutorial. As shown how to set up the GitHub secrets in step 2 (you have to use “_” as shown in step 2, when setting the secrets up in GitHub)

Collapse
 
mostafaameenhashim profile image
MostafaAmeenHashim

Hi Marcel,
Its all good with me and managed to create them. i have the following questions please:

1) Does the main.tf is as same as the standard Provider.tf file?
2) What's the best way to create a TF destroy? a separate workflow on GitActions
and az_tf_destroy.yml?
3) To follow your model, I must create a new .yml per each Azure resource that I need to create?
4) Do you advise to use a branch when add new resources etc?

Thanks!

Thread Thread
 
pwd9000 profile image
Marcel.L • Edited

@mostafaameenhashim
No worries.
As to your additional questions.
Yes, I use my main.tf file to define the versioning and providers for my module, you may have a different file, it does not really matter what the file name is called.

I did not make a destroy Reusable workflow as I have spent more time on developing the marketplace actions. But my guide here will get anyone started on writing their own reusable workflows. So feel free to create one in your environment :)

Also take a look at Part2 (dev.to/pwd9000/multi-environment-a...) in there I show how you can do deploy and destroy using my marketplace actions instead.

You do not need to create a new .yml file per resource, only per module/collection, remember a module can be a resource or a collection of resources. I would suggest you group similar resources together and not build one resource at a time using one .yml at a time as that is not needed.

Just group similar things together such as networking or foundational resources together, This is totally up to you.

Your branching strategy is also totally up to you. :)
I like to use trunk based branching strategy, but that is only my personal preference.