Continua Incontinencia / Continua Diarrea

6

Recientemente veo que en varias empresas les pasa un poco lo mismo. Es algo que no se comenta mucho y hay que “rascar” para que te lo cuenten, ya que no es algo de lo que estén muy orgullosos. Pero sucede. El caso es que los equipos de desarrollo de repente ven la luz y quieren mejorar. Escuchan que hay que hacer TDD, CI/CD, volverse ágiles, etc. Muchas veces sin pararse a pensar en por qué hago esto, qué beneficio tiene y qué necesito para poder aplicarlo, en profundidad. Así se lanzan de cabeza y, como era de esperar se la pegan. Aunque como ya he comentado a veces creo que es bueno, y posiblemente inevitable, pegársela para poder aprender. Pero hay cosas que no están a nuestro alcance, que hay que esperar a poder hacerlas. Y una de ellas es la integración y desarrollo continuos (CI/CD).

Me recuerda a mi hija mayor. Ella ha saltado de afición en afición. Veía algo que le gustaba (natación sincronizada por ejemplo) y nos pedía insistentemente que le apuntásemos. Y la historia solía ser la misma: desde el primer día ella quería hacer las cosas chulas que veía hacer a sus compañeras con más experiencia, pero que todavía no le tocaba hacer. Primero tenía que aprender la base. Así que siempre pasábamos por una primera etapa de frustración: “esto no es tan guay como esperaba”. Y así ha sido hasta la última, el dibujo. Ella quería pintar comics casi desde el primer día y llegaba a un “no me sale”. Pero antes tiene que dibujar muchos jarrones, muchas manos, mucha fruta, muchas narices, antes de poder pintar escenas de un comic. Y esta vez parece que lo ha aprendido y poco a poco va practicando y sumando habilidades a su dibujo.

En otras áreas, como el desarrollo, pasa lo mismo. Creo que estos equipos quieren llegar al estado de madurez el primer día, y se lanzan a todo de cabeza. Pero esto puede ser muy peligroso.

El caso particular que os traigo, el CI/CD, es especialmente peligroso.

CI (“la continua incontinencia”) requiere que nuestro equipo esté maduro en múltiples habilidades. Tiene que dominar y haber interiorizado algún método para gestionar el código (como GitFlow). Debe ser capaz de romper las nuevas funcionalidades complejas en partes más pequeñas. Debe tener la mentalidad de hacer código testeado y 100% funcional en cada una de estas entregas. Debe tener un sistema de pruebas maduro, y quizás es imprescindible que sea automático. Y podría estar un buen rato más diciendo requisitos para poder tener CI. CI es bueno y nos permite reducir los conflictos entre desarrolladores que trabajan en el mismo producto o en productos relacionados. Pero si no estamos preparados va a ser un problema muy grave. Lo primero es que todo llegará a las ramas principales (normalmente la master, aunque podría tener otro nombre) rápidamente y sin control. Así que en vez de ganar, perderemos control. Estaremos “meando” bugs a nuestras ramas principales y bloqueando futuras releases de otros. Estaremos “arrastrando” cambios no deseados a producción. Y otros múltiples problemas. Y si todo el día estamos “meando”, sufrimos incontinencia.

CD (“la continua diarrea”) es similar a lo anterior. A tener incontinencia sobre nuestro código, le añadimos que “la mierda” llegará a producción con un flujo continuo. A poquito a poquito, pero sin descanso. Un flujo continuo de “mierda” es lo que yo llamo diarrea. Así que aplicar CI/CD sin estar preparados es sufrir de diarrea. Problemas comunes están el poder subir a producción sin pasar por el control de versiones (porque así se arregla más rápido) que algunos sistemas de scripting (ASP, JSP, PHP, Ruby, Python, …) podrían permitir sin compilar. O el no testear los cambios, y que suban solos. O el no tener visibilidad de cuando suben las cosas: Un programador hacer un merge, y acaba en producción: el sistema “peta” y operaciones no sabe por qué. Nadie le avisó de que algo subía. Para poder tener CD, a todos los requisitos de CI hay que añadir nuevos. Algunos como que el sistema de deploy en producción avise a interesados, suba un canario, lo compare con el resto, y aplique el cambio si las métricas están bien. Que tengamos un sistema de rollback rápido. Que los desarrolladores tengan la cultura de hacer sus desarrollos compatibles hacia atrás y permitir el rollback. Lo único peor que la diarrea, es atascar un WC de diarrea.

Resumiendo, debemos apuntar a CI/CD. Hay grandes ventajas en ello. Pero no podemos pretender montarlo en un chasquido de dedos. Hay que estar preparados. CI/CD es un premio si hemos hecho bien los deberes. Si no, puede ser nuestra peor pesadilla.

Sobre el autor

Jose M. Huerta

Jose es Gestor de Proyectos y Gestor de Servicios en Mallorca. Es Ingeniero de Telecomunicaciones y obtuvo el Master of Advanced Studies durante su etapa como investigador. Pero no tardó en abandonar ese mundo y meterse de cabeza en el mundo de las Tecnologías de la Información. Está certificado como ITIL Expert. Tiene amplia experiencia en gestión de servicios, clásica e integrada con desarrollo, gestión de proyectos, usando metodologías clásicas y ágiles, gestión de programas y portfolios, gestión de grandes grupos de personas, localizadas y off-shore, sin dejar de perder de vista el lado técnico y freak del sector. Ha trabajado en varias empresas del sector con distintos roles en áreas tanto de gestión de servicios de soporte como de equipos de desarrollo. Actualmente trabaja en WebBeds, como responsable del equipo de operaciones TI.

