Blog

Alot of our clients tend to ask how we would manage sites across multiple servers or how we would maintain the code on the live site to make sure it is identical to the development environment. For our purposes, svn has served us very well and that is our general practice here for all our projects. Personally I find the interfaces (both gui and command line) to be quite intuitive. It is an invaluable tool in our development process and makes the job much easier, especially when clients request multiple deployments of the same site over different servers. The trick is maintaining the Drupal database but that in itself is a whole other post.

Installing svn on DEB based servers (ubuntu, Debian) uses this command


apt-get install subversion


while redhat servers use


yum install subversion


and the command to create the repository is simply


svnadmin create repository_name


Upgrading from Drupal 5.x to Drupal 6.x can be painful, but not as painful as upgrading from Drupal 4.x to Drupal 6.x. This is a 3 part blog series to guide you through the upgrade process from Drupal 4.x to Drupal 6.x.

Upgrading from Drupal 4 to Drupal 6 cannot be done in 1 step. You have to upgrade your current Drupal 4 and contributed modules to the latest versions, and only after this from Drupal 4.x to Drupal 5.x and then from Drupal 5.x to Drupal 6.x. Moreover, there are plenty of sub-steps that have to be implemented during each of these two big upgrades. The reason for this is that you are not only updating your Drupal site's code, but, the most importantly - the database. The more contributed modules you use, the more steps you are going to have. The database tables structure may have changed several times from one module's version to another. It is very important that these changes are done in some particular order, especially if you have lots of dependencies between them. So, the longer you wait - the more painful upgrade is going to be.

Just on my third week at work and yet I am already neck deep in Drupal development. I work in a project group with 2, sometimes 3 other members and BELIEVE me... svn is keeping us all sane. Granted it takes a little bit of finesse and patience to micro-manage the database scripts to activate a module,set a menu item, or import node types programatically but it ENSURES uniform databases across multiple platforms... this is vital if you have more than one person working on a site, that way I can work locally, write scripts to any changes I make, pass it to the rest of the team, they run it and boom, we're all on the same page. It is poetry in motion if executed correctly...

That being said, the only real problem we have run into is working with the Location module, it allows users to automatically add address fields (street,city,zip, etc.) but we have not been able to find a way to activate the functions or set its fields through a sql script... I guess solving these types of problems is what a developer lives for right?

Tortoise for the win ;)