Cómo usar Git-Flow en el desarrollo de software integrado

Cuando se habla de adoptar el desarrollo ágil, la integración continua, la entrega continua y las prácticas de DevOps, tener un sistema de control de versiones adecuado y configurar el flujo de trabajo correcto es una de las cosas básicas para abordar. Te lleva a través de la mayoría de los componentes básicos de Dev-Test-Operation: código, compilación, prueba y lanzamiento. Las investigaciones de los equipos de I + D de SW muestran mejoras significativas que reducen el tiempo de comercialización de nuevas características cuando se implementan prácticas adecuadas de control de fuente [1].

Hoy, el sistema de control de versiones más popular para equipos ágiles es Git, por lo que esta publicación de blog se centrará en un flujo de trabajo Git específico, que se adapte al desarrollo de software integrado.

Git-Flow

imagen tomada de - http://nvie.com/posts/a-successful-git-branching-model/

Para nosotros en Jumper, después de probar algunos flujos de trabajo de git, hemos decidido trabajar con Git-Flow según lo propuesto por Vincent Driessen (si no está familiarizado con Git-Flow, le recomiendo que lo lea).

En pocas palabras, Git-Flow está diseñado principalmente en torno al lanzamiento y aboga por dividir su trabajo entre dos ramas principales:

Master: Lo que está actualmente en producción: la rama estable.
Desarrollar: El próximo conjunto de características en las que estamos trabajando: la rama sangrante.
Git-Flow también habla sobre pocas ramas de soporte y cómo todo se conecta entre sí.

Consideramos que este flujo de trabajo, aunque pueda parecer un poco engorroso, es muy útil para proyectos de software integrados. En la aplicación web o móvil, es posible que no necesite una o más ramas de desarrollo, lanzamiento y master. Sin embargo, el software integrado no se puede implementar todo el tiempo, ya que los dispositivos físicos no siempre están listos para la actualización. Otra razón es que las actualizaciones de software pueden necesitar certificación. Creemos que las ramas maestra, de lanzamiento y desarrollo son necesarias cuando no se implementa todo el tiempo.

Piense en lo que sucede cuando encuentra un error en la producción, pero el tiempo desde un paquete desplegable listo hasta la actualización real del firmware en el campo es de días o semanas. Durante este tiempo, su equipo de desarrollo está trabajando en el próximo conjunto de características. Si se fusiona directamente con el maestro, pero aún no está listo para lanzar todas sus funciones y se encuentra un error en la producción: tiene que volver a la etiqueta que está en producción, ramificando eso, probando, liberando la rama , y luego fusionarse. Con una rama de desarrollo, esto no es un problema. Nuevas características están en desarrollo. Las revisiones se ramifican fuera del maestro y luego se fusionan en maestro y se desarrollan cuando finaliza.

¿Puedo obtener los mismos beneficios con las etiquetas?

Git-Flow proporciona una clara separación de preocupaciones por el desarrollo de nuevas características, mantenimiento general continuo, cada ventana de lanzamiento y mantenimiento de emergencia. Shifu es el más sagrado de los santos, y debe permanecer en un estado puro, activo y entregable en todo momento. Claro, técnicamente podríamos lograr lo mismo al etiquetar los commits liberables, pero las ramas separadas proporcionan una clara distinción, y eso es más que invaluable en el desarrollo de software integrado.
También es útil ver de un vistazo lo que ha lanzado, lo que está a punto de lanzar y qué características aún no se han incluido en ninguna versión.

Restricciones de desarrollo de software incorporado

El desarrollo de software para sistemas integrados introduce restricciones que afectan el flujo de trabajo de desarrollo de software y Git. Creemos que los tres siguientes son los más comunes para la mayoría de los proyectos de sistemas integrados:

  1. Configuración de hardware: durante la vida útil de un proyecto, debe admitir diferentes configuraciones de hardware, lo que significa que debe mantener diferentes versiones de software.
  2. Tiempo de certificación: el proceso de certificación, que es imprescindible para médicos, automotrices, industriales, etc., introduce largos ciclos de prueba antes de un lanzamiento, lo que significa que la fusión con el maestro se pospone.
  3. Prueba automatizada: el dispositivo físico hace que la conexión del proceso de prueba automatizado a un flujo de trabajo de Git sea engorroso (aprenda estos cinco pasos para pasar de la prueba manual a la automatizada en forma integrada).