6 comments

  1. Miquel Gabarró 8 octubre, 2018 at 16:48 Responder

    Todos los artistas pasan por distintas etapas, épocas o períodos ( por ejemplo: Picasso en su etapa azul, rosa , negra, cubismo, … etc). En resumen, tú etapa escatológica me esta gustando ! Más madera o mejor dicho más mierda ;-).

  2. Joan Miralles 11 octubre, 2018 at 07:54 Responder

    Tienes razón en que es un cambio que debe hacerse poco a poco, y si puede ayudarte alguien que ya se haya enfangado alguna vez mejor.
    Pero en mi opinión, en el caso de la CI, puede ser un proceso que puede (incluso debe) instaurarse en cualquier proyecto, siempre por fases, y no pasar a la siguiente hasta que una fase implantada no esté madura para el equipo.
    Hace ya unos cuántos años, en nuestra empresa implantamos un proceso de CI muy simple en los proyectos Legacy, sólo para que los artefactos dejaran de generarse en el “PC” del programador, y se centralizara, en nuestro caso, en el Jenkins.
    Es un proceso de CI simple, al que le faltan muchas etapas, pero ya te permite detectar el típico archivo que no se ha subido, problemas de configuración de entornos, etc.

    Gradualmente se pueden ir:
    – Añadiendo Tests
    – Pasar de Subversion a Git (me maravilla la cantidad de empresas que todavía usan Subversion)
    – Usar un Artifactory o un Nexus donde publicar los artefactos generados.
    – Implantar una metodología de Gitflow
    – etc.

    Gracias Jose por estos artículos “de mierda”. Esperando el siguiente con ganas. 😀

    • Jose M. Huerta 11 octubre, 2018 at 08:04 Responder

      ¡Wow! Un lujo tenerte comentando por aquí.
      Por supuesto, 100% de acuerdo contigo. Pero seguro que conoces algún caso en el que la norma es “hay que ir mergeando todo a la rama principal para que luego no nos cueste mergear”. Y eso llevado al límite de un programador añade la funcionalidad A, a medio testear. Otro programador añade la B. Queremos hacer la release de la B, pero la A está en medio y vemos que falla. Así que a invertir unas horas a echar atrás los cambios, y volver a poner la B sola. Y eso si la A y la B no interactúan. A eso me refiero con ir a CI por el mero hecho de querer implantar CI sin entenderlo del todo.
      “me maravilla la cantidad de empresas que todavía usan Subversión”: X_D ; y te añadiría: la cantidad que usan subversión, y todo a la misma rama.
      La verdad es que me estoy sintiendo cómodo con esto de escribir sobre mierda.

  3. Julio 16 octubre, 2018 at 13:54 Responder

    Me encantan los renames que has usado!

    Pero en el tema CI/CD hay mucha confusión y malinterpretación.
    CI es un modo de funcionamiento a nivel de equipo.
    CD es un modo de flujo de valor a nivel de organización.

    Nunca he entendido porque se meten ambas siglas juntas: CI/CD. No son lo mismo para nada! y de uno no puedes pasar al otro como si fuera el siguiente paso. Antes hay muchísimos más. El principal problema es que la gente entiende esto:
    CI = tenemos Jenkins.
    CD = podemos hacer una entrega a la semana.
    Y por tanto, ya me puedo poner la pegatina de moda. Nosotros hacemos CI/CD. Igual que usamos Scrum. Igual que antes tuvimos el CMMI.

    Pero no es nada de esto. Es más algo como:
    CI = el equipo trabaja de forma integrada a diario, sube y se baja código cada día. Colabora. Este código tiene que ser estable. Esto permite tener una línea base del código estable y actualizada. Ese es el objetivo. El Jenkins de turno no es más que una automatización para avisarte de si el código de esa línea base no está estable. Es sólo un chivato. Si el equipo hace bien CI el jenkins ni se mira.
    CD = el equipo es capaz de entregar valor según Negocio lo requiere. Qué es valor? Lo defines tú mucho mejor que yo, pero por supuesto es software que funciona. Ya no es sólo que el código esté estable, es que no tiene bugs, que funciona en PRO y no sólo en el ordenador del desarrollador, que es lo que quiere negocio y no otra cosa, que no requiere que negocio se pase una semana haciendo pruebas antes de validar la puesta, que tiene buen rendimiento, etc. Si Negocio puede precisar implantar a las 4am o pedirte algo para dentro de un par de horas, pues más te vale tenerlo todo bien automatizado. Pero, de nuesto, esto es más secundario de lo que cree la gente.

    Entonces, para llegar a este nivel de CD, necesitas dar muchos pasos antes. Lo has descrito muy bien: hay unos deberes previos. Disciplina, trabajo en equipo, colaboración, responsabilidad, control de versiones, automatización, tests, tests por un tubo!, CI, gestión de la configuración, entornos, repositorios, monitorización y más cosas que seguro que se me olvidan.

    Y una opinión: el feature-branching no soluciona nada. Quizás al revés. Y las herramientas sólo son eso: herramientas. Una mala herramienta, o no tenerla, puede hacer que te sea más dificil. Pero no justifica nada. Puedes hacer CD con subversion sin problemas. Y si crees que no puedes, a lo mejor habría que preguntarse por qué no puedes hacerlo varias veces, a modo de retrospectiva.

    PD: Escribiendo este tochazo me he dado cuenta de que en el pie del blog pone SUCRÍBETE en lugar de SUSCRÍBETE.

Post a new comment