19

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?

1

5 Answers 5

10
+200

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. :)

2
  • Thanks, I've decided to accept your answer. I need to get used to drush make, figure out how to best deal with this in large projects with many custom modules and convince my co-workers before I can start using this, though ;) Do you have any resources on how to maintain a site, e.g. best way to update version, rebuild a site.
    – Berdir
    Jun 7, 2012 at 7:36
  • 2
    I didn't have any resources, so I wrote one :) drupal.stackexchange.com/questions/33403/… Of course, feel free to comment with deeper questions if you want. :)
    – Letharion
    Jun 7, 2012 at 10:58
1

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.

0

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.

1
  • Git deploy exposes version information of contrib modules, but we don't have contrib modules so I don't think it would help.
    – Berdir
    Jun 1, 2012 at 9:08
0

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

2
  • My solution is based on this article nvie.com/posts/a-successful-git-branching-model
    – LLub
    Jun 1, 2012 at 11:01
  • Hm. So I could then essentially add another site as as a remote and import a custom module branch from there. That could work, but is relatively complex.
    – Berdir
    Jun 1, 2012 at 11:35
0

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.