El origen de DevOps

Tenía pensado sacar algunos posts en relación a DevOps y pensando creo que puede ser buena idea por comenzar por los orígenes. Creo que hoy en día se confunde mucho DevOps con el uso de herramientas, lo cual es una parte importante, pero no es todo.

DevOps es un movimiento originado en 2007, cuando Patrick Debois, un consultor freelance, estuvo analizando el sector IT. Su objetivo principal era ganar experiencia en todas las perspectivas en la cadena de valor IT. Tiene un blog bastante interesante.

En 2007 mientras Debois estaba en un proyecto de consultoría para el gobierno de Bélgica para la migración de un data center se frustra debido a los conflictos que se producían entre desarrolladores y administradores de sistemas. Debido a esto él decide proponer una solución.

En Agosto del 2008, en Agile2008 conference, Andrew Clay Shafer y Patrick Debois se conocen. Shafer habló sobre la “infraestructura Agile” y sólo una persona atiende: Patrick Debois. Shafer, al ver que no había más que un asistente, piensa que no había interés en este tema salta esta sesión y Debois más tarde tiene con una larga conversación en el pasillo sobre el tema.

De esta y otras conversaciones surgieron todas las típicas frustraciones y conflictos que existen entre operaciones y desarrollo, así como sus motivos. Ambos crearon un grupo en Google denominado “Agile System Administrators” creado para continuar el debate.

devops_timeline

En 2009 John Allspaw y Paul Hammond presentan “10 deploy per Day”en la O’Relly Velocity 09 Conference. La principal premisa era enfocarse en asegurar que Dev y Ops trabajaban juntos y de forma crossfunctional a través de las herramientas y procesos ágiles.

Esto inspiró a Debois creando el evento “DevOpsDays” en Bélgica (DOD). Decide hacer exactamente lo que indica la charla y toma de aquí el concepto DevOps (Dev and Ops Cooperation at Flickr). La conferencia de puertas abiertas tiene lugar en Octubre de este año y se continua la discusión vía Twitter. El movimiento empieza a surgir.

Al mismo tiempo, la integración continua está en su momento de auge dentro del espectro Agile. Y había mucho movimiento en cuanto al continuous deployment sobre todo con la aparición del libro “Continuous delivery”.

Mientras en paralelo la industria IT empiezan a tener fuerza otras metodologías como Operation Management, Lean e IT service management.

Este movimiento formado por debates, conferencias, twitter y  lentamente tomó atención de la industria. IBM, CA Technologies, HP y BMC empiezan a aplicarlo.

En una entrevista de InfoQ en Abril del 2012, Debois admite que el nombre no fue intencional, que simplemente el título original era muy largo y escribió “DevOpsDay” para acortar. De aquí emergió el nombre DevOps.

Por otro lado, la similitud entre las palabras “Debois” y “DevOps” siempre me ha parecido un dato, al menos curioso.

Por ahora esto es todo. Espero que os haya aclarado al menos el origen.

 

 

TDD, BDD, ATDD,sus orígenes y diferencias

Hoy en día, sin lugar a duda, sabemos los beneficios que nos ofrece utilizar TDD en nuestros desarrollos. Del mismo modo, también conocemos bastante bien que Behavior Driven Development es un enfoque interesante para combinar con TDD. Algo que suele quedar más oscuro es  ATDD (Aceptance Test Driven Development) ¿Habías escuchado alguna vez hablar de ATDD? En este post veremos los orígenes de TDD, ATDD y BDD, así como sus diferencias.

TDD_ATDD_HISTORY

La época clásica proviene del sector espacial

Entre 1959 y 1963 se estaba desarrollando el software para el programa Mercury. Se trataba del primer programa de vuelo espacial tripulado por humanos de los Estados Unidos. Toma el nombre del dios romano Mercurio y su objetivo era poner a un humano en órbita y devolverle a la Tierra a salvo.

Se seleccionó como sistema informático el IBM 7090 que era un computador de gran tamaño (Mainframe), el cual funcionaba con tarjetas perforadas.

El hecho es que este tipo de computadoras tardaban tanto en ejecutar que empezaron a realizar pruebas de cada una de las sentencias para, tras su ejecución, poder verificar que los resultados habían sido correctos. Esto se empezó a considerar una buena práctica: realizar las pruebas antes que la codificación o más bien durante la propia codificación. Esto se le llamó Test First y fue descrito en aquella época por el visionario Gerald M. Weinberg en su libro Computer Programming Fundamentals.

