From 0893e56b67be1b5b94f527e1a55a118f4c8e003a Mon Sep 17 00:00:00 2001
From: Adar Nimrod <nimrod@shore.co.il>
Date: Tue, 14 Sep 2021 16:32:39 +0300
Subject: [PATCH] fixup! Post about Terragrunt.
---
content/tf-project-structure.rst | 37 ++++++++++++++++----------------
1 file changed, 19 insertions(+), 18 deletions(-)
diff --git a/content/tf-project-structure.rst b/content/tf-project-structure.rst
index 4d3b834..ec1978d 100644
--- a/content/tf-project-structure.rst
+++ b/content/tf-project-structure.rst
@@ -46,11 +46,10 @@ that has all of the changes (the sub-module changes, the calling modules
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
@@ -58,14 +57,15 @@ list the sub-modules needed with the Git ref used. This allows you to use the
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,
@@ -103,7 +103,8 @@ would look like this:
# 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
@@ -131,10 +132,10 @@ with the Terraform commands and plan files to stich everything togethere. Even
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
-----------
--
GitLab