Cerrar

Continuous integration, explained

Crea una metodología ágil para tu equipo con un feedback más rápido. Porque solo avanzas tan rápido como tus pruebas.

Nothing builds–or destroys–agility like a team's commitment to continuous integration (CI). That might sound ominous (especially if your team has yet to embrace CI), but there's good news. Regardless of the technologies a team uses, chances are there's a continuous integration and automated test framework that will work for their code base. Here's what you need to know before you dive into the detail.

Continuous integration articles

[CONTINUED]

¿En qué consiste la integración continua?

La integración continua es la práctica de integrar de forma rutinaria los cambios en la rama principal de un repositorio y probar los cambios, tan pronto como sea posible. Lo ideal es que los desarrolladores integren el código a diario, si no varias veces al día.

Automated testing, continuous delivery, and continuous deployment

It is important to distinguish continuous integration from automated testing as well as continuous delivery and continuous deployment. While those development practices relate to each other, they differ essentially by how the code gets deployed to production.

Automated testing

Automated tests are tests that can be run without the need of human intervention in a repeatable way, at any time. You typically have to write down a script to test some assertions or validate the behaviour of your application. The script is then run by a machine which provides the results as an output. Automated testing is a key part of CI, but it is not enough by itself.

Entrega continua

You practice continuous delivery when your codebase is always deployable, ready to go to production in one click. While it is recommended to deploy to production as soon as you get a green build, you may decide to slow down the releases on purpose for business reasons.

Despliegue continuo

Continuous deployment happens when every change to the main branch that passes the CI tests gets pushed to production without the need for human interaction. This often results in many deployments per day which provide fast feedback to the development team.

Ventajas de la integración continua

Investing in CI results in fast feedback on code changes. Fast as in "within minutes" fast. A team that relies primarily on manual testing may get feedback in a couple hours, but in reality, comprehensive test feedback comes a day–or several days–after the code gets changed. And by that time more changes have occurred, making bug-fixing an archeological expedition with developers digging through several layers of code to get at the root of the problem.

Definitivamente, eso no es rápido.

Los equipos ágiles entregan software de calidad con rapidez, sin heroicidades ni marchas forzadas. Todo gracias a la IC.

Protección de la calidad con builds continuas y automatización de pruebas

¿Quién no se ha descargado el último código fuente y resulta que no se compilaba o que tenía un error importante? ¡Adiós a la productividad!

Hay dos formas de evitar esta situación:

Compilaciones continuas: Compilar el proyecto en cuanto se realice un cambio. Lo ideal sería que la diferencia entre compilaciones fuera de una sola modificación.

Test automation: Programatic validation of the software to ensure quality. Tests can initiate actions in the software from the UI (more on that in a moment), or from within the backend services layer.

Piensa que estas dos prácticas son como la mantequilla y la mermelada: por separado, saben bien, ¡pero juntas mucho mejor! La integración continua aúna las compilaciones continuas con la automatización de pruebas. Así se garantiza que en las compilaciones se evalúe también la calidad del código.

