Comments by "" (@ContinuousDelivery) on "What Is Infrastructure As Code?" video.

  1. Thank you for sticking with us! Unfortunately, the whole team went down with Covid, so we did the best we could in the circs - not up to our usual production standards, sorry!
    15
  2. Test Driven IaC is still pretty "bleeding edge" as far as I can tell. I think that the difficulty is the same for any code, testing at the edges of the system, where there is input and output. I think that the solutions are the same, try to marginalise the inputs and outputs so that you can fake them and test the rest if the code. The problem with IaC is that it is a lot about the I/O. I worked on a team where we did this, and got some real value of it, but it was always a bit more tactical than regular TDD. We were using TeamCity for build management, and did most of of our glue automation with Unix shell scripts. We got decent TDD in place for the shell scripts, we had a working deployment pipeline for our deployment pipelines, and we designed the pipeline around a collection of simple adapters, so that we could run tests of the logic in TeamCity against unit-like tests that talked the to the adapters. Then we had some acceptance tests, with a real mini-project that had a handful of real unit tests and a handful of real acceptance tests so that we could run the pipeline and see it report success, report failure, and so on. As I said it wasn't really elegant, but it did work pretty well for us.
    4
  3. Unfortunately, the whole team went down with Covid, so we did the best we could in the circs - not up to our usual production standards, sorry!
    3
  4. All sorts, helm, k8, terraform, docker, puppet, chef, shell scripts… Whatever it takes, whatever makes sense for you tech. I think that the philosophy is much more important than the tech, but then I nearly always say that 😉😁
    2
  5.  @stephenbutler3929  Thanks, we're all on the mend now.
    2
  6.  @qj0n  No difference. How config changes are executed are choices of pipeline design. My default is infrastructure config changes flow the the same pipeline as application changes, are tested with the version of the application that they related to, and are deployed as part of the application deployment. If there are no changes to the app, config changes flow through the pipeline in the same way, are tested with the current version of the app, and deployed at the end of the pipeline. No special cases, wether the prod deployment is automated or manually triggered is really just a choice of how your pipeline is configured. I agree with you, I much prefer that my infrastructure config lives alongside the app, so that it is clear which versions of the app this config has been tested with.
    2
  7. You script everything, and employ data-migration strategies. I talk about some aspects of this here: https://youtu.be/JPfbjKl9jbw
    1
  8. Thanks for spotting that - I have added this to the details: "Infrastructure As Code", by Kief Morris ➡️ https://amzn.to/3ppZXxJ
    1
  9. I don't see a"vs"? I use TBD for IaC changes, my preference, because it is simplest, is to keep everything in the same repo, source, config, IaC code, everything.
    1
  10.  @crushingbelial  I am still not sure that I understand what you are describing. At the moment this seems to me like a complicated way to describe a simple idea. TBD = using version control to simplify the relationships between things. Have one repo that contains everything. So the 'current' version is definitive, we know that this IaC config works with this version of the app, because they are all on one repo, and usually, ideally were all tested together. That is all TBD is about. Now you may add things like feature flags for some kinds of change if you really want to, but the easiest use of TDB is to make every change atomic, and every change keeps the system correct. Sometimes, for complex changes that you want to drip into prod over a series releases, more complex things like FFs can help, but this is only peripherally related to IaC.
    1
  11. You don't. You write the SW so that it runs on all hardware configurations, and self-configures on start-up, at least that is what the HP LaserJet team did, and I think that is how Tesla work too. This means that you only have one version to maintain, and you can test it in a wide range of configurations.
    1
  12. It is always possible to miss things, the strategy isn't to expect to be perfect from the outset, it is to do your best in test, and then plug the holes in your thinking as you discover them by adding more tests when you find the gaps in your thinking, so these problems only happen once. Running the SW on the same hardware is ok if you can automate that, if not it doesn't scale and the testing is lower quality.
    1
  13. Thanks
    1
  14. GitOps is ok, though I don’t think it adds anything significant to the concepts, so sure, certainly good enough, no different to any other IaC approach though.
    1