intive Argentina Blog

¿Qué NO es Integración continua?

El título de este artículo es una pregunta de examen. Posiblemente con un valor de entre 5 y 10 puntos. Muchos responderán que “Integración continua” es “integrar continuamente” y, otros no. Algunos ni siquiera podrán dar respuesta a esta incógnita. Y es que para decir qué NO es “Integración continua”, necesitamos entender qué es.

Integración Continua

Integración continua está considerada dentro de las buenas prácticas al desarrollar software. Consiste en integrar los cambios que se han realizado sobre un código fuente y asegurarse de que éste funcione, incluso cuando las modificaciones hayan sido llevadas a cabo por varias personas. Es un hábito recomendado dentro de las metodologías ágiles, un fundamento de la programación extrema y un pilar dentro las prácticas de DevOps.

Para poder decir que usamos Integración continua en nuestros proyectos, deberíamos asegurar los siguientes tres aspectos:

  • Un repositorio central

Independientemente de la herramienta que usemos para centralizar (ya sea git, subversion o mercury), el código que debería llegar a nuestros ambientes tendría que estar contenido en este repositorio. Es recomendable que los desarrolladores definan reglas de convivencia, acerca de cómo trabajar en el repositorio. Las comunidades de cada herramienta ofrecen algunos lineamientos, que podrían ser útiles para explotar todo su potencia. Aquí, un ejemplo de git.

  • Pruebas automatizadas

La consolidación del código dentro del repositorio muchas veces parece suficiente para decir que el mismo es estable. Pero la verdad es que NO, NUNCA, ¡JAMÁS! Cuando se modifica una parte de la aplicación, sin querer se puede afectar una funcionalidad que previamente no mostraba inconvenientes, por lo que resulta ideal la ejecución de pruebas automatizadas que logren identificar problemas. La Integración continua tiene mucho valor a la hora de detectar errores en fases tempranas, ya que el costo y el esfuerzo de solucionar un problema es mucho mayor a medida que se avanza en el desarrollo.

Dentro de las pruebas automatizadas, podemos realizar pruebas unitarias. En equipos ágiles, el “tech lead” debería promover una cobertura de código aceptable. La cobertura de código consiste en definir qué porcentaje de nuestras pruebas unitarias cubre el código escrito. Esto no significa que abarque todos los casos, pero sí que por lo menos alcance todas las partes probándolas al menos una vez.

Las pruebas unitarias no son las únicas dentro de un contexto de integración continua. También se pueden agregar pruebas de integración y funcionales, que darán un mejor resultado si buscamos obtener un producto de calidad. Adicionalmente, podemos analizar si el código cumple estándares de codificación y complejidad.

  • Producto estable

El resultado de aplicar pruebas deriva en un producto que es candidato para ser enviado a ambientes productivos, en periodos cortos de tiempo. En teoría, cada vez que se realice la integración del código y se superen las pruebas, deberíamos obtener al final del día una nueva versión para instalar. También lograremos hacernos de ciertas métricas que nos ayudarán a mejorar nuestro producto, como por ejemplo: complejidad ciclomática y cobertura de test.

Ahora, ¿Qué NO es Integración continua?

  1. Usar git.
  2. Usar jenkins u otra herramienta similar para bajar el código y compilarlo.
  3. Compilar código directamente en un ambiente.
  4. No hacer pruebas.
  5. La filmografía de Adam Sandler. No solo no es Integración Continua, sino que mucho menos son buenas sus películas.

Rodolfo Cordero

Rodolfo Cordero es desarrollador en la compañía desde junio de 2016. Es Licenciado en Desarrollo de Software, graduado de la Universidad Latina de Costa Rica, país del cual es oriundo. Asiduo lector y melómano, hizo cursos de coctelería y barismo, habilidades con las que deleita al staff de intive-FDV en los afters organizados por la compañía.

4 comentarios