I'm about to embark on a new project for a client with an existing 6.x site. For the most part, this project entails building out a significant new chunk of site -- new content types, views, content, etc. As such, I'm wondering what the current thinking is on how best to approach moving that sort of project through the development lifecycle. Ideally, of course, dev would happen on a dev server, test on preview, deploy to production. Is there any way you've found sane to approach moving what is largely content data from environment to environment like that? Alternatively, how do you like to approach developing something like this on a production instance (heavy use of roles to keep things hidden away, etc.?)?
Thanks! I appreciate any insights you can provide.
-Brant
Comments
When I first started I just
When I first started I just backed up all the sites/ files and did a mysqldump and used that to push from dev to production. I didn't have a test/preview/UAT server.
I ran into a lot of problems with the FQDN and usage of multi site configuration. So now I don't use multi sites
It depends
Hey Brant. I offer the classic consultant's answer of… it depends. :) Depending on the amount of traffic, the extent of how dynamic content is, and other factors, will determine whether I'll have a public-facing dev/production setup (I always have a local copy for testing upgrades) and the migration of data.
I remain a huge fan of Backup and Migrate, which greatly facilitates these chores. As for keeping dev material from unauthorized access, it's a rather simple use of Drupal's authentication to require login to any page, even if I offer a single login for non-community-type sites. I haven't tried using apache authentication, but that would offer the advantage of not having to change the authentication settings after doing a content move after development and testing.
Thanks
Thanks for the comments, guys. I figured it might be too much to hope for a mechanism to make the content "transfer" problem smooth -- it's just kinda messy. We'll likely just try and use roles to restrict access to the new section during development.