La primera jornada del Software Development Summit (#SDsummit) estuvo dedicada al Continuous Delivery y tuvimos el placer de contar con Angélica Lozano, quien nos dio un punto de vista diferente sobre este tema.
Angélica Lozano, CTO de MOBILE LEAN (m-lean), nos contó cómo trabajan para conseguir llevar el despliegue continuo al contexto de los entornos industriales. Facilitan el día a día de la gente que trabaja en una fábrica mediante aplicaciones móviles nativas, conocidas como MPS (Mobile Production System).
Contexto
La empresa nació en 2014 y desde su primer cliente, en Francia, ha sido siempre una empresa internacional. Hoy están presentes en 180 fábricas del sector automoción y alimentación de 24 países.
Según Angélica, “una característica de nuestros clientes es que funcionan de una manera razonablemente estandarizada en todas sus fábricas”. Gracias a ello pueden aportar valor al grupo con un impacto mayor.
La estrategia de m-lean es “crecer muchísimo el número de fábricas manteniendo más o menos contenido el número de clientes” y aprovechar esta uniformidad de procesos.
Flujo de desarrollo
Las 17 personas del equipo de ingeniería trabajan sobre la rama develop y según van sacando funcionalidad en feature branches van haciendo merge. Es una aproximación “menos glamourosa que lo que contaba Edu en su charla” del SDSummit pero les funciona.
La manera de integrar esas funcionalidades del producto es mediante Pull Requests que acaban siendo integradas mediante un pipeline automático de Jenkins que identifica las partes de código que han cambiado y lanza sólo los tests afectados. Esto ocurre continuamente varias veces al día. Para prevenir problemas de regresión y dar mayor seguridad se lanzan todos los tests de manera programada por la noche.
Adicionalmente usan Sonarqube para monitorizar la calidad del código y mediante Quality Gates vigilan que ésta no baje.
Tienen iteraciones de dos semanas, al cabo de las cuales el código no va a producción sino a la rama demo “desde la que se despliega en los entornos de testing y de demo”. Éstos entornos de testing y demo se utilizan por parte de los comerciales para enseñar el producto. También se despliega en unas cuantas fábricas piloto de cada cliente para “reducir el ciclo de feedback” y “van validando la funcionalidad en ciclos relativamente cortos”.
Cada 4 iteraciones, 2 meses, se mergea de demo a master y se lleva el código a todas las fábricas.
Mantenimiento del producto
Los componentes del producto son webs, backend y aplicaciones móviles nativas. Éstas últimas no se despliegan a través del store sino que “es despliegue corporativo privado”. Cabe destacar que se trata de despliegues independientes en cada fábrica ya que sus aplicaciones no son multitenant y están además sujetas a otras restricciones que pueden ser de seguridad o por limitaciones técnicas del cliente.
Tienen un sistema de actualización que avisa al usuario de que hay una nueva versión y sólo le permite instalarla. Esta forma de trabajar simplifica el mantenimiento, ya que no necesitan versionar su API porque siempre usan la última versión.
“Sólo se hace mantenimiento de la última versión del producto (…) si hay que hacer un hotfix (…) para una fábrica, siempre sabemos en qué punto del código está”.
Despliegue
Inicialmente se hacían despliegues más continuos, pero el feedback de los usuarios fue que les molestaban las interrupciones a causa de las actualizaciones y pidieron que se espaciaran más en el tiempo. “Lo que yo percibía como un súper valor añadido resulta que al revés (…) quizás por ser entorno industrial (…) se percibía como algo negativo”.
La parte de los servidores web está contenedorizada con docker y orquestada por docker-compose. En la mayoría de los casos se ejecutan sobre ubuntu.
Diagrama de la componentes del producto
Todo este proceso que consiste en la generación de imágenes y binarios así como la transferencia por red para una fábrica normal es de una media hora con una perdida se servicio de unos segundos.
Mejoras previstas
El despliegue habitual solía ser on-premise, pero hay una tendencia general de migrar hacia la nube. Siguen trabajando “en la automatización como mantra” y en acercarse a las buenas prácticas que presentó Eduardo Ferro en su charla. Para 2021 quieren separar las partes de build, deploy y release. De hecho la idea es que la fase de release la haga el equipo de ventas.
Conclusión
La presentación de Angélica fue interesantísima tanto por la temática como por lo amena que fue, entrando en muchos detalles de los entornos industriales y de su proceso de desarrollo de producto, que aunque no esté aún del todo optimizado evoluciona continuamente hacia ese objetivo.
Podéis volver a ver su charla aquí:
Sobre el autor:
