Initializing and Building Pipeline

This lesson moves from concepts to implementation by building a production-grade Azure DevOps pipeline for Terraform. The pipeline follows CI/CD best practices: initialize the workspace, produce a safe reviewable plan, and gate destructive changes behind approvals before applying.

Why `terraform init` runs first

terraform init prepares the working directory for all subsequent Terraform commands. It configures the backend, authenticates via the Azure DevOps service connection, downloads provider plugins, and sets up any required modules. Because hosted Azure DevOps agents are ephemeral, this initialization must run on every pipeline job unless you use a self-hosted agent with preinstalled providers and tooling. Typical Azure DevOps task to run init:

- task: TerraformTask@5
  inputs:
    provider: 'azurerm'
    command: 'init'
    backendServiceArm: 'tf-01'
    backendAzureRmResourceGroupName: 'rg-kodekloud-demo-01'
    backendAzureRmStorageAccountName: 'sakodeklouddemotf'
    backendAzureRmContainerName: 'tfstate'
    backendAzureRmKey: 'demo.tfstate'

Important operational points:

backendServiceArm should reference the Azure DevOps service connection with the appropriate permissions.
The resource group, storage account, container, and key determine where the state file is stored. Remote state provides centralized state storage, state locking, and consistent execution across runs.
Run init at the start of every pipeline job — before plan or apply.

Terraform `plan` — the safe review step

terraform plan compares your configuration against the remote state, computes proposed changes, and outputs an execution plan without applying changes. In CI/CD, plan is the reviewable artifact that tells reviewers and automation exactly what will change. Example plan task:

- task: TerraformTask@5
  inputs:
    provider: 'azurerm'
    command: 'plan'
    environmentServiceNameAzureRM: 'tf-01'

Best practices for plan in pipelines:

Run plan automatically on every commit or PR to maintain visibility over intended changes.
Persist the produced plan as an artifact so the exact plan can be consumed by the apply stage.
Always run plan before any apply.

Best practice: Run plans automatically (on every commit or PR) but gate apply with explicit approvals for non-development environments. This preserves visibility while limiting destructive actions.

Plan vs Apply separation and approvals

Separation of plan and apply is an enterprise pattern that improves safety and governance:

Automatically run plan for every pipeline execution (development, feature branches, PRs).
Gate apply for test/UAT/production with human approvals or environment checks.
Use Azure DevOps stage approvals, environments, and gates to enforce these controls.

The image displays a presentation slide about "Plan vs Apply Separation" with best practices, and an approvals settings panel from a software interface.

When to use plan separation

Implement plan/apply separation for:

Test, UAT, and production environments — always require review/approval.
Development environments — you may allow automated apply for rapid iteration, but track changes and revert controls.

Terraform `apply` — execution phase

terraform apply executes the plan (or computes and applies changes), updates remote state, and uses state locking to prevent concurrent modifications. In pipelines, apply is typically run only after the plan has been reviewed and approved. Example apply task:

- task: TerraformTask@5
  inputs:
    provider: 'azurerm'
    command: 'apply'
    commandOptions: '--auto-approve'
    environmentServiceNameAzureRM: 'tf-01'

Notes:

--auto-approve is required for non-interactive pipelines but should only be used after an explicit approval gate.
apply is production-impacting — restrict it to authorized runs and environments.

Warning: Never enable automated apply in production pipelines without a gated approval. --auto-approve will apply changes immediately and cannot prompt for interactive confirmation.

Quick reference: init, plan, apply

Command	Purpose	Typical pipeline inputs	Best practice
`init`	Prepare backend, download providers, authenticate	`backendServiceArm`, storage account/container/key	Run at the start of every pipeline job
`plan`	Compare configuration to remote state and output execution plan	`environmentServiceNameAzureRM`, save plan artifact	Run on every commit/PR; produce artifact for review
`apply`	Execute changes and update remote state	`commandOptions: '--auto-approve'`, gated approvals	Require approvals for test/UAT/prod environments

Conclusion

A robust Terraform pipeline follows a consistent sequence:

terraform init — initialize backend and providers.
terraform plan — produce a reviewable plan and persist it as an artifact.
terraform apply — execute the reviewed plan, only after approvals for protected environments.

By separating plan and apply and leveraging Azure DevOps approvals and environments, you maintain visibility, enforce governance, and reduce risk for infrastructure changes.

Links and references

Watch Video

Introduction

Executing Pipelines

Introduction

Infrastructure as Code Fundamentals

Terraform Cloud

Setting up environment

Azure Context for Terraform

HashiCorp Configuration Language

Terraform Providers

Variables

Outputs and Dependencies

Iteration and Logic

Advanced Constructs

Terraform State Fundamentals

Remote State

Terraform Workspaces

Terraform CLI

Lifecycle Meta-Arguments

Data Sources

Provisioners

Debugging Terraform

Terraform Modules

Azure DevOps Integration

Azure Pipelines for Terraform

Initializing and Building Pipeline

Why `terraform init` runs first

Terraform `plan` — the safe review step

Plan vs Apply separation and approvals

When to use plan separation

Terraform `apply` — execution phase

Quick reference: init, plan, apply

Conclusion

Links and references

Watch Video

​Why terraform init runs first

​Terraform plan — the safe review step

​Plan vs Apply separation and approvals

​When to use plan separation

​Terraform apply — execution phase

​Quick reference: init, plan, apply

​Conclusion

​Links and references

Watch Video

Why `terraform init` runs first

Terraform `plan` — the safe review step

Plan vs Apply separation and approvals

When to use plan separation

Terraform `apply` — execution phase

Quick reference: init, plan, apply

Conclusion

Links and references