Versión rusa

Imaginemos que está desarrollando un dispositivo de software y hardware. El dispositivo consiste en un sistema operativo personalizado, servidores exclusivos, mucha lógica empresarial, como resultado, tiene que usar hardware real. Si libera un dispositivo roto, sus usuarios no estarán contentos. ¿Cómo hacer versiones estables?

Me gustaría compartir mi historia de cómo lo tratamos.

Prueba de concepto

Si no conoce un objetivo, será realmente difícil superar la tarea. La primera variante de despliegue se parecía a bash :

make dist for i in abc ; do scp ./result.tar.gz $i:~/ ssh $i "tar -zxvf result.tar.gz" ssh $i "make -C ~/resutl install" done 

El script se simplificó solo para mostrar la idea principal: no había CI / CD. Nuestro flujo fue:

1. Construido en host de desarrollador.
2. Implementado para probar el entorno para una demostración.

En la etapa actual, al saber cómo se aprovisionó, todos los errores conocidos eran magia sucia dentro de las mentes de los desarrolladores. Fue un problema real para nosotros debido al crecimiento del equipo.

Solo hazlo

Habíamos usado TeamCity para nuestros proyectos y gitlab no había sido popular, por lo que decidimos usar TeamCity. Creamos manualmente una VM. Estábamos ejecutando pruebas dentro de la VM.

Hubo algunos pasos en el flujo de compilación:

1. Instale algunas utilidades dentro del entorno preparado manualmente.
2. Comprueba que funciona.
3. Si está bien, publique RPM.
4. Actualice la puesta en escena a la nueva versión.

 make install && ./libs/run_all_tests.sh make dist make srpm rpmbuild -ba SPECS/xxx-base.spec make publish 

Recibimos un resultado temporal:

1. Algo ejecutable estaba en la rama maestra.
2. Funcionó en alguna parte.
3. Podríamos detectar algunos problemas casuales.

¿Sientes el olor?

1. Hubo un infierno de dependencia con los RPM.
2. Todos tenían su propio entorno de desarrollo de mascotas.
3. Las pruebas se estaban ejecutando dentro del entorno desconocido.
4. Había tres entidades completamente ilimitadas: compilación del sistema operativo, provisión de instalaciones y pruebas.

Reduce la magia sucia

Cambiamos los flujos y el proceso:

1. Creamos el metapaquete RPM y eliminamos el infierno de dependencias.
2. Creamos una plantilla de VM de desarrollo a través de vagabundo.
3. Movimos los guiones de bash a ansible.
4. Por un lado, creamos un marco de pruebas de integración, pero por otro lado, usamos serverpec .

Como resultado de la etapa actual que recibimos:

1. Todo nuestro entorno de desarrollo era idéntico.
2. El código de la aplicación y la lógica de provisión se sincronizaron con cada una.
3. Aceleramos el proceso de incorporación de nuevos desarrolladores.

Por un lado, una construcción fue realmente lenta (aproximadamente 30-60 minutos), pero por otro lado fue lo suficientemente buena y atrapó con éxito la gran mayoría de los problemas antes del control de calidad manual. Sin embargo, enfrentamos nuevos problemas diferentes, es decir, luego actualizamos el kernel o luego revertimos un paquete.

Mejorarlo

Resolvimos muchos problemas diferentes:

1. Las pruebas de integración funcionaron cada vez más lento porque la plantilla de máquina virtual de desarrollo era anterior a los RPM reales. Estábamos reconstruyendo la plantilla manualmente, luego decidimos automatizarla:
   
   • Crea un VMDK automáticamente.
   • Adjunte el VMDK a una VM.
   • Empaque la VM y cárguela en s3.
2. En caso de una fusión, no fue posible obtener el estado de compilación, como resultado, pasamos a gitlab.
3. Solíamos hacer un lanzamiento manual todas las semanas, lo automatizamos.
   
   • Versión de incremento automático.
   • Genere notas de lanzamiento basadas en problemas cerrados.
   • Actualización de registro de cambios.
   • Crear solicitudes de fusión.
   • Crea un nuevo hito.
4. Pasamos algunos pasos a Docker (pelusa, ejecutamos algunas pruebas, enviamos mensajes, compilamos documentos, etc.).

Como resultado en el esquema de la etapa actual se veía así:

1. Había muchos repositorios RPM / DEB para paquetes.
2. Había s3 como almacén de artefactos.
3. Si ejecutaste una compilación dos veces para la misma rama, recibirías un resultado diferente, porque las dependencias del metapaquete no estaban codificadas.
4. Había límites no visibles (líneas de color rojo) a través de las construcciones.

Sin embargo, pudimos producir versiones cada semana y mejorar la velocidad de desarrollo.

Conclusión

El resultado no fue ideal, pero un viaje de mil li comienza con un solo paso ©.

PD es crosspost