@gaunacode
Building cloud-native apps on Azure. I can't stop self-improving.
I used to be a .NET developer. Nowaways, I am a DevOps solutions architect with a focus on Azure and Kubernetes.
I also love productivity topics, especially when it comes to doing more with less of my time. I'm also a daddy, so time is a limited resource for me.
Nothing here yet.
Montgomery Burns - Did you create the rg-terragrunt-mock-001 resource group? It's called out in the Wait ✋🏽, some prep work section. I did catch a mistake there, it did not mention that you also needed to create a storage container for the backend called environment-states, but you seem to have gone past that issue.
Denny Crane - Hey there! I was using RavenDB around 2015-2016 timeframe. It's been a long time since then. That was my opinion back then. My experience using RavenDB has been mostly for web applications. I remember reading Ayende's blog a lot and he was a firm believer in no repository or Unit of Work pattern. Thanks for the comment!
Because trunk based development, I would treat a failed build like the most important thing to tackle and all other work is put aside. So I would create a branch, start another PR, and see if it plans again. Then merge the PR and continue until the issue is solved. Sometimes, the issue is just a timeout in which case you can retry the GitHub action without opening PRs.
It is complicated. I think if you're using Terraform lightly and/or your team is new to it, you won't get much value out of this. If you're starting out, maybe start with an environment folder and trunk based development strategy so that if you want to use terragrunt, you can switch. If you are advanced Terraform user and don't feel the pain points that Terragrunt tries to address then it's probably not worth it.
