Continuamente Integrado

No sé si conoces a Henry Ford. Por si acaso no te situas, fue el señor que creo la marca de coches Ford y consiguió democratizar el uso del coche en EEUU.

¿Como consiguió tal azaña?

Revolucionando la forma en que se construian los coches.

Introduciendo la producción en cadena. Lo que permitía construir muchos coches, más rápido y con menores costes y posibilidades de fallo.

Artesanos del siglo XXI

Al igual que antes de la llegada de las revolucionarias ideas de Henry Ford, todo el proceso de fabricación de coches era totalmente artesano, en el mundo del SW embebido pasa algo similar.

Muchos desarrolladores de SW embebido, tenemos la idea en la cabeza de que lo que hacemos es «especial», «singular», una especia de arte que está a la altura de la ceremonía del té Japones.
Y la idea de introducir cualquier técnica que se utilice en el SW tradicional nos produce urticaria.

Yo también fuí así hace años. Pero un día me empecé a hacer preguntas.

¿Como puedo evitar que mi código solo compile en mi máquina?

¿Como asegurarme de que no he roto nada al introducir cambios?

¿Por qué el proceso de generación de una release es tan manual, y tan tediosa?

Muchas preguntas que tenían la misma respuesta.

Automatización

Mientras me hacía todas esas preguntas, y por la mayor de las casualidades, acabé en la división que realizaba un SW de Control de Satélites de la empresa donde trabajaba.

Durante los 7 meses que pasé allí maldiciendo mi suerte y buscando otro trabajo aprendí algo.

Las técnicas de desarrollo de SW de una aplicación de alto nivel (de esas que yo detestaba).
Tests unitarios, uso exquisito del control de versiones, compilación automática con cada commit, sistema de tickets para las incidencias enlazadas con el control de versiones, etc, etc, etc.

Estas técnicas con el tiempo se denominaron CI/CD (continuos integration & continuos delivery).

Terminos como DevOps, surgen de aquí también.

Y aquí dejo las batallitas y vuelvo a las preguntas.

¿Como puedo evitar que mi código solo compile en mi máquina?

¿Como asegurarme de que no he roto nada al introducir cambios?

¿Por qué el proceso de generación de una release es tan manual, y tan tediosa?

La respuesta a mis preguntas estaba en esas técnicas de automatización que conocí por casualidad.

Todo era tan sencillo como automatizar todas esas tareas mediante un sistema de integración continua.

  • Compilación automatica
  • Ejecución de tests
  • Analisis estático de código
  • Analisis de la calidad del código
  • Tests en target
  • Análisis de cobertura
  • Generación de binarios de producción

Todas estas cosas y muchas más se pueden hacer de forma automática.

Con una única y sencilla meta

DESARROLLAR CÓDIGO DE MEJOR CALIDAD Y EN MENOS TIEMPO

Y esto, seas desarrollador o CEO de una empresa debería estar poniendote cachondo…

Un empujoncito

Como te decía, deberías estar cachondo pensando en hacer código más rápido y de mejor calidad.

Pero hay un pero.

¿Como se pone en marcha todo esto?

Y aquí es donde yo te puedo ayudar.

Llevo bastantes años utilizando herramientas de todo tipo:

  • SVN, Git y otras para el control de versiones
  • Trac, Mantis, Redmine, JIRA, Gitlab para gestión de tareas e incidencias
  • Jenkins, Gitlab, Github para integración continua
  • Cantata, Vector Cast, Google Tests, Unity, CppUnit para tests unitarios
  • PCLint, CppCheck, SonarQube para en analisis del código
  • Vim, Eclipse, VSCode para editar y compilar código
  • Make, CMake y otros para compilar código

Y se lo que es juntar piezas para formar un engranaje afinado.
Y sobre todo, que las herramientas estén a tu servicio y no tu al servicio de las herramientas.

Ahora es tu turno

Si algo de lo que te he contado te ha resonado y quieres que te ayude en la automatización de tu proceso de desarrollo, contáctame:

Escribeme a carlos@codingalchemy.es y hablamos.