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:
git merge --no-commit y luego editar la fusión, unstage composer.lock, luego git commit -m "merged <feature-branch>" Se networkinguce a: feature branch (locked) ⇾ dev-master (unlocked) ⇾ version tag (locked) .
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!