Ensayos Agiles, el tercer libro del AOC disponible en forma gratuita

Bueno, finalmente ya está camino a la imprenta el tercer libro de la serie AOC. Como de costumbre el arte de tapa estuvo en manos del habilidoso y creativo @maurostrione. La foto de la portada fue por tomada por @yamitcar.

La versión digital ya está disponible en varios formatos en forma totalmente gratuita en GitBook y la versión física sabemos que en principio estará disponible en Amazon y nos gustaría que también en algún otro lugar (estamos viendo). Muy posiblemente hagamos una impresión en alguna imprenta local y luego auto-gestionaremos la distribución a pedido.

En paralelo hemos empezado a trabajar en el audio-book.

Anuncios

Cosecha de libros

Cosecha de libros

En Mayo pasado cuando asistí a la XPConf aproveché que había una stand de venta de libros y me di el gusto de comprar un par de libros que tenía en la mira desde hace tiempo.

En línea con la idea de que en un equipo todos sus miembros deben tener un perfil tipo T (saber en profundidad de un tema y al mismo tiempo tener una idea general del resto) hay un tema particular en el que me siento especialmente flojo: Usabilidad. Por esto decidí comprar dos libros:

  • The Design of everyday things, de Donal Normal, un libro clásico, no particularmente de software sino de diseño y usabilidad en general. Me lo había recomendado @dfontde hacía ya tiempo.
  • Don’t make me think, de Steve Krug, este si es un libro específico sobre usabilidad de software. Lo había visto hacía años en la biblioteca de una empresa amiga y desde entonces lo tenía en mi wish list.

Otro tema en que me siento flojo es en testing exploratorio y por ello también me compré un libro al respecto:

Finalmente había un conjunto que libros que ya había leído (al menos parcialmente) y que como me gustaron mucho quería tenerlos en formato físico:

Entrega continua principio #1: 3 repositorios por aplicación

Creo que en la actualidad está ya claro que debemos tener un repositorio para versionar el código de nuestra aplicación. Algunos también versionan  en ese mismo repositorio la configuración de la aplicación. Para algunos casos esto puede ser suficiente, pero en contextos de entrega continua no me parece apropiado.

En primer lugar la configuración y el código tienen un tasa de cambio distinta, el código cambia mucho más rápido que la configuración. Al mismo tiempo la configuración suele variar dependiendo del ambiente en que se despliegue la aplicación. Finalmente, dependendiendo de la organización puede que la configuración del ambiente productivo sea reservada y sólo algunos miembros de la organización puedan accederla. La propuesta entonces es tener un repositorio exclusivo para almacenar la configuración de la aplicación. En particular, yo suelo crear en ese repositorio un branch por cada ambiente. Adicionalmente para facilitar el trabajo del equipo de desarrollo suelo almacenar junto al código, la configuración del ambiente desarrollo.

Finalmente necesitamos un tercer repositorio para almacenar los scripts de despliegue. La idea de poner estos scripts en un repositorio exclusivo tiene que ver otra vez con su tasa de cambio esporádica y también con el hecho de que es posible que estos scripts sean creados/manipulados por personas distintas a las que escriben el código, típicamente sysadmins.

En algunos casos particulares puede que sea necesario un cuarto repositorio, por ejemplo si uno quisiera generar modulos Puppet para automatizar el provisioning de la aplicación.

Pensándolo bien, creo que el título del artículo no es preciso, el principio es versionar todo,  el hecho de usar 3 repositorios es más bien una forma de implementarlo, que puede no aplicar siempre.

DevOps, una nueva idea no tan nueva

El término DevOps fue acuñado por Patrick Debois quien allá por 2009 organizó una serie de conferencias bajo el título DevOpsDays. El objetivo de estos eventos era incentivar una visión holística de la entrega de software derribando las barreras de la visión tradicional que separaban el desarrollo del software de su operación. A pesar que el término fue acuñando hace ya más de 5 años, creo que fue en los último 3 que tuvo un salto de popularidad potenciado entre otras cosas por herramientas como Chef, Puppet, Docker, y Vagrant y por prácticas como Infraestructura as Code, Test-Driven Infraestructure y Self-Service Provisioning.

