Administre módulos personalizados en varias instalaciones.

Tenemos algunos módulos personalizados que se utilizan para múltiples sitios. Esos no se pueden lanzar como módulos contribuidos, por ejemplo, porque son específicos del cliente, hacen suposiciones que no funcionan para los módulos contribuidos, etc.

Conozco las siguientes posibilidades para lidiar con esto:

• Cópielos y péguelos. Obviamente hace que sea difícil mantener el módulo actualizado en todas las instalaciones.

• Tenga una única instalación en varios sitios, pero esto no siempre es posible.

• Utilice submódulos git, pero pueden ser desagradables, es fácil olvidar actualizarlos y no siempre son compatibles (por ejemplo, Pantheon)

• Drush crea scripts para verificar desde un repositorio git común. Para esto, AFAIK necesita usar drush make para todo el sitio y actualmente no lo usamos.

• http://drupal.org/project/fserver . Todavía no lo he probado, ¿alguien sabe si es lo suficientemente estable? La descripción del proyecto no suena muy prometedora y no hay una versión 7.x.

¿Algo más / mejor? Que prefieres y porque?

El enfoque de hacer Drush , como ya mencionaste, es la versión que mi equipo está usando.

Aunque actualmente no está utilizando drush make para sus sitios, debería ser relativamente sencillo moverse a este flujo de trabajo si lo desea, ya que drush también proporciona drush make-generate que generará el archivo make desde un sitio existente. Por lo tanto, no es necesario sentir que solo vale la pena para nuevos sitios. :)

Si todos los sitios están en el mismo servidor, puede usarlos symlinkpara cargar módulos desde un lugar central, o rsyncsi está tratando con varios servidores.

Esto resolverá el problema de la distribución de archivos, pero aún debe iniciar una actualización. Se puede automatizar con drush, junto con un script simple que llama a la actualización en cada sitio, uno por uno.

Parece ser que casi buscas casi todas las soluciones. Cuando lo leo, primero lo que viene a mi mente son otras dos soluciones como rsynco symlinkpero, una vez más, no es cómodo de mantener.

Luego recordé sobre ese módulo Git Deploy que en realidad sería un buen combo con submódulos git.

Todavía no he probado esta idea, pero podría funcionar, o al menos darte una idea de cómo hackearla para hacer tu propio sistema.

Utilizo un repositorio git separado para todos los módulos contribuidos / personalizados donde cada módulo contribuido o personalizado está en una rama separada (no en un submódulo).

así es como funciona la fusión git aquí:

Maestro

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

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

maestro -> lanzamiento

y un script bash / drush para actualizar las ramas

Utilizo SVN en lugar de Git para almacenar nuestros módulos desarrollados a medida. Después de confirmar el cambio desde localhost, simplemente ejecuto el script bash que ejecuta el comando "svn update" en ubicaciones de servidor predefinidas. Cada vez que implemento un módulo en una nueva ubicación, actualizo el script bash. Es realmente una configuración simple y funciona sin problemas.