How to setup an organized development environment
Hi,
i use Drupal for a long time as a pure CMS, but i'm willing to use in "real" development, implementing more complex systems, so i'm wondering how do Drupal developers organize the versioning of modules code. I used to develop with Java, where i had Maven and some other tools to "modularize" the project, but i hadn't a system around, so i'm a bit confused.
I'm developing a functionality that break into 3 modules, how do i organize this? Doesn't make sense for me to put the whole Drupal, with 3 modules, inside subversion(am i right?), but the IDE(Netbeans, in case) does not support to have a "project" with 3 different versioning setups in your subfolders(each module with your repository). I'm thinking about creating 1 "project" for each module, with it's own repository, and leave the IDE without knowledge about the Drupal code itself, but i think this will bring me some cons.
Any links, guidelines, tips?
Thanks in advance ;)
My quick tips
I have used both Eclipse and Netbeans and have finally settled on using Netbeans. I occasional use Geany (http://www.geany.org/) to edit single files especially BASH scripts because it loads very fast.
My experience with the integrated source control within Eclipse and Netbeans is they are not reliable, especially with the nested repositories. Both IDEs can be useful for viewing your revision history and comparing files. Still, these days I am using Beyond Compare as my diff editor (http://www.scootersoftware.com/) and UnFuddle (http://unfuddle.com) as my SVN repository host and browser. Generally, I do all my updates and commits from the command-line.
My custom code repository is setup to be similar to a Drupal installation's directory structure.
/trunk/drupal-custom
/trunk/drupal-custom/modules
/trunk/drupal-custom/modules/my_custom_modules
/trunk/drupal-custom/scripts
/trunk/drupal-custom/scripts/backup.sh
/trunk/drupal-custom/themes
/trunk/drupal-custom/themes/my_custom_theme
....
I bundle all my work together and mainly work on the HEAD code base. I will only create branches for major changes like when Drupal 7 is released.
I keep all my custom code outside my Drupal projects and setup symlinks as needs. Sometimes I will symlink the entire modules folder. (ie ln -s /var/www/drupal-custom/modules /var/www/example.com/sites/all/modules/custom/)
When I am working on a custom module I will just create a local test Drupal installation and symlink the needed modules or theme from my local sandbox.
My simple re-cap would be to use the command-line for source control and keep it simple.
Hope this helps.
Thanks @jrockowitz I'm not
Thanks @jrockowitz
I'm not too far from what you told, so i guess it's a good start. The main difference is that i'm working with RapidSVN, instead of command line.
The whole stuff here is Netbeans(merges came here too), RapidSVN and Trac. The layout of the svn repo is /mymodule/trunk
I am also just starting with
I am also just starting with Drupal Module Development. I think it is good idea to keep the custom modules in your repository and symlink them to the drupal installation.
thanks for these tips.
Symlinks vs Vendor branching
Symlinks can be a quick win, but can also cause problems. The best way is to use a vendor-branching system to keep your custom code in a separate branch, and merge into specific projects as needed.
This is a really good question though overall (dev environment). Would be good to get some more best-practices out there.
http://www.chapterthree.com | http://www.outlandishjosh.com
What kind of problems with
What kind of problems with simlinks are you refering to?
Symlink problems I know about...
Certain commands especially FTP will ignore the symlink and upload the contents. Some commands, like tar and gz, require an option to to be set so that just the symlink is archived and not the symlink's contents.
Still, I love symlinks.
SVN: externals
Using SVN:externals is another way to manage vendor branching.
http://svnbook.red-bean.com/en/1.0/ch07s03.html
I hit a snag with using SVN:externals because the feature was added in SVN 1.5.x and my extremely cheap shared hosting is using SVN 1.4.x. so I went back to using symlinks. I use a shell script to keep track of my symlinks. I also use relative paths for the symlinks which makes them easier to manage when moving them from one environment to another.
BTW, I think the main difference between using merging vs SVN:externals is when you
svn commityour project the SVN:externals directory will also be committed. I would assume GIT has a similar feature. (Please correct me if I am wrong.)Symlinks are probably okay for one developer but for a project with multiple developers joshk is right, it is worth leveraging source control as much as possible.
Pendrive alternative
I use a pendrive with any portable edition of some WAMP server if I want a fast windows environment, or I use a pendrive with a live distribution of linux with a LAMP server.
Then I assign different ports for te DBs and HTTPD servers and i have my fast and comfortable environments always with me.
I have erroneusly posted this comment here, sorry!