Posted by mattman-gdo on January 8, 2009 at 6:52am
Hey there fellow Drupaleros,
I'm seeking peer review of my video about my CVS/SVN workflow regarding deployment for a multisite setup. I'd learned about vendor branching and svn:externals a few months ago and finally got around to setting up a system I was happy with.
What I'm wondering is if I could do anything better or how other people are doing similar things, but slightly different.
All feedback is welcome, leave comments on the site or email me via gdo.
Comments
Great!
If you're consistently using the same set of modules, it's worth it to make a super basic install profile that just includes those modules and turns them on by default.
They then go in a profiles/profilename/modules directory, which you can also keep at the higher level and just svn:external profiles/profilename.
I'm not a fan of putting stuff in sites/all ... but that's likely because I use install profiles a lot. Again, if you do the separate "modules" folder, you can again svn:external into profiles/profilename/modules and even do DIFFERENT install profiles, with a mix of modules.
An install profile could be as simple as an array listing enabled modules. Your DB dump of a fresh install will become stale every single time any one of the modules and/or core gets updated, so the limited up front work of making a simple install profile is probably worth it.
Hmmm...could you do "local" svn:externals rather than 4 separate repos? Most people won't run their own repos, but rather something like http://unfuddle.com, where multiple repos might cost money.
Damn you, now I need to go reboot my layout ... this is great, and the first real big change that makes sense since I first did our layout: https://svn.bryght.com/dev/browser/bryghtbase
Pretty much the only thing I would include is a pointer that you actually create and maintain a "patches" directory. Remember, it's not a hack unless you don't submit the patch...
About the stale database issue
Regarding...
In all honesty, I've not spent enough time to fully investigate profiles. My solution to the stale database issue was something that I didn't include in the video. However, I do have a system for this. The dump to the database folder is only for development and not for the release of new sites. In my real setup, one of my sites is simply called "base". An example would be base.gotdrupal.com. This is a base install of the database and is secured behind realm authentication and ip access limitations.
I consider it my newsite database. I run it just like a normal site with all desired default modules activated. When modules or core are updated, I simply do the update on this site to bring my base database up in line with the code.
The advantage I have found with this approach is it allows me to "evolve" my base database by performing tweaks to the "base database" for any new site. This seems to prevent me from having to do those same tweaks which I'm assuming drupal profiles don't support.
A simple
mysqldump drupal_base_database | mysql newsite_databasegets me going quickly with the database end of things.The process is actually scripted for the server, but it essentially happens like this 1) uncompresses newsite.tgz, 2) renames newsite based on the supplied argument to the script (typically domain.com), 3) strips the .com, dumps from the "base database" into the new database, 4) copies a settings.php file into the site folder and you're almost ready to go with a new site in seconds. All I do beyond that is MySQL user/permissions, DNS and Apache setup - and even that can be automated as you know.
Again, I'll need to learn more about profiles to fully understand how they can be leveraged, but this is how I'm doing things currently.
I like the idea of "local" svn:externals (essentially a self referencing repo - if externals support that - which I don't see why they wouldn't).
Re: using /sites/all - I consider this my "core modules" location and it includes modules which typically ALWAYS end up getting activated. For other site specific modules I don't mind a small bit of replication if you use one module in more than one site. I'm also thinking about a second modules repo where they would be symlinked into individual sites. However, this would add yet another repo where I would have the repo "base modules" (included into /sites/all) and "optional modules" (symlinked into individual sites as needed).
All stuff to think about, but I'm glad you liked the setup!
GotDrupal.com
Sharing what I know via Drupal Videos
directory structure
Hi, I think your videos are excellent, with a patient pace. The thing about this video is that it points to specific folder tree structure on both local stations and remote live sites and this part is somewhat clear but I haven't yet delved into it and paused the video to set up the folders.
What's not clear to me is why have the sym links although you explain it, it just seems like a major deviation from a normal setup. So, until I attempt it, it's just one more thing to keep abreast of and I wonder if others will readily understand the structure.
Unless I understand it wrong, the entire setup must originate with a CVS version to begin with rather than a non CVS original base install.
At the end of the video I felt I was missing some further information which you claim the video is too short for, so I'm wondering what's missing for me to actually delve into this. Currently I'm confused about how a local setup can use the same MySQL DB and how to manage the username of the DB since cPanel which is what I have remote, automatically adds a cPanel prefix to a username. Anyhow, so many questions, so little time.