Concepts

Key concepts and terminology

To effectively use Terrateam, it’s important to understand its key concepts and terminology. In the following section, we’ll explore the core components of Terrateam and how they work together to simplify your infrastructure management workflow.

Dirspace

At the heart of Terrateam is the concept of a dirspace. A dirspace represents a unique combination of a repository, a directory, and a workspace. It is denoted as a tuple (repository, directory, workspace) or simply (directory, workspace) when the repository is implied.

For example, consider a repository named repo with two directories, dir1 and dir2, and no extra configuration for workspaces. This repository would have two dirspaces:

1. (repo, dir1, default) or (dir1, default)
2. (repo, dir2, default) or (dir2, default)

Terrateam executes its operations, such as plan and apply, within the context of a dirspace.

Repository
  |
  |-- Directory 1
  |     |-- Workspace: default
  |
  |-- Directory 2
        |-- Workspace: default

Changes and file patterns

When a pull request is opened or updated, Terrateam detects changes in the repository based on the file_patterns specified in the when_modified configuration. By default, the file_patterns are set to ['**/*.tf', '**/*.tfvars'], which means Terrateam will consider changes to any files with .tf or .tfvars extensions.

Terrateam maps the detected changes to their appropriate dirspaces. These mapped dirspaces are referred to as changes. When Terrateam executes a plan or apply operation on the changes in a pull request, it only considers the dirspaces that have files modified in the pull request.

Autoplan and autoapply

Terrateam offers two automated operations:

• Autoplan: Automatically runs a plan on a new pull request or an update to an existing one. This allows you to see the proposed changes to your infrastructure before merging the pull request.
• Autoapply: Automatically runs an apply after merging a pull request. This ensures that the approved changes are applied to your infrastructure immediately after the merge.

These automated operations streamline your workflow and reduce the manual effort required to manage your infrastructure.

Locks and unlocks

Terrateam introduces the concept of locks to ensure that only a single change to a resource can be applied in a pull request at any given time. This prevents conflicts and maintains consistency in your infrastructure.

• Lock: A guarantee that only a single change to a resource can be applied in a pull request at any given time.
• Unlock: The process of releasing a lock, allowing other changes to be applied.

Tags and tag sets

Terrateam uses tags to group Terraform resources in a repository and match against those labels. There are two types of tags:

• Tag set: An unordered and deduplicated list of labels assigned to Terraform resources.
• Tag query: A tag set used for matching. Every tag in a tag query must exist in a tag set for a match to occur.

Tags provide a flexible way to organize and manage your Terraform resources within Terrateam.