La Integración continua: Netscape, la NASA, XP y dos mayordomos

En el artículo “La Integración Continua reduce el riesgo en proyectos software” comentábamos un poco el contenido del artículo de Martin Fowler que sacó en el 2005 sobre este mismo tema. En este artículo Fowler explicaba que la CI tenía un beneficio directo en los proyectos software reduciendo el riesgo, y  tuvo el efecto  añadido de  ayudar a que se difundiera con aún más fuerza.  Haciendo un guiño nostálgico a un anuncio del 2001 que decía “Si no sabes programar no sabes informática”, hoy en día “si no practicas la integración continua, no desarrollas software”. Volviéndome a ponerme nostálgico, ya lo decían en un anuncio de los 80: “la informática es mucho más que unas palabras”. Porque desarrollar software es mucho más que sentarse durante horas a escribir líneas de código.

programador3

Los que conozcan Extreme programming me dirán, “integración continua es una de las prácticas de XP”. Sí que lo es, es una de las 12 prácticas de XP, pero ¿cómo fue su evolución? y ¿a quién se le ocurrió por primera vez que debían hacerse integraciones automáticas lo más a menudo posible para reducir el riesgo en los proyectos? ¿Un día se levantó Kent Beck de la cama y dijo: “¡¡¡Eureka!!!”? y uno de los doce mandamientos será: integración continua. Nada más lejos de la realidad.

Os Dez Mandamentos 1

La CI fue propuesta y nombrada por primera vez en 1991 por Grady Booch en su método (Método Booch). En este caso Booch no hablaba en ningún caso de integrar varias veces al día. Grady Booch es conocido por desarrollar UML junto con James Rumbaugh. En 1991/94 desarrolló el método Booch. Se trataba de una técnica usada en ingeniería software para el diseño de objetos (predecesor de UML y RUP). Este método hablaba de uso de objetos, métricas, QA, patrones de diseño, formalismo, madurez de procesos y una notación robusta. Habla de sacar releases de arquitectura hasta llegar al sistema final (evolutivos)…si, es el precursor de RUP también, evidentemente.

image-83472-full

En los años 90 del siglo XX se producían dos temas importantes para el surgimiento de la integración continua. Uno fue que contrataron a Kent Beck (uno de los creadores de XP) en Chrysler con el objetivo de llevar un proyecto (El C3) de gestión de nominas, en el cual los requisitos eran un gran problema (¡¡¡no me lo esperaba!!!…). Parece ser que el sistema legacy de nóminas era bastante infumable (más de lo habitual supongo), se trataban de varias aplicaciones, cada uno de su padre y de su madre, que hacían lo mismo en algunos casos pero de forma diferente y donde los requisitos, como no, brillaban por su ausencia. El primer año que sacaron la primera release fue muy duro. Tan duro,  que  cliente, punto de contacto de Chrysler con el proyecto, tuvo que pedir la baja por estrés.

liberar-estress

Por otro lado, mientras se cocía la historia de Chrysler y XP, ocurre una historia paralela. Los ingenieros de calidad de Netscape, tuvieron una gran ocurrencia. Estos llegaron a la conclusión de que sería bueno poder realizar construcciones del código automáticamente de forma periódica. Tenían bastantes problemas con CVS (que acaba de surgir en los 90), ya que cada vez que iban a sacar una release, el código no compilaba correctamente: “en mi máquina funciona” decían los desarrolladores.

fz1t19.jpg

Se pusieron manos a la obra y crearon una herramienta muy sencilla llamada Tinderbox que les permitía realizar una construcción diaria de su software de forma que sabían en el mismo día si había habido un problema con la construcción del mismo (la build). En poco menos de un año, se dieron cuenta que bajando la cadencia de los builds, eran capaces de saber cuál había sido el problema de integración que había roto la build (a menos tiempo, menos commits realizados y más fácil detectar el problema de fallo). Progresivamente bajaron la cadencia hasta  realizar builds automáticos cada hora. Cuando en 1998 el código de Netscape es liberado, también es difundida su forma de trabajo a la comunidad de open-source. De esta manera la construcción frecuente de tu código de forma automática pronto se convirtió en una buena práctica en el mundillo del desarrollo software.

best-practices.jpg

XP lleva las mejores prácticas a niveles extremos. Por ejemplo la práctica de hacer test antes de desarrollar fue usada por la NASA en el programa Mercury Space por primera vez para tarjetas perforadas en 1960. XP la llevo al extremo con TDD. Aunque Kent beck no se considera a sí mismo el creador de Test Driven Development, fue el que implemento SUnit, un framework de tests unitarios para Smalltalk que fueron las bases de la familia xUnit (conjunto de frameworks basados en sus premisas como nUnit, phpUnit, junit, MsUnit, etc). Este framework se pensó para realizar TDD basándose en ideas de Gerard Weinberg y Leeds, Herbert D. en su libro (Computer Programming Fundamentals – 1960). Sí, he de afirmar que es curioso que en la portada original Weingberg no aparezca. Pero eso es otra historia.

