A deployment I don’t have to be there for
When someone orders a change to their system from me, sooner or later a question comes up that has nothing to do with programming: so when will it actually be live?
For years there was only one answer — in the evening, once nobody’s working. I connect to the server, shut the application down, upload the new files, start it back up, and hope. If something goes wrong, I’m sorting it out at midnight. And if it goes wrong in a way nobody notices right away, the accountant finds out in the morning.
This week I finished something for one client that does away with the nighttime part. It’s already running this way on the test system.
The application packed into a container
The basis of it is that the application isn’t uploaded file by file. It’s packed whole into a container — a single package holding absolutely everything it needs to run: the program, the settings, and the system it runs on. That package can’t be changed. Once something has been sealed inside, nobody overwrites it, so it runs on my computer exactly the same as on the server. Docker takes care of that, and these days it’s a completely ordinary thing in the server world.
On the server, a small program then keeps watch for a newer version arriving. When one does, it sets the old one aside, starts the new one, and that’s it. It takes a few seconds, and I don’t have to be there.
Test first, live only after
And here’s the part that gives me the nerve to let this loose on someone else’s business.
This client has two copies of the system running. One for testing, where we try everything out, and one live, where people actually do their work. A change always goes to the test copy first.
Once it’s approved, nothing gets packaged again. What goes live is exactly the same container that was standing on the test copy. Not a new one, rebuilt from the same recipe — the same one.
Sounds like nitpicking. It isn’t. If it were packaged again, a newer version of one of the components the application is assembled from might have come out in the meantime. It would look the same and behave almost the same — and that “almost” is exactly the word that has someone spending two days working out why the live system behaves differently from the test one.
A pastry chef doesn’t bake the customer a new cake from the same recipe either. They send the one the customer came in to taste.
What the client gets out of it
Changes come through faster, because going live is no longer an event that has to be scheduled for the evening. What goes live is what was tested, not something that resembles it.
And if it still turns out that the new version is worse than the last one, going back is a matter of a minute — the previous container hasn’t gone anywhere; you just say that it should be the one running again.
That last part, by the way, is where the courage comes from. Not that nothing ever goes wrong. But that it can be undone before anyone notices.