In Demolition Man (1993), John Spartan is frozen for decades only to be thawed to fight a familiar enemy in an unfamiliar world; where every bathroom has three shells and Taco Bell is the only restaurant left in America.
In software development, regular maintenance costs a lot of time, so we “freeze” apps all the time to prevent the changing world from breaking our precious apps without thinking about the consequences what happens if we ever have to unfreeze them. It like taking all the maintenance headaches, packing them into a can, and kicking it out of sight, probably down a road.
But it’s impossible to completely freeze your dependencies. The world keeps turning. Packages disappear from repositories. Providers drop support for old versions of MySQL. The Internet drops support TLS v1.0. Browsers drop non-HTTPS traffic. CentOS disappears. Mexican pizza is no longer on the menu. The better job you did at locking up your project, the worse of a time you’ll have if you ever have when you have to bring it back out.
Taco Bell Future
The feeling of dread you get picking up an old project. Many things will have changed since you last touched it. It may live in a crazy world where Taco Bell is now the only restaurant.
I have to update this old jQuery site, I don’t know what kind of Taco Bell Future I’ll have to deal with
For production apps, you’ll have to do some degree of freezing. Here are various techniques for freezing your apps:
- Pin versions – Pretty standard. Tools for maintaining dependencies are constantly getting better.
- Own all your dependencies – Vendor everything and/or maintain a private artifact repository. Good luck.
- Dockerfile/AMIs – Freeze your whole OS + app as one artifact
- Static sites – The best! You can host your project anywhere. You better hope you never have to thaw it out though, if it’s even possible. Also not viable for most apps.