github.com/danp/terraform@v0.9.5-0.20170426144147-39d740081351/website/source/docs/enterprise/runs/index.html.md (about)

     1  ---
     2  layout: "enterprise"
     3  page_title: "Runs - Terraform Enterprise"
     4  sidebar_current: "docs-enterprise-runs"
     5  description: |-
     6    A "run" in Atlas represents the logical grouping of two Terraform steps - a "plan" and an "apply".
     7  ---
     8  
     9  # About Terraform Enterprise Runs
    10  
    11  A "run" represents the logical grouping of two Terraform steps - a "plan" and an
    12  "apply". The distinction between these two phases of a Terraform run are
    13  documented below.
    14  
    15  When a [new run is created](/docs/enterprise/runs/starting.html), Terraform
    16  Enterprise automatically queues a Terraform plan. Because a plan does not change
    17  the state of infrastructure, it is safe to execute a plan multiple times without
    18  consequence. An apply executes the output of a plan and actively changes
    19  infrastructure. To prevent race conditions, the platform will only execute one
    20  plan/apply at a time (plans for validating GitHub Pull Requests are allowed to
    21  happen concurrently, as they do not modify state). You can read more about
    22  Terraform plans and applies below.
    23  
    24  ## Plan
    25  
    26  During the plan phase of a run, the command `terraform plan` is executed.
    27  Terraform performs a refresh and then determines what actions are necessary to
    28  reach the desired state specified in the Terraform configuration files. A
    29  successful plan outputs an executable file that is securely stored in Terraform
    30  Enterprise and may be used in the subsequent apply.
    31  
    32  Terraform plans do not change the state of infrastructure, so it is
    33  safe to execute a plan multiple times. In fact, there are a number of components
    34  that can trigger a Terraform plan. You can read more about this in the
    35  [starting runs](/docs/enterprise/runs/starting.html) section.
    36  
    37  ## Apply
    38  
    39  During the apply phase of a run, the command `terraform apply` is executed
    40  with the executable result of the prior Terraform plan. This phase **can change
    41  infrastructure** by applying the changes required to reach the desired state
    42  specified in the Terraform configuration file.
    43  
    44  While Terraform plans are safe to run multiple times, Terraform applies often
    45  change active infrastructure. Because of this, the default behavior
    46  is to require user confirmation as part of the
    47  [Terraform run execution](/docs/enterprise/runs/how-runs-execute.html). Upon
    48  user confirmation, the Terraform apply will be queued and executed. It is also
    49  possible to configure
    50  [automatic applies](/docs/enterprise/runs/automatic-applies.html), but this option is
    51  disabled by default.
    52  
    53  ## Environment Locking
    54  
    55  During run execution, the environment will lock to prevent other plans
    56  and applies from executing simultaneously. When the run completes, the next
    57  pending run, if any, will be started.
    58  
    59  An administrator of the environment can also manually lock the environment, for
    60  example during a maintenance period.
    61  
    62  You can see the lock status of an environment, and lock/unlock the environment
    63  by visiting that environment's settings page.
    64  
    65  ## Notifications
    66  
    67  To receive alerts when user confirmation is needed or for any other phase of the
    68  run process, you can
    69  [enable run notifications](/docs/enterprise/runs/notifications.html) for your
    70  organization or environment.