Manage custom modules across multiple installations

Question

We have some custom modules which are used for multiple sites. Those can't be released as contributed modules, for example because they are client specific, make assumptions that don't work for contributed modules and so on.

I know about the following possibilities to deal with this:

• copy & paste them around. Makes it obviously hard to keep the module up to date on all installations.

• Have a single multi-site installation, but this isn't always possible.

• Use git submodules, but they can be nasty, it's easy to forget to update them and aren't always supported (e.g. Pantheon)

• Drush make scripts to check out from a common git repository. For this, you AFAIK need to use drush make for the whole site and we don't use it currently.

• http://drupal.org/project/fserver. I haven't tried that out yet, does someone know if it is stable enough? The project description doesn't sound very promising and there is no 7.x version.

Anything else/better? What do you prefer and why?

Answer 1

The Drush make approach, as you've already mentioned, is the version my team is using.

Even though you are not currently using drush make for your sites, it should be relatively straightforward for you to move to this workflow if you want as drush also provides drush make-generate which will generate the make file from an existing site. Thus no need to feel like it's only worth it for new sites. :)

Answer 2

If all sites are on the same server, you can use symlink to load modules from a central place, or rsync if you are dealing with multiple servers.

This will solve the problem of distributing files, but you still need to fire an upgrade. It can be automated with drush, along with a simple script that calls upgrade on every sites, one-by-one.

Answer 3

Seems to be that you almost look pretty much to all solutions. When I read it, first what come in my mind its two others solutions like rsync or symlink but again it's not comfortable to maintain.

Then in remembered about that module Git Deploy that actually be a nice combo with git submodules.

I haven't tried yet this idea, but it could work, or at least give you some clue how to hack it to do your own system.

Answer 4

I use a separate git repository for all contributed/custom modules where each contributed or custom module is in a separate branch (not in a submodule).

here is how the git merge works here:

master

      <-- custom
        <-- custom module 1
        <-- custom module 2    

      <-- contrib
        <-- contrib module 1
        <-- contrib module 2     

master --> release

and a bash/drush script to update the branches

Answer 5

I use SVN instead Git to store our custom developed modules. After I commit change from localhost, I just run the bash script which runs the "svn update" command at predefined server locations. Whenever I deploy a module to a new location, I update the bash script. It is really a simple setup and works without any hassle.