Cabalgando a la bestia: una experiencia de rediseño legacy

Cabalgando a la Bestia

Una experiencia de rediseño legacy

Diego Fontdevila Marcelo Gore

@dfontde @marcelogore

El camino

El contexto del proyecto

Decisiones tomadas

Mejoras implementadas en el producto

Prácticas implementadas

Lecciones aprendidas

Contexto del proyecto

Fue desarrollado en dos etapas para un cliente original

Fue repensado como un producto

Vendido a un primer cliente

144 pruebas unitarias y de integración en tres generaciones

(1 que fallaba aleatoriamente)

1 prueba de regresión de interfaz de usuario

Muchas dependencias innecesarias

Arquitectura de módulos

Decisiones tomadas

Decisiones tomadas

1. Refactorizar en la primera etapa solamente el módulo de inconsistencias.

2. Invertir fuerte en ejecutar continuamente la prueba general de regresión.

3. Automatizar los procesos (build, deploy) de punta a punta.

4. Realizar las mejoras incrementalmente.

Decisiones tomadas [I]

Refactorizar en la primera etapa solamente el módulo de inconsistencias (también borrar lo que no servía)

Antes pensamos en refactorizar el módulo web

Antes aún, en refactorizar el módulo de Cuestionarios

Nos ayudó la presión de las fechas a reconcebir nuestra ideas

Tomamos la decisión con autonomía, pero con restricciones

RefactorRenombrar 5 tablas y sus columnas

Mejoras implementadas

Migración a Postgres

Refactoring de módulo de inconsistencias

Versionado de base de datos con FlyWay

Despliegues automatizados

Entornos con software de base idéntico

Homogeneización de estilos con Bootstrap

Prácticas implementadas

Prácticas implementadas

Infraestructura como código

Integración continua (incluyendo despliegue)

Entrega continua

TDD de punta a punta o BDD

Infraestructura como código

./ Utilizamos Vagrant como abstracción para administrar máquinas virtuales VirtualBox y cajas en la nube con DigitalOcean

./ Ansible como abstracción de la provisión de software de base a las máquinas virtuales

./ Bash para automatizar despliegues

./ Maven para automatizar builds

./ Repositorio de infraestructura

Administrar la configuración de infra (máquinas virtuales,

software de base, automatización) como código

Infraestructura como código[demo]

Lecciones (re)aprendidas

● Es fundamental gestionar efectivamente la configuración○ En particular, separar la configuración dependiente del ambiente

(puertos, usuario y clave, etc.)

● Manejar las tareas en jenkins con scripts que empaqueten toda la información

○ Por ejemplo deploy y deploy-test que llama a deploy con los

parámetros para test.

○ Permite ejecutar rápidamente maximizando el feedback.

● Ejercitar el proceso múltiples veces para encontrar errores y aumentar su claridad/eficiencia.

● Usar smokeTest

Nos equivocamos (I)

Integración continua total

./ Ejecutar continuamente las prueba s unitarias.

./ Desplegar continumante a una máquina virtual

./ Ejecutar continuamente la prueba de aceptación (regresión) general.

Ejecutar continuamente las pruebas

Integración Continua

Tablero de Jenkins

Despliegue continuo

Delivery pipeline

SEGTCI

SEGTGenerar

Test

SEGT Desplegar

Test

SEGT Desplegar

Cliente

SEGT Desplegar

Test

SEGT Desplegar

Prod

TDD de punta a punta (BDD)

Creamos pruebas para la poquísima funcionalidad nueva

Escribimos las pruebas antes de escribir la funcionalidad

Lo hicimos probando desde la interfaz de usuario

TDD de punta a punta[demo]

Lecciones aprendidas

Vale la pena no abandonar aunque el andamiaje sea frágil.

Vale la pena invertir en abstracciones de infraestructura.

Siempre hay alguna forma de cortar que permite mejorar.

Las pruebas heredadas son difíciles pero pueden ser útiles.

Es importante hacer versiones iniciales y mejorarlas luego.

¿Preguntas o reflexiones?

Muchas gracias

Diego [email protected]@grupoesfera.com.ar

Marcelo [email protected]@grupoesfera.com.ar