I’ve worked jobs with websites that are manually sent to the server by FTP, and I’ve worked with sites that are pushed up with a single command line call. Guess which ones I enjoyed more?
Let’s back up a minute. Websites are, at their core, a collection of files on a web server (yes, often many servers. Work with me here.) In my experience, there are a few common ways to make updates to a site:
- Editing files directly on the server. Here we’re connecting through ssh, telnet, Remote Desktop, tin cans and string, and what have you, and just editing the files live on the server. If you make a typo the site crashes. If there’s database work, it’s connecting to your live database, and somehow your odds of, say, forgetting a Where clause in an update or delete statement get astronomically higher in these cases. Yeah, ask me how I know this…
- Editing files locally, and then replacing the server files with an FTP upload. In this case, you’re trying stuff out on a different computer. Ideally you’ve got a development environment set up so server-side code actually executes, and you’ve got a local database that’s either a clone of your production data or filled with test data (yes, that actually matters in some privacy circles,) so you can make mistakes to your heart’s content. When you’re done, you upload the changed files. Assuming you don’t forget any, of course… This is the level where source control becomes a lot more possible, but there’s still a danger of regressing to step 1 from time to time and losing sync with the live code (I’ve worked in places where “grab it from the server before you edit” was a best practice, but we’ve got better options than that, see below…)
- Editing files locally, uploading a whole new version of the site, then switching over to that version. Here we gain a little protection against missing a file, combined with the bonus that you can get the whole site uploaded (for larger sites, this can take a while) and then a near-atomic action to flip the site over to the new version (renaming the root folder, repointing the web server’s root folder, etc.) If you’ve got any folders that have special permissions (like making them writable) you’ll have to remember to change those too, but now we’re getting to a level where you can write the instructions down in a way that a reasonably trained infant could follow.
- Automated deployment. In this version, you’re taking what you do in option 3 and automating the whole thing down to a single command or button click or whatever. The deployment is ideally based on what’s in your source control system so you know it’s a version you can recreate (and more importantly, roll back to) if needed, and any “magic steps” are baked into the scripts so there’s considerably less room for human error.
True confessions: did I say I’ve worked at jobs with each of these practices? A more accurate way to describe it would be that I instituted each of these practices. “It was the style at the time” doesn’t quite cover for my eternal shame.
For automated deployment, Capistrano remains my favourite tool of the moment. I’ve written my own systems, but the thing of it is, most deployments are pretty much the same, and someone else has likely had that “weird situation” that you think you have to deal with, so a solution likely already exists.
Capistrano isn’t just for Ruby on Rails, by the way. Here’s someone’s description of a PHP setup, and here are some tips for ASP.NET.
Basically, it boils down to this: as a client, would you rather pay someone an hourly rate to perform an arcane series of commands that go wrong 30% of the time, or have them type “cap deploy” and get on with the stuff that makes you money? As a programmer, would you rather be on the hook for the downtime caused by a typo or two and endure the stress that comes with each deployment (typically making them further apart and more complicated) or, again, type “cap deploy” and get on with the stuff you can actually feel good about doing that got you into this line of work in the first place?
So the impetus/object lesson for today’s post: I just took on an “emergency rescue” gig to help a CakePHP project that had somewhere in the neighbourhood of 50 to 100K lines of code in it, spanning 50 models, 40 controllers, and so on, and it took about 5 hours to get something working on my development machine. If it didn’t have a Capistrano script already in place and proven I would have had to either walk away from the job or spend another day or two learning the guts of the app so I could do an appropriate level of post-deployment testing. There wasn’t any good way to tell if a glitch was just on my machine or if it was in the production version too (duplicating the error would have had noticeable impact on the site’s users in some cases.)
Thankfully, the build script was working and proven, so I could focus on making just the changes I needed to make and have reasonable confidence that they would be the only changes to the production system after they got pushed out.
For some programmers, a complicated deployment process might imbue a certain amount of job security, but I’m hoping that word’ll get around to clients everywhere that it doesn’t have to be this way. There’s a small up-front cost with getting the process in place, but this pays for itself incredibly fast and lets everybody do the job they’re best at with minimal potential for damage to the website’s users.
(And if you’ve got a project that you’d like automated, I’m available for consultation…)
