Introduction

As we've mentioned before in other blog posts, Terrateam is heavily influenced by Atlantis. But it's not a copy. We chose to diverge from Atlantis in a number of ways, the biggest being tags and locks.

In this post we'll briefly discuss the semantics of locking in Atlantis vs. Terrateam.

Atlantis

In Atlantis, planning a pull request takes out a lock on that pull request. That means that no one else can plan against the same set of resources in another pull request until the original lock is removed or the change is applied. This can easily get in the way of other development. In fact, there is a long standing Atlantis issue about this exact scenario.

Terrateam

With Terrateam, we decided that only operations creating change against infrastructure should lock. Planning is side-effect free as it only produces a plan file that can be applied later.

Therefore, you can plan at any time in Terrateam. Multiple pull requests can plan at the same time. Even if a pull request has a lock, another pull request can plan.

Exceptions

The only exception in Terrateam is when an apply is being executed.

An apply is always mutually exclusive with any other operation. Because an apply is taking action against a Terraform resource, if a plan were to execute at the same time, it might not accurately reflect the changes applying it should make.

An apply invalidates a plan

Because our locks do not impact performing a plan, we do take care to invalidate any plan after an apply has been executed. This is important to ensure that the right changes are applied.

Conclusion

We think having the ability to plan at all times can be a huge time saver and is more efficient than the Atlantis approach of always locking.

Give Terrateam a shot for a safe and no-lock-on-plan workflow.

Features

Learn More

Learn

Connect