Si bien la idea de DevOps aún hoy puede parecer novedosa para algunas organizaciones, para algunas otras siempre ha sido moneda corriente. Hablando más en concreto creo que DevOps suele resultar novedoso o incluso revolucionario para grandes organizaciones de tipo “tradicional” como bancos, telcos e incluso organismos gubernamentales. Al mismo tiempo me parece que es moneda común en organizaciones surgidas en la era de internet como .coms y startups.

Personalmente desde 2012 soy parte del equipo de Tipit, una empresa dedicada a brindar soluciones web y que adicionalmente cuenta con un conjunto de aplicaciones ofrecidas como servicio.
Tipit es una empresa chica pero que tiene bien claro que sus clientes pagan por el valor aportado al negocio y que en este contexto se traduce en software funcionando en manos del usuario. Dicho de otra forma, en términos de valor no existe la diferencia entre desarrollo y operación, la cuestión es blanco o negro: ¿está la funcionalidad lista para ser usada en un ambiente productivo o no?

Al igual que la mayoría de mis colegas en Tipit, yo trabajo tanto en tareas de desarrollo como en tareas de operaciones. Esto no implica que todos hagamos todo, todo el tiempo, sino que cada uno tiene un rol en cada proyecto pero más allá de ese rol particular que cada uno desempeña, todos somos responsables de que el software este disponible en manos del usuario cuando este lo necesite. Entre otras cosas esto requiere no dejar las cuestiones de operaciones para la última milla, sino tenerlas presentes en forma temprana, ya desde el momento del diseño de cada funcionalidad.

DevOps ¿es un realmente un rol?

Érase una época en que las organizaciones operaban como silos, con un área de desarrollo por un lado y una área de operaciones/infraestructura por otro. Estas dos áreas no sólo hablaban poco entre ellas sino que incluso en algunos casos guardaban cierto rencor entre sí. Programadores y Sysadmins enfrentados mutuamente como Vampiros y Hombres-Lobo, porque obviamente más allá de las diferencias que ellos percibían, para todo el resto de la organización eran más o menos lo mismo: gente rara del área de TI.

La adopción de métodos ágiles en las áreas de desarrollo ayudó que los desarrolladores se acercarán más al negocio y al resto de las áreas de la organización. Agile fue algo así como la sustancia que permite a Blade exponerse la luz solar y vivir más como humano que como Vampiro. Pero en la gran mayoría de los casos la fórmula de Blade no tuvo efecto en los Hombres-Lobo, quienes quedaron aún más aislados del resto de la organización.

En varias organziaciones la cuestión se puso aún más interesante cuando los equipos usando agile pretendieron salir a producción en forma frecuente. Tradicionalmente los pasajes a producción ocurrian cada un par de meses y era entonces cuando la relación entre Programadores y Sysadmins alcanzaba los picos máximos de tensión. Ahora los programadores agile pretendián ir a producción cada 2 semanas y encima contaban con el apoyo (y el entusiasmo) de la gente de negocio. Para los Hombres-Lobo esto era demasiado: ahora los Vampiros tenian el apoyo de Blade y los humanos.

Y como suele ocurrir en todas las guerras, el mayor perjudicado con todo esto era el pueblo (que en este caso era la organización). Fue en este contexto donde surgió el la iniciativa de DevOps como una propuesta para acercar a los programadores y los sysadmins y lograr que cada uno trabajé consciente de la existencia y responsabilidades del otro. Es aquí donde las implementaciones de DevOps divergen en dos estrategias.

Por un lado algunas organzaciones generan un nuevo rol al que denominan DevOp con el objetivo de mediar entre programadores y sysadmins. Si bien creo que inicialmente esta estrategia puede ayudar mejorar la situación, creo que no es más que un remiendo. Estos DevOps cuentan generalmente con habilidades técnicas mixtas, o sea son una especie de Hombre-Lobo-Vampiro y en última instancia son un bicho raro más a los ojos del resto de la organización.

Por otro lado, algunas otras organizaciones ven DevOps como una transformación en la organización mediante la cual programadores y sysadmins dejan de lado su egoísmo para trabajar colaborativamente unos con otros (al mejor estilo Saga Crepúsculo parte 3) de cara a lograr una feliz convivencia con los humanos y el resto de la organización.

