NBuild

nbuild es el sistema de integración continua (CI/CD) utilizado diariamente para generar y probar NAppGUI-SDK. Se ha desarrollado en ANSI-C90, utilizando el propio NAppGUI-SDK. En principio no es una utilidad de propósito general, mas bien se ha creado ex profeso para cubrir las necesidades propias de este proyecto. No obstante, con la evolución y ampliaciones necesarias, puede dar soporte a cualquier proyecto C/C++ que esté basado en CMake.

nbuild -n network.json -w workflow.json -s secrets.json

• network.json: Configuración de la red de nodos. Ver Red de compiladores.
• workflow.json: Lista de tareas a realizar. Ver Flujos de trabajo.
• secrets.json: Contiene aquellos valores sensibles, como contraseñas, que no pueden alojarse en repositorios convencionales. Ver Secretos.

1. Ejemplo de uso

En https://nappgui.com/builds/en/builds/bindex.html tienes acceso al registro de la CI/CD de NAppGUI SDK, gestionado por nbuild (Figura 1).

2. Motivación y características

El desarrollo de nbuild empezó en el año 2017 como una pequeña utilidad para lanzar comandos de compilación remotos mediante ssh. Con el tiempo ha ido evolucionando tomando características propias de sistemas CI/CD convencionales como Jenkins, TeamCity o GitHub Actions. Hay varios motivos por lo que NAppGUI no utiliza estos sistemas CI/CD pero pueden resumirse en tres: Complejidad del despliegue, evitar el scripting y garantizar el funcionamiento de por vida en plataformas legacy. Todo esto unido a la facilidad y potencia que brinda el tandem C+SSH para implementar cualquier necesidad actual o futura, ha sido suficiente motivación para ir mejorando esta herramienta a lo largo de los años. Las principales características de nbuild pueden resumirse en:

• Compilación, prueba y empaquetado de proyectos en C/C++ basados en CMake.
• Orientado a proyectos Open-Source, donde se distribuye el código fuente.
• Mínima configuración en los nodos (runners) donde únicamente es necesario instalar SSH, CMake y los compiladores (GCC, Xcode, MSVC o Clang).
• No requiere soporte en cloud (AWS, Artifactory, GitHub, etc). Tampoco necesita conexión a Internet. Funciona en una red de área local privada.
• No utiliza Ansible ni cualquier otra herramienta de acceso remoto. Solo SSH.
• No hay que programar scripts. Tan solo indicar que targets queremos compilar, dentro de workflow.json.
• No hay paneles de control ni interfaz web. Corre como una utilidad por línea de comandos.
• Cada proyecto puede definir su propia red de nodos.
• No hay que pagar por compilar.
• No requiere Python.
• Funciona con nodos "legacy" como Ubuntu12, WindowsXP o MacOSX Snow Leopard.
• Multi-etapa. Un flujo de trabajo relativamente grande puede dividirse en varias etapas de diferente prioridad, obteniendo resultados parciales lo antes posible.
• Multihilo. Controla diferentes nodos en paralelo.
• Scheduler. Empareja trabajos con los nodos disponibles.
• Redundancia. Es posible configurar varios nodos con las mismas características (SO, versión del compilador, etc), con el fin de acelerar procesos que requieran la misma plataforma.
• No bloqueante. En ningún momento la ejecución de nbuild interfiere o bloquea nuevos cambios en el repositorio.
• nboot. Capacidad de encender/apagar runners bajo demanda, en el momento que se necesiten.
• ndoc. Generación de documentación asociada al proyecto.
• nreport. Genera reportes web con el resultado de cada ejecución.

3. Flujos en nbuild

nbuild ejecuta Flujos de trabajo descritos en archivos workflow.json, donde se incluye la descripción del proyecto, la lista de targets y las plataformas objetivo. Este flujo se reiniciará cada vez que se detecten cambios en el repositorio, aunque queden tareas por realizar de flujos anteriores. Es decir, el objetivo de nbuild no es completar todas las tareas de un flujo, sino completar cuanto antes las tareas de máxima prioridad con la versión más reciente del repositorio. En resumen, un flujo de trabajo se compone de (Figura 2):

• Exportación del código. nbuild no trabaja directamente con el código fuente del repositorio. Previamente, se realizará una selección, pre-procesado y empaquetado de aquellos archivos requeridos por el flujo en cuestión, almacenando los resultados en el nodo drive. Este paquete fuente estaría listo para ser distribuido, bien a través de GitHub o directamente en un .zip. También se utilizará por los nodos de la CI, para tareas de compilación y test.
• Documentación. Si el proyecto dispone de documentación, y se detectan cambios en ella, se creará una nueva versión de la documentación y se almacenará en el nodo drive.
• Compilar/test. Se compilará y comprobará el paquete fuente en diferentes nodos de la red, por orden de prioridad.
• Reportes. La ejecución de nbuild irá acompañada de un reporte web. Cada vez que el estado del repositorio cambie, por ejemplo, al realizar un nuevo commit, se abrirá un nuevo reporte. El mismo reporte se irá actualizando a medida que se vayan completando trabajos relacionados del mismo commit.
• Hosting. Tanto la documentación del proyecto como los reportes CI/CD se pueden subir a un servidor público, para que sean más fáciles de consumir.

4. Ejecutar nbuild

Para lanzar el sistema CI/CD hay que ejecutar el comando nbuild de forma manual o mediante algún administrador tipo unix-cron. No existe ningún evento, hook o trigger que automáticamente active el sistema a partir de cambios en el repositorio. Esta CI/CD ha sido diseñada para completar las tareas de mayor prioridad lo más rápido posible, por lo que ejecuciones sucesivas de nbuild cooperarán en la resolución del flujo de trabajo definido en workflow.json (Figura 3).

En etapas donde el código cambie con frecuencia, nbuild se centrará en aquellas tareas de máxima prioridad. Con esto pretendemos detectar lo antes posible cualquier error introducido en los últimos commits. Por el contrario, en etapas de baja actividad (fines de semana), el sistema irá completando paulatinamente las tareas de baja prioridad, hasta cubrir todo el espectro de compilaciones y pruebas existentes en workflow.json.

La ejecución de nbuild solo realizará unas pocas tareas, las de mayor prioridad dentro del fluyo. Es el administrador del proyecto el encargado de programar con que frecuencia debe ejecutarse la CI/CD.

Se pueden lanzar diferentes instancias de nbuild en paralelo, siempre que trabajen sobre flujos diferentes.

5. Licencia

nbuild es un proyecto Open Source y se publica bajo licencia MIT.