fixup! Post about Terragrunt.

changes, any fallout from those changes).

This process fitted us nicely. The PR had the entire picture and we could really

see if the change improved anything (like adding an output to a module and

fetching it in a different module would be clear if you see it being used). We

did on occasion had conflicting changes and we did had to use targeted

:code:`plan` and :code:`apply` but as far as I can remember no more than once a

quarter.

see if the change improved anything (like adding an output to a module to be

used in a different module would be clear if you see it being used). We did on

occasion had conflicting changes and we did had to use targeted :code:`plan` and

:code:`apply` but as far as I can remember less than once a quarter.

Terragrunt recommends splitting the repository in 2, one for sub-modules and one

for actually deployed modules. Then you create :code:`terragrunt.hcl` files that

RDS database sub-module from today but the auto-scaling group from last year. I

see little point in this.

The change process goes as follows, 1 PR for the sub-modules repository and (at

least) 1 for the live repository. Now I hear that the recommendation has

changed. The new recommendation is that each sub-module will be in a separate

repository. So more PRs for each change (that one change of adding an output and

using it became less obvious but requires more work, I wouldn't call it a win).

I wonder if there's any place that has 2 repositories, 1 for code 1 for the

tests and you change the code, and when it's merged you go to the tests repo and

update the tests there to use the new code to see if it passes?

The change process goes as follows, 1 PR for the sub-modules repository and 1

for the live repository (or more, we haven't gotten around to discussing

environments yet) Now I hear that the recommendation has changed. The new

recommendation is that each sub-module will be in a separate repository. So more

PRs for each change (that one change of adding an output and using it became

less obvious but requires more work, I wouldn't call it a win).  I wonder if

there's any place that has 2 repositories, 1 for code 1 for the tests and you

change the code, and when it's merged you go to the tests repo and update the

tests there to use the new code to see if it passes?

Another outcome from this way of working I keep seeing is that because changes

are not applied (or planned) before merging the changes to the sub-module,

    # Review the changes.

    terraform apply tfplan

For making life a little easier I added the following snippet to each module:

For making life a little easier I also added the following snippet to each

module:

.. code:: terraform

on paper this doesn't look like a good idea and it isn't one in practice, making

debugging issues difficult.

It also suggests that you can have different versions of the different

sub-modules in use across different environments, putting emphais on having

the :code:`main` branch match exactly what is each environment instead of

putting emphasis of avoiding drift between the different environments.

It also suggests that you can have different versions of the sub-modules in use

across different environments, putting emphais on having the :code:`main` branch

match exactly what is each environment instead of putting emphasis of avoiding

drift between the different environments.

Conclusions

-----------