Posted by lrosete on February 22, 2011 at 3:49am
Hello Guys,
Just want to pick your brains on what you think is the best way to Develop in Drupal, just a simple direct one though.
Right now, I think I prefer a "multisite" install of the dev and, eventually, the production site.
And I think I prefer them to have their own separate databases.
My question is, is there a way to copy the dev database directly to a production one, after I finish development phase, for example? And just add some settings somewhere on a "settings" file? (sound familiar anyone :)
I'm just looking for some practical shortcuts that I can do from dev to production, I guess.
What do you think? Anyway, any similar suggestions would be appreciated.
Thanks in advance.
Comments
My question is, is there a
I use Backup and Migrate para ma-migrate yun DEV settings ko to PROD. Very easy to use and you can use this module too to backup PROD data. Pag na-migrate na, configure as necessary (ie. settings.php, file/folder access)
As for my DEV environment, I have multiple DEV sites but they do not share the same codebase (i.e. /var/www/site1, /var/www/site2, etc). I find it easy kasi to just tar the whole site and deploy to prod without worrying anything going out that is not related...
Pag meron ako bagong dev site, I just add a .conf sa /etc/apache2/sites-available, configure as necessary then refresh apache:
sudo a2ensite <new_site.conf>thensudo /etc/init.d/apache2 reload. Then siempre, edit mo din ang host file (/etc/hosts). Just add the new site and point it to 127.0.0.1 (e.g.newsite.local 127.0.0.1 # This is a dev site)(My first post! Uyeah!)
Thanks!
Thanks!
The thing here that I tend to
The thing here that I tend to do is use two parts, one is revision control. I use Git. Committing changes, and tagging releases is vital for building a history in your project. Also it will help you if ever you decide to add members onto the project. Think about tracking Feature Modules and Custom modules individually from the whole project as well as tracking the theme on its own repo.
For the Site / database i use aegir to help in facilitation of workflow. In aegir you can setup a Dev, Stage, Workflow. Dev should be where all the work takes place, you use stage to test your changes against the live site data, then you can roll live into the new platform. It may be a bit more involved than you had imagined, but the benefit of doing it this way is your site will not be down and aegir handles all of the database movement for you. Write all of your changes to views / content, contexts, into code or modules. This allows you to track it easier, it also makes it easier to recover from unrecoverable database issues.
This sounds really great and
This sounds really great and I would really want to try this out. Do you have any recommended tutorials can I can easily follow? It would be really nice to have a good system of development in Drupal. Thanks for your help!
There is not an official
There is not an official tutorial, but here is how i set it up:
Setting up Git Local / Repo - Setup a local git repo as well as a remote one that your team can log into. You should be working on something similar to Tags, like modules do on the d.o site. Branching off of master for hot fixes / new updates to features / module.
Setting up aegir: http://community.aegirproject.org/ is the place to get all the aegir related tutorials. Once you get Aegir installed create a Feature Server site using mig5's make file: http://developmentseed.org/blog/2009/sep/03/5-minute-feature-server (Good Explanation of what it is ), https://github.com/mig5/feature_server (This is your makefile). Set up a basic team layout for your needs.
Now each Module, Feature, etc has an Update XML, make sure your custom ones point to your feature server. You can also set it up to use your Git Repo, or manually upload your features. This can be a time saver. Just Like d.o you can set versions of a feature / module as recommended. When you use drush make to build your stage, it will pull the latest recommended versions(unless otherwise stated in your .make file). You can also keep this drush make file inside of a git repo if you want to keep revision history on it.
platforms/client_name/site_name-(Drupal Version).x-(Revision of Makefile)
platforms/bobs_bacon/bobs_bacon.com-6.x-1.0 < This is our live version of the site
platforms/bobs_bacon/bobs_bacon.com-6.x-1.1-alpha < This would be a dev version of the site
platforms/bobs_bacon/bobs_bacon.com-6.x-1.1 < This would be created from drush make, then we would stage a clone of live on it. Once confirmed as working, we would migrate live to the new platform, archive the old, then remove it from the system. Aegir handles migration of the files dir, site special themes, features, and database. If it fails to migrate it will roll the site back to the previous version.
The flow starts working pretty smooth quickly, and also allows you to copy / demo the site as quickly as 5 - 10 minutes. Handy for a client that changes their mind a lot. Additionally if you do a perticular sort of site often then you can setup starter platforms / make files to begin early stage work.
Let me now if this has helped and makes sense.
This is GOLD! Thanks for
This is GOLD! Thanks for sharing your setup. Honestly though, this looks quite lengthy so I printed it so I can start digesting. So now I'm staring at what looks like a one-page "course outline", and I have made five deep breaths already, at least :-) Anyway, kidding aside, I will start setting this up as soon as I can (... there goes my freetime/weekends). Honestly, this makes only a bit sense for now, but I'm very sure your guideline will help me in my learning (and I'm quite optimistic that I can complete this successfully, cross-fingers). My plan right now is to start off with setting up GIT and just go from there. Just one question for now though, what's a "d.o site"? Just want to make sure that I know what you are talking about from the start. Sorry about that, my Drupal background is quite limited to my 2 yr old D6 site which I haven't really managed regularly because of my "day job" doing some "development" on something else :-) Although I have experience in creating a Drupal custom theme which I believe made good use of the Drupal Admin (Plus reading Drupal books, watching videos, etc). Anyway, I'll get back to you on this for sure, after I manage to get a dent on this. I can't wait to learn how to do this. Thanks again.
SOrry D.o is my shorthand for
SOrry D.o is my shorthand for Drupal.org, i was mentioning how projects (modules/themes ) work there, basically thats how the Feature server works. It could take a bit to get setup and may be overkill for one man, but even for my personal needs i have found it has mad servicing my clients easier. There is a lot of setup at the front end, but the long-tail advantages are there.
Oh ok, thanks for the info.
Oh ok, thanks for the info. Anyway, so... I really don't mind the overkill, believe me I understand what you mean. Currently, we are not really following any kind of system at work, so its a nightmare. But no regrets, I just take it as a learning process, so now I kind of know what I am looking for now, in terms of developing apps, whether by myself or with a team.
Unfortunately, so I just
Unfortunately, so I just learned, I cant use Aegir on my Shared Hosting.
http://community.aegirproject.org/node/14#sharedhosting
"Shared hosting will not give you enough permissions to install new sites..."
Thanks anyway.
Yes Aegir is not something
Yes Aegir is not something that would work on shared hosting. However if your looking at running a drupal shop, you should have a virtual dedicated server at the very least for being able to provide quality hosting for the sites you build. You will learn very quickly there are a lot of downsides to running on shared hosting solutions.
I will be releasing a Aegir powered hosting solution soon. This may be something that you can consider.
I will certainly check it
I will certainly check it out. Please provide the link when available.
mostly remotely
Figure a workflow with your team. Most of the time it varies depending on your coding and development techniques.
Since 2010 I no longer develop locally. I use multisite setup + Git + Direct remote-server development via WebEnabled.
Marckee for Short
WebEnabled is not free :( But
WebEnabled is not free :(
But thanks for the input. I will surely keep this in mind when I get the proper clients.
This is exactly what i was
This is exactly what i was worrying about. Git can handle the files, but how about the database ? If you configured something on your local server (development) all variables/configs will be stored in the database tables. If your production site is active how can you deploy just your changes and not the entire database? I toyed with Deploy module a bit but have to really dig deeper..
True. Which is why I try to
True. Which is why I try to avoid doing any DB config via the UI as much as possible. And if really need to, I try to do the exact same thing I do in DEV to PROD. BUT, there will be more complications as your site grows bigger. I had to learn this the hard way.
I was happily adding/removing blocks in DEV while updating its CSS using the block ID to target-theme it. Everything was A-OK and it was migrated perfectly, I exported DB data to CSV, uploaded, configured as necessary. Easy.
But then the time came when I had to add a new block via UI, which I thought was pretty straightforward - add in DEV, check, add in PROD, theme using the block ID (if needed, and for this case, I needed to). I did the exact same thing in PROD as what I have done in DEV, but lo and behold, the ID of the new block in DEV was different in PROD so the CSS didn't apply (since I used the block ID) and the horrible looking block stood out in a neatly designed site. Why? Cos internally, my DB in PROD still knows to start counting from 1 when auto-assigning PK values, whereas my DEV DB has already reached a diff number.
So yeah, try to do your changes as much as possible in the code and if you really have to do it via the UI, do some research and tweak your affected tables (remove/add indexes, records, etc) so that DEV can still be more or less in sync with PROD.
You can try Features module.
You can try Features module. It can export/import data from views, block, configs, etc. CCK can export field definitions. And there are some modules that can handle export/import nodes.
For some occasions, you really need update your live site manually. Or you can write some script to update it automatically. See hook_update_N() in .install file.
One good practice is make your data portable by keeping them in code or in file (xml, json, other formats) rather than in db.
Thanks for the input. Yes I
Thanks for the input. Yes I will surely look into Features and also making my data portable.
"One good practice is make
"One good practice is make your data portable by keeping them in code or in file (xml, json, other formats) rather than in db."
You mean pwede natin gamitin ung export ng Views, save the output in a file then call it later? can the views_embed_view() use that file instead of paying a trip into the DB? Sir can you enlighten us ?Thanks!
I dont believe that is what
I dont believe that is what he was saying. I think he was mentioning exporting node/user/block data. For a total export of things i think using Views, Context, Boxes(Instead of Custom Blocks), Features, and Strongarm goes a long way to getting where you need to go. The rest can be done by creating a custom module then writting a hook_update_XXX(), this hook is found in the install file for a module can be used to update the database in numerous ways. It is quite commonly how i do this if i have no other easy way of passing the different changes i need into a database, just remember to increment the number that replaces XXX for each new update hook and you should be fine.
views_embed_view, has to call a view that is defined with an ID in the database, you can pull in a exported view(if you did it via views ui), through the views ui, then the views_build_view will work, but the best method is create a Feature Module that has that view as an component.
multiple techniques
Ang ibig sabihin ni Jeff pwede kang gumawa ng paraan para madali mong mahila yung content mo sa iba-bang sites gamit ang XML/JSON. You can use these methods to create a way to "sync" your content from one site to another (there are many ways to do this albeit a bit technical).
Remember, sa Drupal lahat ng nodes ay saved as nodes sa loob ng database. It would be best if you figure out a workflow that works for you and how you manage your content across sites.
For exportable settings / site-configs features and feature-compatible modules definitely helps.
Marckee for Short