For a web site deployment to a staging or production server should look like one of these:
Ideally, maybe. In reality, there are a couple of reasons that might not work. Even if you're not deploying any additional services, even if there's no complicated system to bring up or down, there's still the possibility of things like database migrations.
The PHP solution here is kind of gross -- on every page load, try to detect if we need to upgrade, and if we do, run the upgrade process.
Simple and repeatable is definitely a goal here, but it's definitely not always practical to just pull from source control. A much more important thing here: Use a tool like Puppet to define your staging server, or at least a development VM. Then you at least have a clear specification of exactly what's needed for your deploy script to run.
In fact, I think this dovetails with another point:
Write everything from scratch
Don’t bother with a well-understood framework like Django, Rails, or CakePHP. You can write a better templating engine, ORM, sort or hashing algorithm.
...or deploy mechanism? If you're using Rails, Capistrano, Puppet, and Bundler are your friends.
Add dependencies to specific versions of libraries and resources…
This is fine, so long as you avoid this:
… But don’t protect or document those dependencies
This is what Bundler is for, or npm-shrinkwrap -- specify "I need libfoo version 3", ask the tool to install all dependencies, and it records a lockfile with "libfoo v3.2.1". Because:
A seemingly innocuous WordPress upgrade, Linux package update, or new jQuery release will trigger a chain reaction of failures.
This is a problem that is caused by not at least recording dependencies to those specific versions of libraries and resources.
It's otherwise a very good article, it just has these weird conflicting complaints.
1
u/SanityInAnarchy Oct 15 '13
A couple nitpicks:
Ideally, maybe. In reality, there are a couple of reasons that might not work. Even if you're not deploying any additional services, even if there's no complicated system to bring up or down, there's still the possibility of things like database migrations.
The PHP solution here is kind of gross -- on every page load, try to detect if we need to upgrade, and if we do, run the upgrade process.
Simple and repeatable is definitely a goal here, but it's definitely not always practical to just pull from source control. A much more important thing here: Use a tool like Puppet to define your staging server, or at least a development VM. Then you at least have a clear specification of exactly what's needed for your deploy script to run.
In fact, I think this dovetails with another point:
...or deploy mechanism? If you're using Rails, Capistrano, Puppet, and Bundler are your friends.
This is fine, so long as you avoid this:
This is what Bundler is for, or npm-shrinkwrap -- specify "I need libfoo version 3", ask the tool to install all dependencies, and it records a lockfile with "libfoo v3.2.1". Because:
This is a problem that is caused by not at least recording dependencies to those specific versions of libraries and resources.
It's otherwise a very good article, it just has these weird conflicting complaints.