Toronto April Meetup: Development Best Practices

Events happening in the community are now at Drupal community events on www.drupal.org.
walkah's picture
Start: 
2008-04-24 18:30 - 20:30 Canada/Eastern
Event type: 
User group meeting

Come celebrate spring with us this month to learn about tips, tricks and tools for managing development. Colan is going to lead us through using subversion and trac and how he and the team at Openject keep on top of things. Interesting discussion is sure to ensue :-)

Note the changed date

Time: 6:30 - 8:30 pm Thursday, April 24th
Location: Centre for Social Innovation - 215 Spadina Ave, 4th floor [map]

Comments

Can Drupal newbies join?

abe's picture

Can Drupal newbies join? I know just a tiny bit of Drupal, and have implemented just one simple site.

Abe

Of Course

ConceptDog's picture

I started with drupal about a year ago now. Other than some reading online, I jumped in at DrupalCamp last year.

The community is awesome, and while my schedule hasn't let me come down for a meeting yet, you should feel more than welcome to jump in.

Just try to get there on time

clgarret's picture

... the building doors are locked and you may be stuck outside for 30 mins or so before someone comes down to check.

we'll leave signs

walkah's picture

I'll make sure there are signs with contact information for after the doors are locked.

sounds great

reformatt's picture

I would love to know more about subversion so I will defnitely come by.
Also is anybody using something similar like subversion in order to sync/update databases from local to remote?

Oh that

andremolnar's picture

There are a number of ways to tackle this 'problem'. Some interesting ideas came out of a Birds of a Feather session in Boston - but there is no single 'right' answer. And no single answer that is 'simple'.

But, its certainly a topic worth talking about. Bring along your 'solutions' to the meeting and we can talk about it. If we run short on time we can always find a nearby establishment and continue the chat.

andre

Drupal install and update scripts

andrewfn's picture

I have have been developing some bash scripts that make it very easy to install/update Drupal and contrib modules/themes. It would take me about 5 mins to demo them on Thursday if people are interested.
It handles downloading, uncompressing and putting everything into the right directories
It makes updating Drupal as simple as typing:
install drupal 6.2 or for a contrib module:
install cck 6.x-1.x-dev
If you want to check out drupal 7 from cvs, you type
cvs drupal
It also supports patching, so you can type something like
install xmlsitemap 6.x-0.x-dev
patch xmlsitemap.6.0.patch
The patch is downloaded, uncompressed and applied at the right place.
I can provision a new site in seconds with the right versions of all my favourite modules by putting a list of install commands in a batch file. It seems a shame to do all this work and not share it with others who might find it useful.

finally, a Drupal Toronto date I can make!

afronaut's picture

I too am looking for a good database versioning system to go along with SVN - didn't even know there were options out there...

See (meet) you all tonight
Ari

Great Drupal Meeting

reformatt's picture

Hi Everyone,

It was a great Drupal meeting yesterday and I learned a lot.
Also here is the link of the software I was mentioning yesterday, it ain't free unfortunately but it could be useful in serious situations.
I would like to know if there are more database comparing solutions out there (open source would be great :) )

The program is called MySQL studio and is a combination of tools.
http://www.sqlmanager.net/en/products/studio/mysql/

~Matt

Maatkit

btmash's picture

