Hello, my fellow Engineers and Developers!
As many of you on the journey of adopting Terraform have likely experienced, over time your configurations grow in size and sophistication. As teams mature, Cloud Engineering becomes a body for enablement for App Developers that builds platforms rather than running every infrastructure-as-code project. This allows everyone to scale and focus on what matters most to them.
For that to work, you have to start creating things like pipelines, Terraform modules, and in some cases custom providers to meet not only the tactical needs of your customers but also to meet the security and risk requirements of your company.
At that level of maturity, teams also generally start using tools like Git more professionally in order to create a culture of everything-as-code. This is where you start to see things like mono-repos getting refactored into built-for-purpose repos and teams starting to leverage git tags for versioning of bespoke modules.
As teams use these capabilities to shift left, you are left with some new problems which are things like “how do we make sure that when we update one thing the other things don’t break?” or “how do we ensure teams using our shared toolsets stay up to date with new versions without thinking about it?”.
For those who are starting to run up against this problem and looking to level-up their Terraform dependency management, I wanted to share that I recently released the first version of my Terraform Mesh command-line interface tool that can be used locally or in pre-commit hooks and CI/CD pipelines to ensure your Terraform executable, provider, and module versions always stay up-to-date!
As part of this release, the init, get, set, plan, and apply commands were introduced.
initsets up the state for the configuration
getreturns information about a given resource
setmakes updates to versions and constraints
planprovides an inventory of changes to be made
applymakes the planned changes happen (like magic, but real)
If some of those commands seem familiar, that is because I am making a deliberate attempt to try to map back Terraform CLI verbiage to this tool so that working between them feels more natural. Next up, there are several bugs to squash, new CLI features to implement (including environment variable support), refactoring to make the code DRY-er, and tests to write to get coverage back up above 90%.
It is a small way to give back to this amazing community.
I’d love to get your feedback, feature requests, or work with you to try it out if you have an interest. If you want to learn more, read the docs or check out the project on GitHub.
Leave a Reply