News for hackers. Stuff that matters.
Re:The Plan-Execute Pattern by JohnMakin on Wednesday June 26, 2024 @02:04PM (#40802673)
This is a similar pattern to Terraform, correct? (Plan/Apply). I like this pattern, however, when implementing it into automation it presents a conundrum. Often, code will be checked into a repository with a "plan" attached to it. Great. Merge after plan is approved, then automation executes the plan. However, lots of providers will only show errors on the "execute" phase (e.g., on apply, "resource already exists" errors, etc.), leading to a ridiculously slow feedback loop of having to open new PR's, go through all approval chains again, merge, execute plan again. Debugging a simple issue like a misnamed variable can take days this way.

I have yet to see a graceful work flow here in a production environment and would love to hear about one. (No I will not use terraform cloud)

Re:The Plan-Execute Pattern by rnubel on Wednesday June 26, 2024 @04:00PM (#40804005)
It's more manageable to have automation (i.e., Atlantis) do the apply on the open PR and then only merge if it succeeds. You have to rely on the locking feature of Atlantis to avoid conflicts, but it's worked pretty well at scale at Enova (~50 Terraform changes a day).
Re:The Plan-Execute Pattern by DougBTX on Wednesday June 26, 2024 @03:05PM (#40803365)
I’d recommend testing the Apply step in a staging environment before rolling out.

For releases, the plans don’t need to be committed to version control. Instead they can be generated in CI just before release, then put reviewing the plan on the checklist before confirming the release to prod.