Personalmente me inclino por esta segunda estrategia de DevOps aunque reconozco que en ciertos casos la primera estrategia puede resultar beneficiosa siempre y cuando quienes ocupen el rol de DevOps cuenten con habilidades blandas (gestión, facilitación, etc) más allá de las habilidades técnicas.

Nobleza obliga: la analogía con Vampiros y Hombres-Lobo está tomada de un artículo publicado por Jeff Atwood en su blog CodingHorror.com.

La calidad no es inyectable, parte 3

Finalmente hoy sí voy a referirme a los métodos ágiles. Tal como lo contamos en el capítulo 18 de Construcción de Software, una mirada ágil, el enfoque de los métodos ágiles es construir con calidad día a día. Esto no es muy novedoso pues bajado a concreto (y en forma simplificada) lo que hacen los métodos ágiles es tomar algunas de las prácticas existentes en el desarrollo de software y llevarlas un paso más allá:

  • Si las revisiones de código agregan valor, entonces directamente escribamos el código de dos (pair programming)
  • Si el feedback del usuario es valioso, entonces trabajemos más cerca de él (on-site customer) y busquemos su validación en forma periódica (iteration review)
  • Si la integración periódica nos facilita el desarrollo, entonces integremos todo el tiempo (integración continua)
  • Si el testing y la aceptación son actividades importantes para la calidad, no las dejemos para el final, integremoslas al ciclo de desarrollo de forma temprana (Definition of Done, BDD)
  • Si creemos que podemos mejorar en la forma que trabajamos, incorporemos entonces un mecanismo explícito para la mejora continua (retrospectivas)

Y sin duda podríamos seguir enumerando casos de prácticas de desarrollo que los métodos ágiles han potenciado.

Adicionalmente hay algunas otras cuestiones, que personalmente no logro identificar con prácticas pre-existentes pero que sin duda son clave en los métodos ágiles y entre las cuales destaco:

La construcción de software es una actividad intelectual llevada a cabo por personas. Si bien puede parecer una cuestión obvia resulta que curiosamente muchos enfoques de construcción de software precedentes parecen haberla pasado por alto.

Fin.

Selección de herramientas de prueba (parte 2)

En la primera entrega de esta serie presenté una arquitectura de prueba de referencia. En esta entrega voy a instanciar esa arquitectura de referencia en Ruby.

Comenzado por las pruebas del programador (unitarias y de componentes), tendremos que nuestro objeto de prueba serán clases programadas en Ruby. Para hacer este tipo de pruebas una de las herramientas más populares es RSpec la cual nos daría una arquitectura de pruebas conformada por:

  • Lenguaje de especificación: Lenguaje de Dominio Específico provisto por RSpec
  • Intérprete: es el propio RSpec
  • Driver: dado que estamos testeando clases Ruby, que estamos haciendo pruebas unitarias y de componentes y que RSpec está hecho en Ruby no requerimos de ningún driver particular. En todo caso nuestro driver es el mismo Ruby
  • Librería de aserciones: es el mismo RSpec
  • Motor de ejecución: RSpec

Un detalle a tener presente es que este tipo de pruebas son pruebas que hace el programador para sí mismo, ya sea para guiar el desarrollo (si está haciendo TDD) o bien para garantizar que sus clases se comportan acorde a lo esperado. Este tipo de pruebas no suelen interesar al usuario, pues son de índole técnica y al mismo tiempo mucho más granulares que las funcionalidades pedidas por el usuario.

arquitectura_developer_tests_ruby

 

 

Pasando ahora a las pruebas de aceptación funcionales, si bien podríamos utilizar el mismo set de herramientas, la realidad es que esperamos que el usuario esté involucrado y por ello usaremos un set distinto de herramientas de cara tener un lenguaje de especificación más “amistoso” para el usuario. Al mismo tiempo el objeto de nuestras pruebas ya no son clases sino la aplicación como un todo:

  • Lenguaje de especificación: Gherkin
  • Intérprete: Cucumber
  • Driver: dependerá de la forma en que pretendamos comunicarnos con la aplicación. Suponiendo que nos comunicamos via HTTP, podríamos utilizar Capybara en conjunto con WebDriver de Selenium.
  • Librería de aserciones: RSpec
  • Motor de ejecución: Cucumber

arquitectura_user_tests_ruby