51+GmuMoPYL._SX331_BO1,204,203,200_

Otra de las prácticas que se lleva al extremo es la integración continua. Kent Beck tomó la idea de Booch, las nuevas buenas prácticas de los build automáticos con las ideas de los servidores de builds automáticos emergentes y la inclusión del framework de test automáticos que había creado para dar forma a una de las prácticas de XP: Si aquellos tipos de Netscape podrían hacer construcciones del código cada hora, ¿por qué no íbamos a poder hacerlos en cada commit y además pasar automáticamente baterías de test automáticamente con sUnit? En 1999 Kent beck publica el primer libro sobre XP donde incluye el concepto como una de sus 12 prácticas.

circles.jpg

La integración continua ha ido evolucionando a medida de que han ido apareciendo nuevas tecnologías y herramientas. Si tenemos que pensar en cual fue la primera herramienta construida para este propósito, podemos pensar que fue Cruise Control que surgió en el 2001 como servidor de builds extensible. Esta herramienta estaba pensada para realizar builds automáticos usando Ant o Maven. Funcionaba (y funciona) a través de plugins que extendían su funcionalidad. Se trata de una herramienta gratuita y open-source.  Existe una herramienta para .NET similar denominada Cruisecontrol.NET que aparece en el 2003 con su versión 0.3.1 pero no es hasta 2005 que aparece la primera versión 1.0 estable. Es decir, que la integración continua basada en herramientas específicas (no el concepto como tal), tampoco es tan lejano. Fue cuando se estrenó “Batman begins”.

Batman-Begins-batman-555782_1024_768.jpg

Hudson es otra herramienta de integración continua escrita en Java que se ejecuta en un Apache Tomcat o en el servidor de aplicaciones GlassFish. Trabaja con CVS, Svn, Git y clearcase, y puede ejecutar Apache Ant y Maven así como procesos Windows. Hudson surgió en 2008 y se convirtió en una alternativa a Cruise control y otros servidores de builds de código abierto.  El desarrollador principal de Hudson fue Kohsuke Kawaguchi que actualmente es empleado de Sun Microsystems. Si dejas a un montón de desarrolladores software el código de una herramienta como esta, pasa lo que pasa: crean una comunidad y la llevan “hasta el infinito y más allá”.

kohsuke.jpg

Cuando más adelante Oracle compró Sun, este declaró que quería registrar el nombre de Hudson y desarrollar una versión comercial. Esto enfadó mucho a la comunidad de desarrollo de Hudson, la cual decidió, junto con Kawaguchi hacer un fork del código de Hudson y llamarlo Jenkins en 2011 (ambos son nombres típicos de mayordomos). Al final Oracle se da por vencido y en 2012 dona Hudson a la fundación Eclipse. En 2013 llevan muchos commits de Jenkins a Hudson. Lo que decía yo… “hasta el infinito y más allá”.

jenkins vs Hudson java

El caso es que los conceptos han cambiado poco desde final del siglo XX, ya que siguen siendo prácticamente los mismos. Si han aparecido nuevos, es porque han aparecido herramientas que ahora lo permiten y anteriormente no, o no con la misma facilidad. De la integración continúa se pasa a la entrega continua y de ahí al despliegue automático en producción. Hoy en día existen muchas herramientas y plugins desarrollados que están trayendo nuevos conceptos y capacidades de automatización, o quizá ya no tan nuevos en el momento de publicación de este post. Algunas organizaciones, hoy en día, son lo suficientemente maduras para automatizar tanto el desarrollo software y las pruebas, que con cada commit despliegan directamente en los servidores de producción  con seguridad (pocas son) (continuous deployment). Pero eso amigos, eso, es otra historia.

continuos deployment vs delivery.jpg

PDFicono EXTENDIDO

REFERENCIAS:

[1] Continuous Integration – Martin Fowler
[2] Continuous delivery  – Martin Fowler
[3] Extreme Programing Explanined:Embrace change – Kent Beck

Libros que me recomendaron y llevo en mi mochila

