@TheKeyboard Always code as if the person who ends up maintaining your code is a violent psychopath who knows where you live.

A co-worker of mine always complains that people don’t read the RFC that covers a topic related to making their own stuff work with our stuff. He’s old sk00l like that. Although my co-worker is a tad out-of-touch with the realities of programming these days (as in the amount of people who actually read the RFC when they can simply use someone else’s library / module / function / application is very small), I thought I would at least adhere to some semblance of standards and do a blog posting about my plans for making CakePHP application deployment easier.

While I really prefer to use tools like this for deployment, I understand that not everyone wants to mess with standalone programs and configuration files. I’ve been asked before about Cake-specific deployment techniques, so I figure the easiest way is to see about adding a task to the Cake console. Let’s call this ‘cake deploy’.

As I explained on the mailing list I am looking for opinions on what sort of things should be part of the ‘cake deploy’ task. Right now, my thoughts are as follows:

• cake deploy config

- setup and edit configuration parameters. Initially I thought of setting things like transport method (ssh, ftp), logins and passwords, remote location, source directory, and destination directory. The configuration file would be stored locally in APP/config

• cake deploy - seems pretty self-explanatory to me.

In the RFC thread on the CakePHP mailing list, someone mentioned they’d like to see rsync, but I’m trying to avoid having to external programs required to make the deployment work. Or, at least, use as few as possible. Anyhow, if you have any thoughts on this feel free to add them to the comments.

One of the 6 “rules” I came up with for my talk on application deployment at Open Web Vancouver was that the only difference between your development environment and your production environment should be data sets. My friend Juan, who works as the software architect at the adult dating site I used to work for, talked with me via IM about how that rule isn’t always true.

A little background on this is necessary. They are still using the same development setup today that was in place when I was there, in that they have given each developer a server that uses jails (this is a FreeBSD thing) to simulate having all the servers they would have in production. A great solution, one that is still great today. It made writing architecture-specific code (i.e. testing that an application server could talk to a queue processing server for a specific task) very simple. So, in this case I believe that they had a development environment that matches production as closely as you can get.

But then Juan mentioned that they are using Zend Platform on their production servers, and it wasn’t possible to give everyone a copy of Zend Platform on their development servers due to licensing. While Zend Platform is a great product, well, you’ve just introduced an extra variable into your application development and deployment process. Now, your development environment will never be the same as production and you are increasing the likelihood that you will encounter “production-only” bugs, which are the hardest to solve.

I have great respect for Juan (he’s near the top of my list of the smartest developers I’ve worked with), but rule #5 still the best one to follow. While you gain from using something like Zend Platform in production because of all the extras you get, you end up with a development environment very far from what is using in production. Just make sure that you understand the implications of that decision.

Also, there is something else hidden inside rule #5. If you have differences between environments, make sure you understand what those differences are and take steps to minimize their impact. For example, I run Apache2 + PHP 5.2.5 compiled from source + Postgres 8.25 from a package for OS-X & MySQL 5.0.45 from a package for OS-X on my laptop, which is my main development environment. On my VPS (which hosts this blog) I’m running Nginx + PHP 5.2.5 modified under Gentoo with USE flags + MySQL 5.0.54 under Gentoo. So, that means I’m running mod_php on my dev, but using FastCGI on my “production”.

Has this been a problem? Nothing yet *but* if I ever got serious about running something other than my blog I would definitely consider configuring my VPS to use Apache 2 and PHP with the same configuration options as I have in dev, so that I have consistency in environments. Django is recommending Apache + mod_python so I may be doing this sooner rather than later.

So, remember, the goal is to have your dev and production environments the same. But if you can’t have the same, you better be damn sure you understand what the differences are so you don’t end up saying stuff like this.

I managed to make a screencast of the second talk I gave at Open Web Vancouver 2008 about application deployment. I had hoped to make a screencast of my CakePHP console talk, but I messed something up at my end and all I have is the audio from it. Not the best thing when you are doing a demo. However, the conference was also recording talks so hopefully they will have a copy of it for you to see as well.

The talk was well-attended, which is a nice boost for the ego and although I spoke too fast (as usual) I think I got all my points across quite nicely.

Get the latest Flash Player to see this player.

I was going to do a rant today in honour of April Fools’ day, talking about how much it frustrates me to no end that people prefer complicated explanations for their bugs:

Them: “I notice that module X is no longer working when I moved from BloatOS to TinyNX, and my framistat widget is now displaying stars instead of being in plain-text. Why is the component doing that?”
Me: “Dude, that component doesn’t just magically stop working because you’re on TinyNX. Are you using the same version of FooWorks in both environments?”
Them: “I think so.”
Me: “Don’t f*****g THINK so, MAKE SURE”.
Them “But it was working just fine…”
Me: “SILENCE! I’ll bet you the balance in my savings account that you are using the star framistat widget on TinyNX and the two code bases aren’t the same”
Them: “Oh, will you look at that…somehow an older intermediate version of the code using the star widget was deployed on the TinyNX version”
Me: “You owe me lunch”

People, people, people. Weird problems almost ALWAYS have a simple solution. But enough about how smart I think I am, back on topic.

I’ve started working on my presentation I’m giving in two weeks. Oh, don’t worry, I know what I’m going to say but I just need to create the slides that results from it. Part of the presentation is pointing out some deployment horror stories and how they could’ve been avoided. If you can swallow your pride and share some of those stories with me, I’d appreciate it. I will start off with one of my own.

Back when I used to work for an adult dating website, we built a database abstraction class that passed all data modification statements to our master database server…via HTTP. Yes, we wrote code that listened for a string to be sent to it and then executed the code on the server. I don’t have the time or the patience to explain how this decision was made, but there it was. We were lead to believe that MySQL replication at the time (this is 5 years ago) was in ‘milliseconds’ so we thought we were okay dealing with the very large number of updates that would happen to the master, and then being replicated to the 7 to 8 application servers we had running at the time.

That was until we found out that replication is slow, and some machines were up to 30 minutes behind on processing the replication requests. Holy shit.

The solution was to decide what requests could be done later, and creating a queuing system for processing those delayed requests. Apparently this same system is in place today, despite the current software architect’s desire for switching things to a clustering or sharding scenario for the data. Since the site is so dependent on people signing up for paid accounts, nothing is allowed to be done that can disrupt the site when deploying changes. Best of luck with that.