Gran proyecto de TYPO3 con flujo de trabajo de CI e implementación de una sola característica

Tenemos un gran proyecto de TYPO3 con varios desarrolladores. Estamos tratando de configurar una infraestructura de CI, con GIT, compositor y Jenkins. Tenemos entornos de desarrollo (vagrants), de preparación y de producción. Es bastante común que múltiples funciones estén en el server de transición al mismo time. Debido a que diferentes personas están a cargo de probar estas características, las características generalmente no se aplican al server de producción al mismo time. Así que configuramos el siguiente flujo de trabajo:

Todos los desarrolladores comienzan desde la twig principal y crean su propia twig de características. Cuando la function debe ir al server de transición, la twig de característica debe ser presionada. Tenemos una configuration en la que se definen todas las twigs de características, que deben ir a etapas. El Sr. Jenkins fusiona todas las twigs de características antes de build el proyecto y despliega todo en el server de etapas. Cuando una característica se testing con éxito y debe pasar a producción, la twig de características debe combinarse con la maestra. El Sr. Jenkins construye el proyecto y todo se implementará en la producción.

Hasta ahora estamos muy satisfechos con el flujo de trabajo, excepto en un punto: file composer.lock.

Una function podría actualizar o instalar un package. Tan pronto como dos twigs de características manipulan el file composer.lock, hay un conflicto con el "hash" del file que no se puede fusionar automáticamente.

En mi opinión, no hay una solución limpia. La única solución para mí es excluir el file composer.lock del repository y dejar que el Sr. Jenkins haga una "actualización del compositor" que lleva al estado indefinido de todos los packages requeridos. La forma más limpia en mi opinión sería unir todo el entorno de desarrollo a la producción una vez que se hayan probado todas las características, pero esto no se puede hacer por motivos de organización.

¿Es este flujo de trabajo una gran ventaja, o hay una solución de mejores prácticas?

¡Gracias por cualquier ayuda!

¡ Deberías añadir el file composer.lock al proyecto git, porque de lo contrario obtendrás diferentes versiones en jenkins y, por supuesto, para cada desarrollador!

No fusionaría más que la característica actual + master en jenkins y resolvería posibles problemas de fusión manualmente

Mis sugerencias son:

  • mantener el Composer.lock en las twigs (características) y solo las tags (versión)
  • las sucursales son estables y el context de la versión para desarrollar una nueva característica está bloqueado
  • eliminar composer.lock de la twig de desarrollo principal (master)
  • el maestro siempre está sangrando y el desarrollo ocurre hasta que la característica (o el set de características) se congela
  • Al fusionar una twig de entidad con la twig de desarrollo, excluye el file composer.lock
    • puedes usar git merge --no-commit y luego editar la fusión, unstage composer.lock, luego git commit -m "merged <feature-branch>"
  • en congelación de características, ramificación fuera (nueva label de versión) y agregar composer.lock para bloquear el context de la versión

Se networkinguce a: feature branch (locked)dev-master (unlocked)version tag (locked) .


  • comstackr el package de implementación desde la label (bloqueada) de la versión + distribuir (liberar)
  • instalar / actualizar un package de lanzamiento en producción O seguir el enfoque de usar el compositor en la caja de producción e instalar la label de la versión 🙁

La forma más limpia en mi opinión sería unir todo el entorno de desarrollo a la producción después de que se hayan probado todas las funciones …

Fusionando con la producción 🙂 – ¡Err, no, eso sería demasiado fácil!