Las tres restricciones están relacionadas con el flujo de trabajo de Git que elija, pero la tercera también requiere un marco de prueba que le permitirá ejecutar pruebas automatizadas para productos de software integrados (verifique la automatización de pruebas con las herramientas Segger).

Si desea tener una manera fácil de automatizar las pruebas de software integradas de su dispositivo físico, está invitado a probar Jumper. Para aprender a automatizar su proceso de compilación, que es una parte esencial para las pruebas, lea aquí.

Configuración de hardware

Durante la vida útil de un producto integrado, es posible que tenga diferentes configuraciones de hardware que se implementan para diferentes tipos de clientes, o incluso para el mismo cliente. Esto generalmente significa que necesitará tener diferentes versiones para estos subproductos, mientras usa el mismo repositorio. Uno podría elegir trabajar con más de un maestro y desarrollar sucursales, pero no lo recomendamos. Cuando intentas mantener diferentes ramas, te encuentras creando compilaciones únicas, pruebas separadas, fusión de características duras, etc. Todo esto se traduce en pérdida de eficiencia.

En este tipo de proyectos, el desafío principal generalmente está en las interacciones entre las versiones y cómo compartir el código entre ellas de manera efectiva, y Git-Flow no fue diseñado para ser una solución a ese problema.

Como no hay una bala de plata para abordar esto con Git en general, describiremos algunos enfoques para que pueda elegir.

  1. Divida la base de código en bibliotecas / módulos no relacionados que admitan diferentes configuraciones, adminístrelos por separado y luego realice una administración de configuración. Tenga en cuenta que deberá invertir en una arquitectura de software y capas de abstracción adecuadas.
  2. Controle diferentes configuraciones con banderas de características en las mismas ramas.
  3. Cree ramas aisladas y de larga duración para cada versión / configuración de hardware.

A largo plazo, recomendamos utilizar los dos primeros enfoques juntos. También hará que su código sea mucho mejor y le ahorrará tiempo en las pruebas.

Tiempo de certificación

Para los productos que deben cumplir con las necesidades de regulación, el tiempo de certificación puede tardar semanas antes de un lanzamiento. Durante este tiempo, desea que su equipo continúe fusionándose y trabajando en las siguientes funciones, sin agregar ruido al proceso de lanzamiento de la certificación. Para esto, el Git-Flow funciona a las mil maravillas.

Pruebas automatizadas

Tener un buen flujo de trabajo de Git sin conectar un proceso de prueba automatizado es como hacer solo una parte del trabajo (aprender a pasar de las pruebas manuales a las automatizadas). Debe definir un proceso en el que se ejecuten diferentes tipos de pruebas en diferentes ramas para que tenga una buena cobertura y eficiencia en el tiempo de ejecución de las pruebas. Como una característica está comprometida y fusionada en la cadena de ramas: desde la rama de características local hasta el repositorio remoto, para desarrollar, liberar y dominar, debe agregar más pruebas para completar la ejecución de regresión.

Como cada proyecto tiene requisitos de prueba únicos y recursos de prueba disponibles, describiremos nuestro flujo de prueba, que puede necesitar algunos ajustes para adaptarse a su proyecto. Nuestro flujo de pruebas se basa en la suposición de que al menos puede ejecutar pruebas que no sean de host, pruebas de host simuladas y pruebas de HiL [2].

Tenga en cuenta que debe configurar su administrador de automatización para que no ejecute la misma prueba dos veces en la misma confirmación.

¿Interesado en probar Jumper?

Si trabaja con sistemas integrados y desea tener una manera fácil de probar el software integrado de su dispositivo físico, está invitado a probar Jumper. Jumper le permite realizar pruebas de host simuladas para impulsar todo su ciclo de I + D.

Resumen

Adoptar el flujo de trabajo de Git correcto es algo que debe evaluar cuidadosamente. No hay una talla única para todos aquí y depende de los requisitos únicos de su producto. Esperamos que nuestro flujo de trabajo propuesto sea beneficioso para sus necesidades. Háganos saber sus pensamientos y comparta con nosotros su flujo de trabajo de Git.

Campo de golf

[1] - https://itrevolution.com/the-amazing-devops-transformation-of-the-hp-laserjet-firmware-team-gary-gruver/

[2] - https://docs.google.com/spreadsheets/d/1ScSDfn9v73TBaGpuiGfpPTqnBeTvNd22TzApMt_E0qE/edit#gid=0