Los 90’s fueron el renacimiento del desarrollo software

En 1989 Kent Beck recordaba haber leído el libro Computer Programming Fundamentals cuando le estaba dando vueltas a como mejorar con buenas prácticas el desarrollo de un software de nóminas para Chryslter . Piensa que con la tecnología actual de los 90 podría irse un poco más allá. Este proyecto es el Chrysler Comprehensive Compensation project y sus primeros pasos fueron tan desastrosos que motivaron a Kent Beck hacia búsqueda de una manera diferente de desarrollar software. Una manera basada en unos valores que chocarían con las prácticas habituales.

En 1994, Kent Beck,  escribe la primera versión de sUnit (precursor de la familia xUnit) con la idea de hacer Test Driven Development. En estos años se desarrollan las prácticas de Extreme programming y en 1999 se publica el primer libro de XP (Extreme Programming explained).

En el año 2000 se funda www.junit.org por Object Mentor (Empresa de Robert C. Matin – Uncle Bob) y se creaba el concepto de xUnit como familia de frameworks de test unitarios.

Empieza el siglo XXI y el foco es agile

En 2001 17 críticos , entre ellos Kent Beck, del modelo tradicional de desarrollo software se reúnen en Snowbird (Utah). En esta reunión surge el término “métodos ágiles” para definir aquellos “métodos” que surgían como alternativa a otros considerados muy pesados y rígidos por su carácter normativo. Principalmente críticas a Waterfall (Modelo en Cascada).

De aquí surgieron unos principios y valores que compartían todas aquellas metodologías que empezaron a denominarse en ese momento “ágiles” en contraposición a aquellas más “pesadas”. Se empezó a conocer más  Scrum, Crystal, FDD, Extreme programming (XP)  como alternativas a las metodologías “pesadas” que eran vistas como recetas que hay que seguir al pie de la letra. Si es cierto que todavía se sigue utilizando mal el término “metodología”, quizá por inercia, pero todas estas “metodologías ágiles” no son recetas sino conjuntos de buenas prácticas que suelen combinarse entre ellas para crear una metodología concreta. Por eso TDD, que es una práctica de XP, se empieza a utilizar en la mayoría de las metodologías ágiles, surgiendo la necesidad de consultores y formadores como Dan North, del que hablaremos un poco más adelante.

Ward Cunningham es un ingeniero software que desarrolló la primera Wiki. Es un pionero de los patrones de diseño y de XP junto con Kent Beck.  Se trata de un ingeniero que visto florecer TDD desde sus inicios, y al darse cuenta de que hay un vacío metodológico entre la descripción de la necesidad de usuario y el comienzo de desarrollo mediante TDD, piensa en una solución y surge Fit (Framework for Integration Tests) en 2002. En 2005 Robert C. Martin mejoró esta herramienta creando Fitneese.  La metodología utilizada junto con estas herramientas es ATDD (Aceptance Test Driven Development)  la cual está pensada para combinarse con TDD.

Casi al mismo tiempo (2006-2009) surgió JBehave con el objetivo de combinarse con TDD. Se trata del primer framework para aplicar una técnica llamada BDD.  Esta técnica fue nombrada por primera vez en el blog de Dan North. Dan North fue más allá creando un lenguaje de especificación que modelaba el comportamiento (Gherkin). Esta técnica empieza a ser útil para mejorar la comunicación entre aquellos que definen el qué (historias de usuario) y los que implementan el cómo mediante TDD. Además fomenta la aparición de un lenguaje ubicuocomún entre desarrollo y negocio, algo que se potencia con DDD.

¿Pero cuál es la diferencia entre ATDD, BDD y TDD?

TDD (Test Driven Development) es una técnica de desarrollo que se basa en Test First y Refactoring. La técnica se basa en comenzar creando una prueba unitaria que cubra “aquello que queremos implementar”. Esta prueba inicialmente fallará, por lo que debemos ir modificándola y creando el código (Clases y métodos) que vamos necesitando hasta que la prueba funciona.  Una vez la prueba ha funcionado realizamos una refactorización y volvemos a crear otra prueba unitaria que cubra otro aspecto de “aquello que queremos implementar”. Se trata de un proceso iterativo e incremental a través del cual el diseño emerge. Hay mucho más por detrás, pero creo que es un resumen bastante aproximado de la técnica.

