开云体育

Using Pulumi (which basically is a layer on top of terraform) made my life a lot easier coding infrastructure. It also allows for some level of testing that does not necessarily need deployment of the whole.?

I tend to only learn the details of different cloud environments as needed, and forget them immediately after, so a lot of my work with these tools is exploratory. I was moderately happy being able to split parts of the code that were not infrastructure-specific off into functions and test that I was generating the right combination of configurations. I only did a few of the mocked based testing of infrastructure components. More to get a feel of how they worked than of a necessity in the circumstances. Building more on any specific environment I would've started using this more.

In infra teams, or real devops teams, I've usually gotten to a point where monitoring was part of a definition of done. So changes in infrastructure would always get changes in monitoring too. That's important, but doesn't give me the same type of feedback as testing.

In orgs that are strong on compliance and risk, I've done a couple of projects where a really strong structural comparison between the expected state (SOLL) and actual state (IST) was part of infrastructure deployment. Parts of that could be handled by tools (ansible, terraform) that report on whether they needed to perform a change to get to the intended state. For other parts we build custom scripts/code to report things like access rights to files and folders, defined users and groups, network and?firewall config, etc. All those were part of the deployment pipeline, so we had a pretty strong check on state of infrastructure, and were always thinking about how to 'prove' an infrastructure / config change behaved as expected.

Different types of tests for different purposes, but maybe it helps a little in finding what you are looking for.

Wouter