(dis) ventajas de organizar la producción dev-> usando 'drush rsync' vs 'git'?

9

Configuré un sitio Drupal bajo control git para el trabajo de desarrollo.

Está parental en un repositorio GIT maestro, desnudo, y a medida que se realizan cambios en mis diversos clones git de proyecto y trabajo, y se devuelve al maestro, un enlace posterior a la actualización empuja inmediatamente los cambios a un solo sitio web en vivo (http: / /staging.loc.). Nada especial, funciona como se esperaba.

También he alias borroso el sitio "@STAGING". En ocasiones, quiero promover mis cambios del sitio de ensayo a un servidor de producción.

Me vienen a la mente dos métodos relativamente sencillos:

(1) En un momento en el que el sitio de ensayo parece estable, cree el sitio de producción como un pago git desde el repositorio principal,

(2) use drush rsync+ drush sql-syncdesde el sitio de preparación hasta el sitio de producción.

Ambos pueden hacerse trabajar. Aparte del hecho de que (2) parece más centrado en Drupal / consciente por naturaleza, después de todo, drush es un conjunto de herramientas específicas de Drupal: ¿cuáles son los méritos relativos de los dos enfoques?

¿Hay alguna razón en particular que deba considerar (1) sobre (2)?

En cualquier caso, "Todo" está bajo al menos una instancia de control de revisión ...

drush version-control staging Clive
fuente

Respuestas:

3

He usado ambas técnicas. Ambos pueden usarse para garantizar que los mismos archivos que prueba en @stage terminen en @live. La ventaja de rsync es que no terminas con archivos adicionales (por ejemplo, ".git" y asociados) en tu servidor de producción. Tiendo a sincronizar a un vps, y uso git en un cuadro que tengo (por ejemplo, sitios de intranet).

greg_1_anderson
fuente
Gracias por el punto. Solo estaba mirando las opciones de exclusión. Eso ayuda a mantener las cosas limpias. Iiuc, necesito especificar con qué excluir "rsync' => array ('exclude-paths' => '.git:.DS_Store:.gitignore:.gitmodules:',"en el archivo .rc, aunque todavía no estoy seguro de si necesito eso en las especificaciones de los alias de origen y destino o solo en uno u otro.
.git debe ignorarse por defecto. Ejecute 'drush --simulate rsync [opciones] @a @b' para ver el comando exacto rsync que ejecutará Drush. Use --include-vcs si desea que drush rsync incluya .git y otros archivos relacionados con vcs.
greg_1_anderson
Necesito leer con más detalle; No me di cuenta de que .git estaba excluido. Gracias por la sugerencia de simulación también. Re: el OP, creo que me quedaré con el 'drush rsync' ya que está diseñado para ser un método de implementación para drupal & works. git puede funcionar, por supuesto, pero ahora he encontrado suficientes comentarios que no están diseñados para implementarse ...
1

El problema con el uso de drush rsync es que si tienes varias personas empujando cambios al servidor.

Su ejemplo solo muestra a una persona presionando los cambios.

Si tienes al desarrollador A empujando sus cambios y luego el desarrollador B empujando sus cambios, quieres que git elimine los conflictos, o haz que el desarrollador B elimine los conflictos.

Micheas Herman
fuente
1

De hecho, uso ambos. svn / git y rsync tienen dos propósitos diferentes. svn / git es para el control de fuente, rsyncy sql-syncpara sincronizar la puesta en escena y la producción eficientemente. drush rsync @staging @prodes muy difícil de superar en términos de simplicidad, y es terriblemente fácil de integrar en la mayoría de los continuous Integrationentornos en caso de que desee profundizar aún más en la locura / metodologías de calidad de código.

Stefgosselin
fuente
1

Personalmente, uso Git para el control de versiones, implementación y sincronización de varias bases de códigos de servidor y luego rsync para mover / sincronizar archivos de usuarios (ignorado al agregar ciertas rutas al archivo .gitignore).

danbohea
fuente