It's weird to think of infrastructure/deploy automation in terms of "testing". Yes, you are always testing things, but not always in the "func test" sort of way

It's weird to think of infrastructure/deploy automation in terms of "testing". Yes, you are always testing things, but not always in the "func test" sort of way. There's automation testing, and there's testing of automation, and there's tests that are part of automation. Terratest seems to be the second, but it's the third one I think is most useful. If you build your infrastructure/deploy automation correctly, you should be able to redeploy your full stack all the time, and when it succeeds, throw traffic at it, and if you don't detect any anomalies, make that the new production service. On the detection of anomalies you simply move the traffic back to the previously deployed incarnation (or re-deploy the old incarnation, if necessary). For sufficiently large systems this gets more complicated as you can't just duplicate your resources, but the smaller pieces that have actually changed can be shifted around. The idea of a "rollback" is really just "return to a previously known good state", but it's misleading. It was previously good before now. Now things have changed, and it might not still be good. So just as much as you can test newly deployed changes before you make it the production service, you should probably also test the previously deployed changes to make sure they will work again if pressed back into service. So, regression testing for infrastructure, I guess. (You'd do this if you were building a physical product like a network appliance to make sure your old appliances still work with newer software releases, but we rarely think of software-derived infrastructure this way)