Como observáis, no hemos hablado de requisitos, historias de usuario o criterios de aceptación, sino de “aquello que queremos implementar”. El desarrollador con TDD está pensando en el “cómo” basándose en el “qué”. Esto hace que tenga que hacer el ejercicio de diseñar una solución para que ese “qué” sea cubierto por su “cómo”. Lo normal en estos casos es que la historia de usuario sirve como guía de conversación para resolver el problema, pero la comunicación no era efectiva del todo debido a que negocio y desarrollo no suelen hablar el mismo lenguaje, a veces no hay una comunicación fluida, etc. Este vacío se salva con ATDD.

ATDD (Acceptance Test Driven Development) es una metodología de desarrollo que fomenta la comunicación entre los clientes, los desarrolladores y los testers. Podríamos utilizar frameworks como fit, fitness, cucumber o simplemente un framework xUnit para implementar esta técnica. ATDD se basa en que las necesidades de usuario son cubiertas con escenarios (llamados ejemplos) que son el pegamento entre lo que debe hacerse y cómo debe hacerse. A medida que esas pruebas se crean nos faltan piezas, empezamos a pensar en “aquello que queremos implementar” y aplicamos TDD.

Por otro lado, BDD (Behaviour Driven Development) es una técnica que emerge para complementar TDD como una necesidad. Mientras que ATDD  no habla de comportamiento ni lenguaje ubicuo. BDD permite especificar un comportamiento utilizando un lenguaje casi natural denominado Gherkin. Esas especificaciones, automáticamente se convierten en pruebas. BDD se puede aplicar cuando hacemos ATDD, es decir, uno es técnica y otro es una metodología.

Las diferencias entre ATDD y BDD pueden ser un poco confusas. Existe un libro bastante conocido Specification by Example, que dice que ATDD,  BDD y otros términos, son distintos nombres para referirse a la misma metodología. Por cierto, un libro muy recomendable que habla en detalle de las prácticas y de todo el proceso de ATDD. Por otro lado, otro libro conocido ATDD by Example coincide, añadiendo que también podemos conocerlo con el nombre de Specification by Example, Story Testing o Agile Acceptance Testing.

BDD y ATDD

Mi humilde opinión

Para mi, resumiendo mucho, podríamos decir que TDD  es una práctica de diseño a nivel de clases de la que emergen test unitarios. BDD es otra práctica que se va a ocupar de las pruebas funcionales donde vamos a tener unas especificaciones o documentación viva con un idioma que es entendible por los usuarios (lenguaje de negocio). La forma de construir estas especificaciones, creadas en formato de ejemplos, se debería realizar de forma colaborativa utilizando por ejemplo la técnica de los tres amigos donde se reúne alguien de negocio, alguien de desarrollo y alguien de pruebas para construir estos escenarios juntos ya que BDD fomenta la conversación sobre todo combinado con example mapping.

ATDD se centra aun mas en profundizar en discernir que lo que se esta haciendo no solo se hace en forma correcta, sino que también es lo correcto a hacer. Para llevar a la práctica ATDD podríamos utilizar BDD o no.

Aunque este es mi punto de vista, hay mucho debate sobre las diferencias. Podéis echar un vistazo aquí y aquí.

Además en cuanto a TDD y BDD, mucha gente comenta que para ellos es lo mismo. Para mi eso es bastante dicutible y seguramente la explicación merecería un post completo. Para mi, no son lo mismo y si lo son, y esto depende de tu punto de vista. Existen 2 escuelas conocidas de TDD, una es la clásica y otra es la llamada Mockista (escuela de Chicago y escuela de Londres). Son dos tendencias distintas de hacer TDD donde la escuela Mockista, se centra más en el comportamiento y la clásica en el estado del objeto.

Para los mockistas todo gira en base al comportamiento de los objetos ergo todo es BDD, los clásicos te dirán que no. Dicho esto, quizá tenga que escribir un post para hablar en más profundidad de este tema, ya que aparte de interesante, esta explicación se me queda bastante corta.

Y tú, ¿qué opinas?