And remember: to fully realize the benefits, a team must also have the discipline to pause development and address breakages right away. The energy a team invests (and make no mistake: it's an investment) in writing tests and configuring the automation is all for naught if builds are allowed to languish in a broken state. Protecting the investment in CI and protecting the quality of the code base are one and the same thing. 

Pruebas en IC: unidad, API y pruebas funcionales

Las ejecuciones de IC constan de dos fases principales. El primer paso garantiza que el código se compile (o, dicho en lenguaje llano, encajen todas las piezas). El segundo paso asegura que el código funciona según lo previsto. La forma más segura de hacerlo es con una serie de pruebas automatizadas que validen el producto en todos los niveles. 

Pruebas unitarias

Ventajas: son fáciles de escribir, se ejecutan con rapidez y se asemejan enormemente a la arquitectura del proyecto.

Inconvenientes: las pruebas unitarias solo sirven para validar los componentes principales del software; no reflejan el workflow del usuario, que normalmente entraña el funcionamiento conjunto de varios componentes.

Puesto que las pruebas unitarias indican cómo debería funcionar el código, los desarrolladores pueden revisarlas para ponerse al corriente sobre esa área del código concreta. 

Pruebas de API

El buen software es modular, cosa que permite separar mejor el trabajo entre distintas aplicaciones. Las API son el punto final en el que se comunican módulos diferentes entre sí, y las pruebas de API los validan realizando llamadas de uno a otro.

Benefits: Generally easy to write, run fast, and can easily model how applications will interact with one another.

Inconvenientes: en casos sencillos, las pruebas de API pueden ser exactamente igual que algunas pruebas unitarias.

Puesto que las API actúan como nexo entre los componentes de la aplicación, son de especial utilidad a la hora de preparar de una publicación. Cuando una compilación que aspire a publicarse haya pasado todas las pruebas de API, el equipo puede sentirse mucho más seguro al proporcionársela a los clientes.

Pruebas funcionales

Las pruebas funcionales trabajan con áreas más amplias de código y muestran el workflow del usuario. En aplicaciones web, por ejemplo, HTTPUnit y Selenium interactúan directamente con la interfaz de usuario para probar el producto.

Ventajas: hacen más probable encontrar errores, ya que imitan las acciones del usuario y prueban la interoperabilidad de múltiples componentes.

Drawbacks: Slower than unit tests, and sometimes report false negatives because of network latency or a momentary outage somewhere in the technology stack.

Con frecuencia los equipos observan que, a medida que se acercan al workflow real del usuario, disminuye la velocidad de ejecución de las pruebas automatizadas. HTTPUnit es más rápido, ya que no es un navegador web en toda regla. Selenium solo funciona a la velocidad del navegador web, pero tiene la ventaja de ejecutarse en varios de ellos de forma simultánea. A pesar de estas desventajas, las pruebas funcionales tienen un gran valor y dan feedback mucho más rápido de lo que jamás podrían los evaluadores humanos.

Y hablando del rey de Roma...

Algunos evaluadores consideran las pruebas automatizadas una amenaza existencial. Este pensamiento es de poca visión de futuro, y no podría estar más lejos de la realidad. Al no tener que repetir soporíferas tareas de prueba, los evaluadores pueden dedicarse al análisis de riesgos, la planificación de pruebas y adquirir otras habilidades... ¡como aprender a programar! 

Agiliza la integración continua

En Atlassian, procuramos que los desarrolladores sigan innovando y que el código se mantenga en buen estado. Hacemos mucho hincapié en minimizar el "bucle de feedback" del desarrollador, que no es más que el tiempo necesario para compilar cambios y obtener los resultados de las pruebas.

Ejecutar pruebas automatizadas puede incrementar y prolongar rápidamente la duración de la compilación. Una estrategia es ejecutar pruebas automatizadas de forma simultánea en distintos servidores o "agentes de compilación", de manera que el servidor de IC ejecute 2, 20 o hasta 200 pruebas al mismo tiempo. Con las tecnologías basadas en la nube, la CPU se puede adaptar fácilmente a las necesidades del equipo de desarrollo a medida que aumentan los conjuntos de pruebas. Eso sí, la CPU no es ilimitada. Prueba cada área del código por completo, pero no de forma redundante. Las pruebas redundantes inflan la duración de la compilación (y malgastan CPU). Cuando antes tengan luz verde los ingenieros, más rápido podrán pasar al siguiente punto del backlog. 

Las ramas y la IC: ¡una pareja de ensueño!

Muchos equipos evitan las ramas a causa de merges dolorosos. Con las nuevas tecnologías en control de versiones como Git, crear ramas y merges resulta más fácil. Para garantizar que la línea de código principal ("maestra" en la jerga de Git) se encuentra en buen estado, aplica el mismo nivel de integración continua en todas las ramas de desarrollo y versiones estables. Cuando la compilación pasa por una rama, el equipo tiene confianza para combinar ese código de forma ascendente.

With branching, continuous integration, and test automation, teams can be productive and innovative while still protecting code quality. If you're ready to take the next steps, check out our step-by-step guide to getting started with CI.

Este es el desarrollo ágil en todo su esplendor: entregar con regularidad software que funcione, con una deuda técnica mínima y sin poner en peligro el ingenio.

Dan Radigan
Dan Radigan

La metodología ágil ha influido mucho en mí, tanto en el aspecto profesional como en el personal: he aprendido que las mejores experiencias se basan en el modelo ágil, tanto al programar como en la vida real. Mis intereses suelen moverse entre la tecnología, la fotografía y el motociclismo. ¡Sígueme en Twitter! @danradigan