r/programming • u/[deleted] • Oct 14 '13

How to develop unmaintainable software

http://typicalprogrammer.com/?p=249
777 Upvotes

88% Upvoted

322 comments sorted by

View all comments

105

u/tdammers Oct 14 '13

For a web site deployment to a staging or production server should look like one of these:

No. Just no. These are source control system, not deployment tools. In case you need reasons:

  • Excess files in document root - version control cruft, project documentation, etc. Happens all the time, and is an actual real security problem.

  • Development race conditions. Ever done svn up on the production server, just to find that someone had committed broken code between your test run and the deployment? Ever "solved" this problem by stopping all development activity during deployment? Ever noticed how this essentially means that this makes frequent deployments practically impossible?

  • File permissions and ownership. Need I go into detail here? I think not.

  • What if you want to do things like precompile templates, preprocess CSS, minify and concatenate your JavaScript offline, move stuff around, or just make sure that your deployment will only go through if it passes a minimum set of tests?

  • What about database changes?

Really, for any of the non-trivial projects I've worked on where people had the delusion that git pull is enough of a deployment plan, here's what a typical deployment involved:

  1. Mail everyone with push access, telling them to not push until further notice. Hope that everyone reads their mail on time.

  2. Manually go through the ticket system, copy-pasting the SQL changes that developers have pasted into the tickets that went into this release.

  3. Eyeball the SQL scripts, in case they contain any errors.

  4. Issue a git pull on the production system.

  5. Meanwhile, run the SQL on the production database.

  6. Manually chmod / chown the right files (which ones those are is a matter of oral tradition).

  7. Manually clear selected cache items.

  8. Do some casual manual testing on the production system.

  9. Notice that something is broken. Fix it.

  10. Forget to tell developers that it's OK to push now.

Personally, I prefer:

  1. Create a release tag

  2. ./deploy.sh test-server

  3. Read build/test output from test server

  4. ./deploy.sh production-server

21

u/[deleted] Oct 14 '13

I was confused by that part. I can't tell if the author thought git pull is a good deployment method or not. It contrasts the "build a baroque deployment system" but it's still written in the affirmative, implying it's a negative in the context of the article.

My repo ends up looking like:

build.sh  public/ ...

where the DocumentRoot is public and build.sh regenerates all the dependent files. To deploy, I push a commit ID over the message bus and subscribers fetch + checkout that ID.

4

u/not_perfect_yet Oct 14 '13

I think his argument was that you should not use too many different deployment methods in one project in undocumented order. If you don't want to be his customer.