Terraform. GitOps. Lock Policies.
Tags: terraform, devops, cloud, infrastructureascode
Published: 2023-06-02 09:49:09

## What is Terrateam?
Terrateam is Terraform continuous delivery. Purpose-built for GitHub with an expressive configuration file, popular third-party integrations, advanced features like OIDC, access controls, drift detection, and more. Self-Hosted and Cloud versions available.

_⭐ Star us on GitHub: https://github.com/terrateamio/terrateam_

## Announcing Lock Policies

### Strict locking by default

In a collaborative environment, it can be easy to forget to apply a change that has been merged or to merge a change that has been applied. Guaranteeing your infrastructure matches your code is one of the benefits of using Terrateam.

When a change is applied in a pull request, Terrateam acquires a lock on the directory that changed and requires it be merged into the main branch.
Similarly, if the change is merged, Terrateam acquires a lock on the directory and requires that it be applied.  A change is either merged or applied to acquire a lock, and the other operation must be done to release the lock.

### Safety guarantees can get in the way
Some directories are different.  For example, it is common for Terraform repositories to have both development environments and production environments described in them.  Using our [access control](https://terrateam.io/docs/features/access-control) feature, Terrateam can be configured such that anyone can modify development but production is locked down.  Sometimes, to iterate faster, it makes sense to plan and apply development changes locally before making a pull request.

Because the development environment is sometimes run via Terrateam and sometimes managed outside of Terrateam, the safety guarantees can get in the way. Terrateam is too strict in these scenarios.

### Lock Policies
To support this workflow, we've introduced a new
[workflow](https://terrateam.io/docs/features/workflows) configuration called `lock_policy`.  The `lock_policy` option tells Terrateam under what situations it should acquire a
lock.

It has four modes:

- `strict` - This is the default and matches the current behavior.  If a user comments `terrateam apply` in the pull request or the change is merged, Terrateam acquires a lock on the directory until the complimentary operation is performed.  We recommend all production directories keep this setting.
- `apply` - This instructs Terrateam to only acquire a lock if the directory has been applied in Terrateam (`terrateam apply`).  The lock will be released once the change is merged.  If the change is just merged, Terrateam will not acquire a lock.  This is what should be used in the scenario described above. The development directories should be set to `lock_policy: apply`, that way if they are applied outside of Terrateam, no lock is acquired.
- `merge` - This instructs Terrateam to only acquire a lock if the directory has been merged.  The lock will be released when the change is applied (`terrateam apply`).  This is useful if a pull request is used as a playground in development and then closed when done, rather than merging.
- `none` - Never acquire a lock.

Of course, there are other situations where these settings make sense other than the ones described here.  But, be careful!  Locking is fundamental to how Terrateam keeps code and infrastructure synchronized.

## Configuration
The locking policy is defined in the `workflows` section.  To set `lock_policy` to `apply` for all directories `dev` directories:

```yaml
workflows:
  - tag_query: dev in dir
    lock_policy: apply
```

## Docs
Check out the [Terrateam Docs](https://terrateam.io/docs) for more examples.