All Drupal developers have experienced this nightmare. You have been creating a great project, now it’s time to deploy it. No one wants to deal with it. No one wants to be the responsible of doing it.
If you are building a simple site, and there’s only a one time deployment, it’s not a big deal. You just have to follow the largely discussed and know simple rules.
The Rules:
Use SVN (or CVS) to keep your code updated among the developers
Deploy to production by backing up/restoring the database
Create scripts to make the deployment process automatic
That’s all, the unique problem you could have is maybe that you will have to delete the test content/users and change some settings before going live, but in summary, it’s pretty easy.
When it’s about deploying code, it’s still easy to do if you followed the simple rules. You will have only to update your SVN branch and you are done.
When the nightmare begins?
The problem is deploying changes made in the CMS, but without wiping all the existing data. In other words, merging the database changes, the settings and content stored in the database.
Scenario 1: Big (or huge) Drupal projects
You have to deploy a project in multiple phases. So while the first phase is deployed and working in production, you have a bunch of developers working on the next phase (this means, implementing new code, creating new nodes, creating new views, editing existing ones, changing settings, users, permissions, etc.)
Once again, another open source project has dropped Concurrent Versions System (CVS) for Subversion (SVN). Both CVS and SVN are open source version control systems used mainly by developers involved in various software projects. This time the project is phpBB, a forum application.
We like to announce the switch from CVS to SVN for our repository
management and source control. Within this step, we also set up a new
home for phpBB development and phpBB related projects. At the moment
only phpBB itself is listed and only repository management handled
there. Within the next months we will enable more and more features and
move internal projects as well as hopefully other public projects to
the new home. [Link]
Although I'm not much of a developer, I've been interested for some time in why a project has picked one version control system over another. In part this is because I recognize revision control is something my own employer need to do better, not just for the larger projects but even the "local" non-enterprise projects I often found myself involved in.
Except for some Python programming, I've done very little software development this decade with most of my efforts in the 80's and 90's (BASIC, Pascal, Perl, Tcl, etc). Those that know me know I've wanted to dig more into PHP and Ruby, but I have been distracted by one sorry excuse after another.
For work and my status as a Drupal Developer Wannabe I've also been making the effort to learn more about revision control. One issue I have is that at work the consensus has been to use Subversion for version control while the Drupal community prefers CVS. It shouldn't be too difficult to master both version control systems, but for whatever reason my brain cells in that department haven't switched on.
Luckily, I just came across a nice how-to tutorial by Nick Sergeant (first time I've come across his name too).
After reading the Pro Drupal Development
book, and becoming a recent Subversion junkie, I’ve learned to do all
of my Drupal and Contributed Module management through a combination of
CVS and Subversion.
Through this post, I’m going to attempt to take you through all of
the steps of managing your Drupal installation as well as any
contributed modules you may need to utilize.
The tutorial is called, Painless Drupal revision control with CVS and Subversion. This how-to by Nick Sergeant should be a big help for the Drupal Developer Wannabe that would like to or needs to do their work in Subversion and not CVS. As I'm no expert, if you see any corrections that need to be made to the tutorial, please leave a comment over at Nick's blog.
I spend too much time sticking my nose where it likely doesn't belong. Check out Dries comments toward the Drupal project using CVS and my own comments somewhere below his. I argue that SVN is the correct choice. I'm unqualified to really know the answer. Sort of like me telling Bill Gates that dropping the current Windows code and starting something new would be better for Microsoft in the long run.
"Technologies are changing so quickly around us that it's hard to find and integrate good software before its replacement has gone mainstream. For this reason, I'm always on the prowl for what's new and hot.
A couple days ago, I was checking up on the status of Wordpress 2.1, which is supposed to have exciting new features like pseudo cron and spell checking. I came across Wordpress's defect/feature management system, Trac. Just to be clear, Wordpress isn't the author of Trac."
No surprise, yet still of interest. The Ruby Language project is officially dropping their CVS and fully using SVN for version control. I only wish one of my favorite open source projects would just start the move from CVS to SVN.
CVS services (including CVSup and CVSweb) will be permanently unavailable on Fri Mar 16 03:00 UTC 2007. The source code repositry has been moved to SVN.
If you require the CVS repositry, please get it by CVSup till that day.
You can access the original post at Ruby-Lang.org by clicking here.
Congratulations to the Ruby language folks for converting their CVS repository over to Subversion (SVN). From what the "experts" tell me, it is not easy moving your developers over to another version control system. At least that's what was hinted when I asked the question, CVS or Subversion?
The difficulty of moving a project to a different version control system likely has just as much to do with cultural issues as it does with technical issues. To ask a developer to use a version control system when they never have used a version control system before is difficult enough. To ask a developer to spend a day or two to learn a new version control system over the one they're currently using is three times more difficult.
For the organization that I work for, we've settled on SVN. A lot of the developers in our field offices are used to programming alone, thus most of then have never used a version control system. I believe we'll find SVN is the right choice for the new projects we're starting up.