Any advice/experience with development->staging->production work flow?

Events happening in the community are now at Drupal community events on www.drupal.org.
Posted by patrickavella on July 15, 2011 at 3:38pm

Hello everyone. I have a feeling I'm not the first person trying to do this, but I can't seem to find the answer I'm looking for, or at least a non intrusive solution.

The proposed work flow we'd like to use is to develop on our local machines. Push to a staging server for client and colleague viewing, then push to live/production when finished. With static sites this works great, and with git it's pretty easy with drupal except for the multisite configuration.

For example, I have "mysite.com" I'm working on. so I create /sites/mysite.com as a git submodule

I pull it down to my machine, and access it via lc.mysite.com in my hosts file (lc is shorthand we use for local)

That's fine, the fun starts when trying to stage the site. I can push it up to something like mysite.ourserver.com and just create a symlink to handle the initial staging, then I can just point the domain when it's ready to go to production. If the site is already in production there seems to be no good way to name the multisite folder. If I create a /sites/staging.mysite.com folder, while technically it'd work for most facets of the site it will break any links that aren't written without using drupal_get_path() and I try to avoid enabling php filter for any end user editable content.

I hope that explanation of what I'm doing and where it's going wrong was clear, if not I will be glad to reword again.

Are there any modules or dev configurations that help make this work? I have talked to other Drupal shops that actually DO what I've described, but I never inquired how. Any help is greatly appreciated!

Comments

ServerAlias?

Posted by iainh on July 21, 2011 at 4:12am

If the dev; staging; and production servers are on separate machines, each with it's own URL - say my.multisite.com; staging.multisite.com; and dev.multisite.com - then a multisite could live in the my.multisite.com directory on each machine thus preserving the directory naming structure everywhere including Git. If you let Apache do the work, by saying in /etc/apache2/sites-available/my.multisite.com on each machine, that ServerName is my.multisite.com with ServerAlias staging.multisite.com; and ServerAlias dev.multisite.com ..... would that work in your situation?

There again, if your site is Drupal 7, the my.multisite.com/sites.php file will do this for you per this article

Thanks!

Posted by patrickavella on July 22, 2011 at 3:10pm

Thanks for the reply iainhouston. Yes, the set up you describe does work in my situation. After a good deal of reflection it looks like I'm trying to avoid the little bit of manual work that's really not avoidable. I just need to be mindful of any paths I use and make sure they're using drupal_get_path when appropriate. I've found the custom filter module helps a good deal in controlling user land content as well. Thanks again for your feedback! - Patrick

Your Git workflow?

Posted by iainh on July 22, 2011 at 9:10pm

I don't think I was much help to you but the reason I arrived here was that I'm looking for other peoples' 'best practices' with Git as the means of managing dev; staging; and production sites and platforms. I keep each multi-site in its own repo; I keep each drupal 'platform' in its own repo and .gitignore the sites/* directories rather than include the multi sites in the drupal root version control. This fits in with my use of Aegir hosting: separating 'platforms' from 'sites'.
I rather shied from the complexity of managing the sites as Git submodules; or subtrees that Git knows about .... checking what others do.

Obviously I can't speak for

Posted by patrickavella on July 23, 2011 at 1:34am

Obviously I can't speak for anyone else, and I'm still pretty new to drupal.org and only have a year of drupal under my belt, but here are my two cents on the topic.

I use git submodules both at home and at the office. gitignore would definitely work but submodules have the distinct advantage of being 'part of' the whole repo. This shines when you're working with a team, or if you have multiple workstations you might be working from.

git clone me@repo:/core.git /home/www
git submodule init

will pull down the core as well as all of the sites stored as submodules. Adding a submodule is equally as easy.
git submodule add me@repo:/mysite.git /home/www/sites/mysite
# don't forget to commit and push

will create a an empty repo for you to fill that works like any other repo, only it will be tracked separately from core.

I'll admit that submodules were very confusing to me during my crash course with git. I assembled a list of links that helped me understand how to use git and submodules with drupal on my blog http://patrickavella.com/blog/git-drupal

Specifically
http://chrisjean.com/2009/04/20/git-submodules-adding-using-removing-and...
and
http://book.git-scm.com/5_submodules.html

I hope that's helpful.

Very useful, thanks

Posted by iainh on July 23, 2011 at 10:50pm

Oh yes, that's very reassuring and exactly the experiences I was looking for.
Thanks Patrick.

Multisite

Group organizers

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds:

AltStyle によって変換されたページ (->オリジナル) /