Terraform.

Where Terraform fits on a long engagement.

The reason to adopt it is not automation, it is auditability. Infrastructure built by hand cannot be recreated, reviewed or explained six months later. Infrastructure in Terraform has a history, a diff before every change, and a path to rebuilding an environment that someone deleted.

Two things decide whether an estate stays healthy: where state lives and whether anyone still changes things by hand. State in a shared remote backend with locking, and a rule that the console is read-only, are what prevent the drift that makes a plan output untrustworthy.

What an assigned team does with Terraform.

Infrastructure as code only stays true if nobody edits the console. That is a discipline rather than a tool, and it survives exactly as long as the people who agreed it do — which is why drift is the standard condition of estates that changed hands.

The recovery work is unglamorous and worth doing: import what exists, establish state, and close the console. It is assigned under DevOps as a service, in your accounts, with the permissions held by the assigned specialist rather than by us.

What we use Terraform for.

• Environments that actually match Staging and production built from the same definitions, so a test result means something.
• Bringing an existing estate under control Importing infrastructure that was clicked together, which is slower than starting fresh and worth doing anyway.
• Change with a review step A plan attached to a pull request, so somebody sees a destructive change before it runs rather than after.

How Terraform capacity is assigned.

Infrastructure-as-code work is assigned under DevOps as a service, working in your accounts under your own billing and permissions. An Azendo service delivery manager answers for what that capacity delivers.