A lo largo del camino de cambio y renovación que me ha llevado a romper muchos de los paradigmas en cuanto a desarrollo software se refiere, he ido recopilando una serie de libros que algunos he leído ya y otros los tengo en mi backlog personal. Son libros que siempre tienen una historia por detrás y que han sido recomendados y comentados de forma repetitiva con aquellos que he considerado mis mentores. Estos libros salieron de escenas cotidianas en trabajo, durante la comida, el café de por la mañana. Momentos de charla en los que sale el nombre de un libro o un nuevo concepto que consecuentemente nos lleva a buscar el libro que le dio origen.

escalera-libros-educacion

A Pablo se le podría describir como una persona disciplinada y altamente apasionada con la ingeniería software, le he puesto el avatar de Dark Vader Mr. Potato, primero porque desde que le conozco siempre ha tenido un Dark Vader potato encima de su escritorio y segundo porque le pega: te pega, y lo sabes.

julio_iglesias_y_lo_sabes

José no suele tener ningún Mr. Potato encima el escritorio, pero por su personalidad y su formación como coach, así como por su sabiduría y su grandes dotes como mentor, creo que el que más le encaja de los personajes es Yoda. Y curiosamente existe un Yoda Mr. Potato que viene ni que al pelo para poderlo utilizarlo como avatar.

potato-heads-4

Hay que decir que he aprendido mucho de ambos (y sigo aprendiendo), así que he creído que merecía la pena incluirlos en un post. Yo también he sido en alguna ocasión mentor, y la verdad es que siempre ha sido un orgullo ver los resultados de esos granitos que vamos dejando a lo largo del camino. Así que me ha parecido buena idea, entre broma y frikada starwars hacer una recomendación de libros y a la vez hacer mención a algunos recuerdos con ellos.

mochila

¿Qué libros llevo en mi mochila? Pues suelen ser libros que rompen con las creencias clásicas de desarrollo software. Libros que te argumentan cuál ha sido el problema del software, de la motivación o gestión de equipos en los últimos años. Libros que te abren los ojos y te hacen darte cuenta que la realidad que vivimos en muchos proyectos: tomamos decisiones incorrectas porque no entendemos cuales pueden ser las consecuencias de nuestras decisiones o de nuestra falta de las mismas.

choice.png

Flow: principles of the product development.

Donald D. Reinersten.

potato vaderPablo, no paraba de repetir una y otra vez que si lleváramos un contador en la cabeza en el que salieran euros “clink clink clink” (sonido de los euros cayendo sobre tu cabeza) tomaríamos decisiones distintas de las que tomamos habitualmente. Estamos anestesiados, decía, se nos ha olvidado pensar y estamos aquí para ganar dinero con los proyectos, algo que nos olvidamos. Un cambio de paradigma es a lo que se refería él con sus palabras, tomamos decisiones pero ¿en base a qué?, si hacemos un muestreo y le preguntamos a muchos desarrolladores de productos cuanto coste les supone un retraso en una entrega, obtendrás seguramente respuestas dispares. Y es que tan sólo el 20% sabrían calcular cuánto dinero pierde su empresa en un día de retraso. Si trabajamos para que nuestros productos se vendan, ¿por qué tomamos decisiones que nunca un economista tomaría?, porque nuestras decisiones están basadas en creencias erróneas.

el-tiempo-es-dinero640

Drive (Todo lo que no nos contaron sobre la motivación)

Daniel Pink

yodaJosé comenzaba el segundo bloque del curso de Scrum Master diciendo ¿Qué es para vosotros la motivación? Se produjo un silencio. Durante esta época estaba obteniendo la certificación de Life Coach y sabía cuán importante era jugar con el silencio con la audiencia. ¿Si os pagaran más… os sentiríais más motivados? Todos se miraron con cara estupefacta dando por hecho que la respuesta era obvia, pero José volvió a preguntar ¿cuántos reduciríais vuestro sueldo por tener más tiempo libre o mayor flexibilidad horaria? Después de cinco minutos de reflexión comenzó con la presentación. Daniel Pink, en su libro “Drive”, nos explica… Y es de siempre se ha creído que podías motivar a una persona con más dinero, y la realidad demuestra que la motivación no funciona de esa manera y mucho menos en entornos creativos. La gente que trabaja en desarrollo software le apasiona su trabajo, se divierten con él, buscan un propósito y adquirir maestría en lo que hacen. Quieren evolucionar, resolver ellos solos los problemas con autonomía. El dinero simplemente no desmotiva, pero no motiva por sí mismo.

Cyanide-and-Happiness-motivacion

Kanban.

David J. Anderson

potato vaderPablo te coge y te pone delante de una pizarra con postits. Dais un paso hacia atrás y empieza a hablarte de Flow. Fíjate como las historias de usuario avanzan, ¿Qué te dice la pizarra? ¿Qué información te proporciona? Ahora mismo tenemos demasiada variabilidad, demasiadas historias en curso, ¿en cuántas puedes focalizar tu atención? El Working In Process (WIP) es la clave, fíjate en este proyecto y en este instante tenemos acumuladas demasiadas historias en testing. Hay un cuello de botella en testing y todavía nadie se ha percatado, estamos anestesiados.

