Gestionar compositor e implementación

Por lo tanto, estoy disfrutando el uso del compositor, pero me cuesta entender cómo lo usan los demás en relación con un service de implementación. Actualmente estoy usando deployhq, y sí, puedo configurarlo para implementar y ejecutar compositor cuando hay una actualización del repository, pero esto no tiene sentido para mí ahora.

Mi repository principal de compositores, que contiene solo el file json de todos los packages que deseo include en mi compilation, solo se actualiza cuando agrego un nuevo package a la list.

Cuando actualizo mi tema o la extensión personalizada (a la que se hace reference en el file json), no hay un "gancho" para actualizar mi service de implementación. Así que tengo que iniciar session en mi server y ejecutar manualmente el compositor (que lleva el sitio hasta que haya terminado).

Entonces, ¿cómo otros gestionan esto? ¿Debo solo ejecutar el compositor localmente e include la carpeta del proveedor en mi repository?

Cualquier respuesta sería muy apreciada.

James

Siempre habrá arguments sobre la mejor manera de hacer cosas como esta y hay diferentes respuestas y opciones diferentes; el truco es encontrar el que mejor se adapte a usted.

en primer lugar

Primero daría un paso atrás y vería cómo está gestionando su compositor. Json

Recomendaría que todos sus packages en composer.json se bloqueen hasta el número de versión exacto del artículo en Packagist. Si está utilizando Repos de github para cualquiera de los packages (o están configurados para dev-master), entonces me aseguraré de que estos packages estén bloqueados con un hash de confirmación específico. Parece que básicamente estás ahí con esto, ya que no dices nada de actualizaciones de los packages cuando lo ejecutas.

¿Por qué?

Esto es para garantizar que cuando ejecuta la actualización del compositor en el server, estos packages se extraigan de la memory caching si existen y para garantizar que no implemente accidentalmente el código no probado si uno de los modules se actualiza entre su testing y su implementación.

Despliegues reales

Posible método 1

Mi opinión es un poco controvertida en cuanto a Composer en muchos de mis proyectos que no pasan por un sistema de CI, comprometo a todo el directory de proveedores con el control de versiones. Esto es simplemente para garantizar que tengo una twig completamente desplegable en cualquier etapa, también hace que las implementaciones sean increíblemente rápidas y fáciles (git pull).

Ya habrá personas que dicen que esto es innecesario y que bloquear los numbers de versión será suficiente para garantizar que se manejarán las fallas de los sistemas remotos, obstruye el tree de VCS, etc. etc. – No entraré en esto ahora, hay arguments a favor y en contra (muchos de ellos basados ​​en opiniones), pero como lo mencionó en su pregunta, pensé que le haría saber que me ha sido útil en muchos proyectos en el pasado y que es una opción viable.

Método posible 2

Al usar los enlaces simbólicos en su server a la raíz de su documento, puede asegurarse de que la compilation finalice antes de cambiar el enlace simbólico al nuevo directory una vez que haya confirmado que la compilation se completó. Esta es la ruta de menor resistencia hacia una implementación segura para un set de códigos básico utilizando la actualización del compositor en el server. De hecho, uso este método junto con la mayoría de mis implementaciones (incluidas las de arriba y las de abajo).

Posible método 3

Composer puede usar "artefactos" en lugar de un server remoto, esto significa que básicamente creará una "carpeta de repository" de los files de su proveedor, esta es una alternativa para agregar toda la carpeta del proveedor a su VCS, pero también lo protege. contra las interrupciones / files de Github / Packagist que se eliminan y otros posibles problemas. Los files se recuperan de la carpeta de artefactos y se instalan directamente desde el file zip en lugar de recuperarse de un server; esta carpeta se puede almacenar de forma remota. Piénselo como un package privado pobre (otra opción por cierto).

IMO: el mejor método en general

Configure un sistema de CI (como Jenkins), cree algunas testings para su aplicación y pídales que respondan para impulsar webhooks en su VCS para que se desarrolle cada vez que se presiona algo. En esta versión, configurará el sistema para:

  • ejecutar testings en su aplicación (si existen)
  • ejecutar la actualización del compositor
  • generar un artefacto de estos files (si los elementos anteriores tienen éxito)

Jenkins también puede hacer una implementación real para usted si lo desea (y el process de compilation no falla), puede:

  • empujar el artefacto al server a través de SSH
  • implementar el artefacto usando una secuencia de commands

Pero si ya tiene implementado un sistema de implementación, es probable que uno de sus escenarios de implementación sea tener desplegado un artefacto probado.

Espero que esto ayude 🙂