Open aidansteele opened 5 years ago
Actually, there's no reason up
shouldn't be a wrapper around package
, plan
and apply
.
As of eb43d0b3c02b92f46c1ebdbfd259ac0808f717a7
up
is done. It now packages, plans and applies.package
behaves as described above.plan
and apply
don't exist yet
aws cloudformation package
andaws cloudformation deploy
behave differently tostackit package
andstackit execute
.At first I thought it would be more useful to create and display a changeset as part of
stackit package
, making it similar toterraform plan
. This arguably is more useful in the typical case, but isn't as useful in the CI case.Specifically, in a CI setup we might want to archive "artifacts" from a Build stage and use them in a later Deploy stage. Right now we are archiving
stackit.packaged.yml
. The problem is that this isn't replayable, a user can't re-run just the Deploy stage as they might expect.We could ameliorate this with the following design:
stackit package
acts identically toaws cloudformation package
, albeit with sensible defaults -- it will emit a<template name>.packaged.yml
file.stackit plan
is analogous toterraform plan
stackit apply
is analogous toterraform apply
stackit up --stack-name <stack> --template <template name>.packaged.yml
is a wrapper aroundplan && apply
, i.e. it creates and executes a change set.