4 ms·

How does "It auto-updates every time you deploy" fit with "The difference between my local, staging, and production is tiny"? It sounds like you have little con

How does "It auto-updates every time you deploy" fit with "The difference between my local, staging, and production is tiny"? It sounds like you have little control over your dependencies, and the differences between your local, staging, and production environments are the newer versions of your dependencies which you haven't tested against. I like the idea of being able to precisely control both my code and all of my dependencies, so that I know for certain that I'm deploying exactly the same overall system that I tested. Containers are much better for that than the old way, because you could never be certain that your OS and system software were exactly the same in production as they were local and staging. But to achieve that precision, you need to use precise version numbers, and you need to install your dependencies from a local repository to be really sure.

rowyourboat 9y ago
> How does "It auto-updates every time you deploy" fit with "The difference between my local, staging, and production is tiny"? It builds once, and then that very container with those dependencies gets pushed through testing, staging, and production. No more changes happen after the build.
- DougWebb 9y ago
  Ok, that definitely works, assuming you set your process up that way. In my mind, "deploy" starts with build and targets a single environment. Eg: deploy to staging, deploy to production. I've been working with too many clients these past few years who do it that way. One has a real TeamCity CI setup, but they rebuild for production too. Way back in the day, I helped push my company towards a process where build artifacts were tied to specific commit ids (SVN, back then) so that everything that reached production could be traced back through QA and Development. So, basically the process you described. No containers back then, of course, and no VMs either. We had real servers in our server farm.
  - _ix 9y ago
    I thought the very basis of continuous integration/delivery was the same build moving through various stages of readiness and environments until it’s delivered to production, automatically and continuously. In short, if it’s called continuous delivery, that’s about the only way the process could be setup with containers and still be called CD. Or am I mistaken?
viraptor 9y ago
I think that by "It auto-updates every time you deploy." the OP meant - every time you build an image to deploy. But that exact same image goes through testing environments. (test -> staging -> prod) Local may test with something that's a point release further, but in that case you'd find the issue when testing and pin the python to a specific 3.6.x until you resolve the problem and start rolling again. There's also nothing preventing your from building images with precise control over versions of your dependencies. You can do it in the image in the same way you'd do it anywhere else. Specify your own repos and use lock files, or whatever your language allows.
apeace 9y ago
You're right, I didn't make that clear. What you're missing is that the beginning of the "deploy" process is building the image on your local (or on CI). That's when the update happens. Then you test it on staging, and if all is well you deploy to production. If there's a problem it's easy to change your Dockerfile from "python:3" to "python:3.6.2" in order to go back to what you had. Or stick with "python:3.6" if you only want security patches. Or, if you want to miss out on those security patches in order to guarantee more stability, go with "python:3.6.2" and decide when to test and deploy an upgrade.
- scarface74 9y ago
  Are you referring to Canary Builds? https://www.thoughtworks.com/radar/techniques/canary-builds https://www.thoughtworks.com/radar/techniques/canary-builds
  - apeace 9y ago
    No, I am more talking about a standard process of applying security patches (and/or bugfix patches). I'm countering the claim in the article that using containers somehow makes software orgs more prone to "unmaintained" OS's. I'm saying that has little to do with containers, and if anything containers make it a lot easier to get security updates.

rowyourboat 9y ago

> How does "It auto-updates every time you deploy" fit with "The difference between my local, staging, and production is tiny"? It builds once, and then that very container with those dependencies gets pushed through testing, staging, and production. No more changes happen after the build.

DougWebb 9y ago
Ok, that definitely works, assuming you set your process up that way. In my mind, "deploy" starts with build and targets a single environment. Eg: deploy to staging, deploy to production. I've been working with too many clients these past few years who do it that way. One has a real TeamCity CI setup, but they rebuild for production too. Way back in the day, I helped push my company towards a process where build artifacts were tied to specific commit ids (SVN, back then) so that everything that reached production could be traced back through QA and Development. So, basically the process you described. No containers back then, of course, and no VMs either. We had real servers in our server farm.
- _ix 9y ago
  I thought the very basis of continuous integration/delivery was the same build moving through various stages of readiness and environments until it’s delivered to production, automatically and continuously. In short, if it’s called continuous delivery, that’s about the only way the process could be setup with containers and still be called CD. Or am I mistaken?

viraptor 9y ago

I think that by "It auto-updates every time you deploy." the OP meant - every time you build an image to deploy. But that exact same image goes through testing environments. (test -> staging -> prod) Local may test with something that's a point release further, but in that case you'd find the issue when testing and pin the python to a specific 3.6.x until you resolve the problem and start rolling again. There's also nothing preventing your from building images with precise control over versions of your dependencies. You can do it in the image in the same way you'd do it anywhere else. Specify your own repos and use lock files, or whatever your language allows.

apeace 9y ago

You're right, I didn't make that clear. What you're missing is that the beginning of the "deploy" process is building the image on your local (or on CI). That's when the update happens. Then you test it on staging, and if all is well you deploy to production. If there's a problem it's easy to change your Dockerfile from "python:3" to "python:3.6.2" in order to go back to what you had. Or stick with "python:3.6" if you only want security patches. Or, if you want to miss out on those security patches in order to guarantee more stability, go with "python:3.6.2" and decide when to test and deploy an upgrade.

scarface74 9y ago
Are you referring to Canary Builds? https://www.thoughtworks.com/radar/techniques/canary-builds https://www.thoughtworks.com/radar/techniques/canary-builds
- apeace 9y ago
  No, I am more talking about a standard process of applying security patches (and/or bugfix patches). I'm countering the claim in the article that using containers somehow makes software orgs more prone to "unmaintained" OS's. I'm saying that has little to do with containers, and if anything containers make it a lot easier to get security updates.