slate blog

I have to be honest – the upgrade to version 0.4.0 of slate last night did not go very smoothly. I ran into a number of odd issues and in the end, it two nearly two hours to iron everything out.

One thing that did go smoothly was the database migration. This has always been a scary point for me, because we use SQLite3 for development, and SQL Server for production. Thus, from time to time there are pieces of SQL code that don’t work quite the same in both databases. But this time, I planned ahead: I created a staging database in SQL Server, which was a copy of the production database, and ran the migrations. I had a number of failures that aborted rake and caused a big mess, so I had to repeat the process multiple times. I did all this last week, to help reduce the stress of deployment. And for this task, it worked: the migration went perfectly. Unfortunately, the migration was about the only thing that went smoothly.

Version 0.4.0 touched on a large number of features, one of these being Resources (now called Files), our name for user-uploaded files. In v0.4.0, the paths and actual filenames for all Files changed, which I handled via two rake tasks. However, the task for file renaming bombed when it saw one of those “Thumbs.db” files, so I had to run it again. But the logic for renaming wasn’t perfect, and ended up removing a critical piece of the filename for a number of files. I was able to resolve the issue, but I wanted to kick myself for the poor testing.

The next issue was SQL related, and it dealt with a LIKE condition. Apparently, SQL Server expects the pattern to be in single quotes, not double quotes. So, ... WHERE filename LIKE "%.png" ended up failing with the always helpful “Invalid syntax near LIKE” error.

The final big issue actually had to do with TEH. When I performed the svn switch, I forgot to run an update on the externals. As a result, the new helpers introduced in TEH v0.2 were not available, and that resulted in 500s. Of course, the two places where TEH are used have ”;edit” in the URL, so I initially thought that mod_proxy or something else related to Apache was throwing up when it saw the semi-colon in the URL. Thankfully, that was not the case, and a simple svn update on the TEH external and rake textile_editor_helper:install fixed the issue.

Perhaps I was a bit optimistic regarding depolyment this time, but I assumed that the migration piece was going to be the biggest headache. And truthfully, it would have been if I hadn’t tested it the week before. Really, the biggest issue is just that deployment involves a major platform jump: from OS X/SQLite3 to W2K/SQL Server.

Yes, deployment is definitely a pain, and it all basically falls on me. *Sigh* I really need a raise.