github.com/muratcelep/terraform@v1.1.0-beta2-not-internal-4/website/guides/core-workflow.html.md (about) 1 --- 2 layout: "intro" 3 page_title: "The Core Terraform Workflow - Guides" 4 sidebar_current: "guides-core-workflow" 5 description: |- 6 An overview of how individuals, teams, and organizations can use Terraform. 7 --- 8 9 # The Core Terraform Workflow 10 11 The core Terraform workflow has three steps: 12 13 1. **Write** - Author infrastructure as code. 14 2. **Plan** - Preview changes before applying. 15 3. **Apply** - Provision reproducible infrastructure. 16 17 This guide walks through how each of these three steps plays out in the context 18 of working as an individual practitioner, how they evolve when a team is 19 collaborating on infrastructure, and how Terraform Cloud enables this 20 workflow to run smoothly for entire organizations. 21 22 ## Working as an Individual Practitioner 23 24 Let's first walk through how these parts fit together as an individual working 25 on infrastructure as code. 26 27 ### Write 28 29 You write Terraform configuration just like you write code: in your editor of 30 choice. It's common practice to store your work in a version controlled 31 repository even when you're just operating as an individual. 32 33 ```sh 34 # Create repository 35 $ git init my-infra && cd my-infra 36 37 Initialized empty Git repository in /.../my-infra/.git/ 38 39 # Write initial config 40 $ vim main.tf 41 42 # Initialize Terraform 43 $ terraform init 44 45 Initializing provider plugins... 46 # ... 47 Terraform has been successfully initialized! 48 ``` 49 50 As you make progress on authoring your config, repeatedly running plans can help 51 flush out syntax errors and ensure that your config is coming together as you 52 expect. 53 54 ```sh 55 # Make edits to config 56 $ vim main.tf 57 58 # Review plan 59 $ terraform plan 60 61 # Make additional edits, and repeat 62 $ vim main.tf 63 ``` 64 65 This parallels working on application code as an individual, where a tight 66 feedback loop between editing code and running test commands is useful. 67 68 ### Plan 69 70 When the feedback loop of the Write step has yielded a change that looks good, 71 it's time to commit your work and review the final plan. 72 73 ```sh 74 $ git add main.tf 75 $ git commit -m 'Managing infrastructure as code!' 76 77 [main (root-commit) f735520] Managing infrastructure as code! 78 1 file changed, 1 insertion(+) 79 ``` 80 81 Because `terraform apply` will display a plan for confirmation before 82 proceeding to change any infrastructure, that's the command you run for final 83 review. 84 85 ```sh 86 $ terraform apply 87 88 An execution plan has been generated and is shown below. 89 # ... 90 ``` 91 92 ### Apply 93 94 After one last check, you are ready to tell Terraform to provision real 95 infrastructure. 96 97 ```sh 98 Do you want to perform these actions? 99 100 Terraform will perform the actions described above. 101 Only 'yes' will be accepted to approve. 102 Enter a value: yes 103 104 # ... 105 106 Apply complete! Resources: 1 added, 0 changed, 0 destroyed. 107 ``` 108 109 At this point, it's common to push your version control repository to a remote 110 location for safekeeping. 111 112 ```sh 113 $ git remote add origin https://github.com/*user*/*repo*.git 114 $ git push origin main 115 ``` 116 117 This core workflow is a loop; the next time you want to make changes, you start 118 the process over from the beginning. 119 120 Notice how closely this workflow parallels the process of writing application 121 code or scripts as an individual? This is what we mean when we talk about 122 Terraform enabling infrastructure as code. 123 124 ## Working as a Team 125 126 Once multiple people are collaborating on Terraform configuration, new steps 127 must be added to each part of the core workflow to ensure everyone is working 128 together smoothly. You'll see that many of these steps parallel the workflow 129 changes we make when we work on application code as teams rather than as 130 individuals. 131 132 ### Write 133 134 While each individual on a team still makes changes to Terraform configuration 135 in their editor of choice, they save their changes to version control _branches_ 136 to avoid colliding with each other's work. Working in branches enables team 137 members to resolve mutually incompatible infrastructure changes using their 138 normal merge conflict workflow. 139 140 ```sh 141 $ git checkout -b add-load-balancer 142 143 Switched to a new branch 'add-load-balancer' 144 ``` 145 146 Running iterative plans is still useful as a feedback loop while authoring 147 configuration, though having each team member's computer able to run them 148 becomes more difficult with time. As the team and the infrastructure grows, so 149 does the number of sensitive input variables (e.g. API Keys, SSL Cert Pairs) 150 required to run a plan. 151 152 To avoid the burden and the security risk of each team member arranging all 153 sensitive inputs locally, it's common for teams to migrate to a model in which 154 Terraform operations are executed in a shared Continuous Integration (CI) 155 environment. The work needed to create such a CI environment is nontrivial, and 156 is outside the scope of this core workflow overview, but a full deep dive on 157 this topic can be found in our 158 [Running Terraform in Automation](https://learn.hashicorp.com/tutorials/terraform/automate-terraform?in=terraform/automation&utm_source=WEBSITE&utm_medium=WEB_IO&utm_offer=ARTICLE_PAGE&utm_content=DOCS) 159 guide. 160 161 This longer iteration cycle of committing changes to version control and then 162 waiting for the CI pipeline to execute is often lengthy enough to prohibit using 163 speculative plans as a feedback loop while authoring individual Terraform 164 configuration changes. Speculative plans are still useful before new Terraform 165 changes are applied or even merged to the main development branch, however, as 166 we'll see in a minute. 167 168 ### Plan 169 170 For teams collaborating on infrastructure, Terraform's plan output creates an 171 opportunity for team members to review each other's work. This allows the team 172 to ask questions, evaluate risks, and catch mistakes before any potentially 173 harmful changes are made. 174 175 The natural place for these reviews to occur is alongside pull requests within 176 version control--the point at which an individual proposes a merge from their 177 working branch to the shared team branch. If team members review proposed 178 config changes alongside speculative plan output, they can evaluate whether the 179 intent of the change is being achieved by the plan. 180 181 The problem becomes producing that speculative plan output for the team to 182 review. Some teams that still run Terraform locally make a practice that pull 183 requests should include an attached copy of speculative plan output generated 184 by the change author. Others arrange for their CI system to post speculative 185 plan output to pull requests automatically. 186 187  188 189 In addition to reviewing the plan for the proper expression of its author's 190 intent, the team can also make an evaluation whether they want this change to 191 happen now. For example, if a team notices that a certain change could result 192 in service disruption, they may decide to delay merging its pull request until 193 they can schedule a maintenance window. 194 195 ### Apply 196 197 Once a pull request has been approved and merged, it's important for the team 198 to review the final concrete plan that's run against the shared team branch and 199 the latest version of the state file. 200 201 This plan has the potential to be different than the one reviewed on the pull 202 request due to issues like merge order or recent infrastructural changes. For 203 example, if a manual change was made to your infrastructure since the plan was 204 reviewed, the plan might be different when you merge. 205 206 It is at this point that the team asks questions about the potential 207 implications of applying the change. Do we expect any service disruption from 208 this change? Is there any part of this change that is high risk? Is there 209 anything in our system that we should be watching as we apply this? Is there 210 anyone we need to notify that this change is happening? 211 212 Depending on the change, sometimes team members will want to watch the apply 213 output as it is happening. For teams that are running Terraform locally, this 214 may involve a screen share with the team. For teams running Terraform in CI, 215 this may involve gathering around the build log. 216 217 Just like the workflow for individuals, the core workflow for teams is a loop 218 that plays out for each change. For some teams this loop happens a few times a 219 week, for others, many times a day. 220 221 ## The Core Workflow Enhanced by Terraform Cloud 222 223 While the above described workflows enable the safe, predictable, and 224 reproducible creating or changing of infrastructure, there are multiple 225 collaboration points that can be streamlined, especially as teams and 226 organizations scale. We designed Terraform Cloud to support and enhance 227 the core Terraform workflow for anyone collaborating on infrastructure, from 228 small teams to large organizations. Let's look at how Terraform Cloud makes 229 for a better experience at each step. 230 231 ### Write 232 233 Terraform Cloud provides a centralized and secure location for storing 234 input variables and state while also bringing back a tight feedback loop for 235 speculative plans for config authors. Terraform configuration interacts with 236 Terraform Cloud via the ["remote" backend](/docs/language/settings/backends/remote.html). 237 238 ``` 239 terraform { 240 backend "remote" { 241 organization = "my-org" 242 workspaces { 243 prefix = "my-app-" 244 } 245 } 246 } 247 ``` 248 249 Once the backend is wired up, a Terraform Cloud API key is all that's 250 needed by team members to be able to edit config and run speculative plans 251 against the latest version of the state file using all the remotely stored 252 input variables. 253 254 ```sh 255 $ terraform workspace select my-app-dev 256 Switched to workspace "my-app-dev". 257 258 $ terraform plan 259 260 Running plan remotely in Terraform Enterprise. 261 262 Output will stream here. To view this plan in a browser, visit: 263 264 https://app.terraform.io/my-org/my-app-dev/.../ 265 266 Refreshing Terraform state in-memory prior to plan... 267 268 # ... 269 270 Plan: 1 to add, 0 to change, 0 to destroy. 271 ``` 272 273 With the assistance of this plan output, team members can each work on 274 authoring config until it is ready to propose as a change via a pull request. 275 276 ### Plan 277 278 Once a pull request is ready for review, Terraform Cloud makes the process 279 of reviewing a speculative plan easier for team members. First, the plan is 280 automatically run when the pull request is created. Status updates to the pull 281 request indicate while the plan is in progress. 282 283 Once the plan is complete, the status update indicates whether there were any 284 changes in the speculative plan, right from the pull request view. 285 286  287 288 For certain types of changes, this information is all that's needed for a team 289 member to be able to approve the pull request. When a teammate needs to do a 290 full review of the plan, clicking the link to Terraform Cloud brings up a 291 view that allows them to quickly analyze the full plan details. 292 293  294 295 This page allows the reviewer to quickly determine if the plan is matching the 296 config author's intent and evaluate the risk of the change. 297 298 ### Apply 299 300 After merge, Terraform Cloud presents the concrete plan to the team for 301 review and approval. 302 303  304 305 The team can discuss any outstanding questions about the plan before the change 306 is made. 307 308  309 310 Once the Apply is confirmed, Terraform Cloud displays the progress live 311 to anyone who'd like to watch. 312 313  314 315 <!-- 316 317 TODO: Add this back in w/ screenshot of notification 318 319 And after the change completes, the team can be notified of its outcome. 320 321 [ Multi-screenshot of Slack alert indicating Apply completed successfully and 322 with error; except it's not gonna be Slack anymore? ] 323 324 --> 325 326 ## Conclusion 327 328 There are many different ways to use Terraform: as an individual user, a single 329 team, or an entire organization at scale. Choosing the best approach for the 330 density of collaboration needed will provide the most return on your investment 331 in the core Terraform workflow. For organizations using Terraform at scale, 332 Terraform Cloud introduces new layers that build on this core workflow to 333 solve problems unique to teams and organizations.