I really wish I could have made it last night :( But as for my contribution, while I haven't tried out the full set of tools, I suggest taking a look at Maatkit (http://www.maatkit.org) - There are a lot of very useful tools for database management including a dump restoration and a database checksum operation - something that could be used down the line.

This was a good session, my

brst t's picture

This was a good session, my Thursday conflicting schedule aside. Thanks again.

It's time for me to make this move. I no longer have any reasons to delay a multisite restructuring with a versioning system and oh, it's long overdue.

I found most of the links presented during the session on my own, but am guessing there are some I'm missing. Colan, do you still have those handy to post?

And wondering if anyone can offer advice for structuring my localhost. I like the added ease of mgt offered by grouping directories like Andre suggested, with 5.x/6.x. contrib modules added as externals.

drupalcore/5.7
drupalcore/6.2

modules/5.x
modules/6.x

projects/sites/all/modules
projects/sites/xyz.com/modules

etc.

But I wonder if that's still feasible if the live sites I work on are located on different servers. I host a bunch myself, which is where the main live site will be, but I also contract and subcontract out to others - some who may opt for no svn/trac or a different version control system altogether.

I can see it functioning in the absence of a version control system, but what about the case where it's different? Will projects/sites/xyz.com/modules/ suffice?

And wondering if anyone can

brst t's picture

And wondering if anyone can offer advice for structuring my localhost. I like the added ease of mgt offered by grouping directories like Andre suggested, with 5.x/6.x. contrib modules added as externals.

I didn't write this correctly or clearly. It's the repository structure I was aiming at, not the localhost directory structure. The latter needs to be restructured before I get to the rep structure.

I'm less certain now that the subversion + trac is the ideal solution for my workflow given the inherent variability I meet from project to project and server to server. Moreover, I guess is the fact that I already use a drupal-based project mgt system of my own design for tracking progress/responding to issues (not file revisions) so for me, all those extra features offered by trac would go unused and/or seem like extra work.

Instead, I'm now checking out Git (http://git.or.cz/) and maybe integrating the commit logs within drupal with the versioncontrol_git module (http://drupal.org/project/versioncontrol_git)

And that 'Drupal staging solution' (http://drupal.org/node/181128) used by the France24.com folks offers a great improvement to how I've been handling the database updates.

Structure etc.

andremolnar's picture

Hey trish,

Thanks for linking to the France24.com thread. That was the 'odd even' solution that was mentioned at this month's meet up.

Are the other tools to making a 'trac' like solution in with subversion and drupal using the drupal project module. YMMV.

http://drupal.org/project/project
http://drupal.org/project/versioncontrol
http://drupal.org/project/versioncontrol_svn

If you use subversion as your version control system - you do not need to use trac if you don't need it.

As for how to structure your repository. At the session I showed my module and core repositories that I use for including things into my individual project repositories using the svn:external property.

For that I create one repository 'drupal-core'
Inside of that repository I create folders 4.7.x, 5.x, 6.x (instead of the traditional convension of trunk, branches, tags)

I create a second repository called 'drupal-modules'
Inside of that I create the 4.7.x, 5.x, 6.x folders (once again breaking from convention)

The reason I break from convention is that I will never be tagging and or branching within these repositories. I save that for the individual projects.

Then for each project I work on I create individual repositories. (e.g. clientname-projectX)
Within those repositories I create the traditional structure of trunk, branches, tags folders.
I then start checking my work into the trunk of that project. Making use of svn:external to load core and contrib modules from the other repositories.
At later stages I will create tags and release/bug fix branches as needed.

Hope that helps.

andre

Repository structure

colan's picture

I normally maintain a structure like in this example:

  • /vendor/drupal/core/
    • 4.7
    • 5
    • 5.1
  • /vendor/drupal/contrib/modules
    • views
      • 5.x-1.2
      • 5.x-2.0
      • current
    • cck

I use svn_load_dirs to update the vendor drops whenever I need to install a new one.

Slides

colan's picture

Here's a little update for those of you that have been requesting my slides. I've got them posted as an attachment to my blog post on the event. Please take a look at them. (Sorry this took so long!) I'm thinking of running this session again for Drupal Camp 2008, so if anyone has any thoughts on that, please let me know. Feedback is always welcome.

Belated thanks for the slide

brst t's picture

Belated thanks for the slide links, Colan.
And those extra details, Andre.

I think the project module is one of the best there is. But where it's quite strictly software-oriented with an abundance of information (too much for a lot of my purposes) and the output to Views still in the works, I'm sticking with my own custom cck/views solution. So far so great, or so it goes.

And after much consideration, I discovered that git is just a much better fit for my purposes than svn. I haven't got it integrated with Drupal quite yet, though am happy enough with the small handful of commands ('git init' 'git add'/'git checkout' and 'git commit'). With qgit and gitk rounding out the either-or options for the visual display.

And while the Linus Torvalds presentation on git may be better known/more controversial, I preferred the Oct'07 Google TechTalk given by Randal Schwartz. Well worth the 59 min if you're at all interested. It covers a lot of ground.

The 'think globally work locally' nature of git really fits nicely with my existing workflows where a single, centralized server doesn't or is another couple jobs to manage. Plus, for me - plus plus:
+the ad-hoc nature of initiating a track on any tree of files locally or on a live server
+using git to help track changes to binary files like images and audio
+the free and ease of branching off on some exp'tl path and only committing the ones that are successful.
+access control with ssh is easy and can also restrict who's allowed to push changes

The biggest drawback so far:
- the big initial checkout of a giant project; big load aside, that giant pass isn't compatible with all projects all the time

AI/Drupal Toronto

Group notifications

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