If you need to write unit tests for your deployment automation then you might be over complicating it.
If you need to write unit tests for your deployment automation then you might be over complicating it.
Terraform kinda took a similar path, although the reigning champion of this style of software has to be HTML templating solutions. "Templates shouldn't have code in them! Ever! Any! Totally broken bad bad bad, and that's why I started this new template language that has no code constructs in it at all! Although, uh, we do kinda need to be able to loop through things like table rows from databases... and, well, we need if statements to highlight a particular result... and, well, we need full arithmetic support so we can use the modulo operator on those rows... and we need functions to factor out reusable functionality at the template layer... and oh crap that's all you need for Turing Completeness, isn't it? Well... uhh..." "Hi, I'm another developer and I'm starting a new template language because that previous one is broken and busted and written by dum dums because it has Turing completeness in it! Templates shouldn't have any code in them, ever! Although, uh, I do kinda need for loops for table rows from databases..."
Really what we should be doing is generating data structures in <whatever> language rather than creating new languages.
You just use the js primitives.
I'm looking more at things like the Django template library, handlebars, Go HTML templates, etc. etc. And most especially things written with the idea that code shouldn't be in templates. Template languages that were always capable of running code, and were simply separate languages so designers don't have to learn a general-purpose programming language but can learn just this focused thing they need are obviously not what I mean.
I've drunk from the "templates shouldn't have logic in them" well too, but I think as you scale up it just becomes impractical. And in that case, you're better off with a template that always knew it was going to have code in rather than a template language that was designed from the beginning to not have it, but had code sneak in through the back door anyhow. The first one will at least be designed. The second one... well....
However, I do need to correct you that Puppet does support loops and various other ways to munge data for quite a few years/versions now. In addition, _Hiera_ is not that bad once you understand the overall hierarchy of your infrastructure and it gets easier if you shift the default data store to something like HashiCorp Vault for storing secret data.
We get away with not writing tests (we do heavy linting/checks though) in our Puppet infrastructure currently because everything has been documented for our development teams on best practices, trainings, and just communicating expectations well. There are some things that can sneak thru sure, but overall we've had #greatsuccess with just being open about we expect in our repos and being approachable to new committers for onboarding reasons.
Puppet can be a beast to keep up to date I will say, but if you have a good plan in place it's really a wonderful tool for everyone involved.
Your last sentence is true only for the most trivial of deployments, at which point, why are you using deployment automation in the first place, because it's a huge tech cost to invest in. If your deployments are that simple, why ass complexity by using a deployment automation and not just do a bin dump?
One shop I was at that's fairly well known had multiple fedora and centos RPM repos checked in. Compiled versions of Linux from version 2 to 5, silverlight exe's, pdf's, hundreds of excel files, what I had a hard time finding was actual source code.
I couldn't think of two better pieces of software to go die together.