anestesiados.jpg

Agile Estimating and Planning

Mike Cohn

yodaJosé se había percatado de que el product owner había pedido que le calcularan la complejidad en cada historia de usuario a parte de la estimación en días ideales. “Juanma, ¿has pensado en utilizar tallas de camisetas para clasificar las historias de usuario?, es un concepto más fácil de entender.” José quería ayudar a Juanma a darse cuenta de que el tamaño de las historias debía reducirse para reducir a su vez el cicle time, era su objetivo, pero le había picado tanto la curiosidad de la utilización de Juanma de la complejidad y a su vez de que entendía él por complejidad. Por eso decidió aparcar por un momento el tema del cicle time. A lo largo de los años se había dado cuenta que la gente no entendía este concepto de “complejidad” para clasificar el tipo de historia. Para unos la complejidad es lo difícil que sea, para otros la incertidumbre que tengan… no parece una buena medida aunque sea recomendada por algunos Scrum Masters. Sin embargo, es más fácil el concepto de talla de camiseta, al menos para clasificar las historias de usuario.

TallasCamisetasMultilenguajeNEW

Management 3.0.

Jurgen Appelo

potato vaderyodaJosé y Pablo se juntan y empiezan a hablar de equipos auto organizados. ¿Pero como logramos que un equipo sin experiencia logre sus objetivos sin llegar a decirles que hacer? Boundaries dice Pablo, debes limitar su área de actuación, establecer límites como vallas electrificadas. Diles que pueden o no hacer y vete abriendo esas boundaries según el equipo vaya madurando. No les digas que hacer, deja que se equivoquen. Pero sólo una vez, dice José.

scrum-meets-management-30-how-to-apply-the-latest-management-ideas-to-strengthen-scrum-4-638.jpg

Guía de Arquitectura N-Capas orientada a Dominio con .NET – Domain Driven Design

Cesar de la Torre, Unai Zorrilla, Miguel Ángel Ramos, Javier Calvarro

potato vader “No quiero meterme en la arquitectura, quiero que vosotros como equipo decidáis cual es la mejor”. Primer día oficial de proyecto, estábamos siete personas en una sala y un ordenador. Se trataba de MOB programming y Pablo era el Agile Master. La única restricción que os pongo es que las capas estén bien definidas y separadas por interfaces. Test unitarios es un deber. ¿Habéis leído el libro negro? Lo necesitaréis para crear las tuberías. Tres meses de desarrollo, pair programming, teníamos una arquitectura que se adaptaba a los cambios propuestos por el cliente.

225px-Necronomicon_prop

 Inteligencia emocional

Daniel Goleman

yoda¿Por qué crees que tienes un problema de comunicación? – Dijo José mirándote fijamente y esperando ver cuál era tu reacción. Creo que era mi primera sesión o segunda sesión de coaching tratando de mejorar esta faceta. Quería ver si realmente ese problema de comunicación era un problema real o realmente era una creencia mía que debía romper trataba de generarme una disonancia cognitiva. La verdad es que todos estamos llenos de paradigmas, ideas preconcebidas que nacen de nuestra experiencia, que pueden ser ciertas o no, pero que si realmente creemos que tenemos ese problema, sea cierto o no, tenemos un problema

.coaching_session

Flow

Mihály Csíkszentmihályi

potato vaderPablo estaba concentrado en su mesa, si alguien se acercaba miraba de reojo y continuaba trabajando como si nadie existiera. Estaba en pomodoro. Durante los 25 minutos de pomodoro había decidido no ser interrumpido y lograr tener durante su jornada laboral el mayor número de momentos de flow que pudiera, momentos de máxima productividad.

pomodoro

Otros libros recomendados son Las cinco disfunciones del equipo y Agile Retrospectives. Salieron tantos que no acabaría nunca de escribir, y este post tiene que acabar en algún momento. No obstante, eso no quiere decir que no siga metiendo más libros dentro mi mochila. Espero que disfrutéis esta selección.

 PDFicono EXTENDIDO

REFERENCIAS:

[1] Flow: principles of the product development – Donald D. Reinersten
[2] Drive – Daniel Pink
[3] Kanban – David J. Anderson
[4] Agile Estimating and Planning – Mike Cohn
[5] Management 3.0 – Jurgen Appelo
[6] Guía de Arquitectura N-Capas orentada a dominio con .NET
[7] Flow – Mihály Csíkszentmihályi