Categoría: concepts

No más .dlls en Git: infraestructura de desarrollo .Net

Una y otra vez me encuentro con equipos de desarrollo trabajando con tecnología .Net que guardan .dlls (librerías/packages) en repositorios de código fuente. Esto fue una práctica común en una época (lejana) y que yo mismo utilicé en algún momento. Pero desde la aparición de NuGet la gestión de librerías en en mundo .Net tomó un camino distinto.

Cuando uno tiene una dependencia de una librería a nivel binario, simplemente declara la dependencia en un archivo package.json y la herramienta NuGet se encarga de buscarlo en el repositorio binario y descargarlo. NuGet por default busca las librerías/paquetes en https://www.nuget.org/. Sin embargo hay dos casos donde seguramente no encontremos la librería en este repositorio:

  • Si estamos usando librerías de terceros, puede que por algún motivo esos terceros no hayan publicado el correspondiente paquete en nuget.org y dependiendo del tipo de licencia del paquete puede que no tengamos derecho a publicarlo nosotros mismos en un repositorio abierto.
  • Por otro lado es muy común hoy en día con el auge de los microservicios que uno tenga librerías propias que utilice en diversos proyectos de la organización y a menos que nuestros proyectos sean open source, es poco probable que querramos publicar esas librerías en nuget.org

Entonces, para estos dos casos la estrategia a seguir es utilizar un repositorio privado de binarios ya sea on-prem (instalando por ejemplo un Nexus) o utilizando algún servicio en la nube (como por ejemplo myget).

Si ponemos todo esto en contexto, una arquitectura de desarrollo de referencia podría incluir:

  • Un servidor de repositorios de código fuente, por ejemplo alguna implementación de Git como GitHub, GitLab o BitBucket.
  • Un servidor de CI/CD como Jenkins o TeamCity
  • Un servidor de repositorios de binarios NuGet como Nexus, MyGet o Artifactory

Simplificando el setup de Jenkins con Docker

A la hora de hacer el setup de Jenkins hay diversas cuestiones que resolver las cuales pueden variar dependiendo del contexto. En términos muy generales esas cuestiones se resuelven:

  • operando directamente sobre Jenkins, por ejemplo para instalar plugins
  • o bien operando sobre el servidor en el cual Jenkins está corriendo, por ejemplo para instalar un SDK

La importancia que se le da al primer punto es muy variable y depende de si se trata de un «Jenkins Silvestre» (Jenkins manejado por un equipo de desarrollo sin ningún tipo de soporte organizacional) o si se trata de un «Jenkins Corporativo» que es administrado por un grupo de la organización.

Pero el segundo punto, es algo central si pretendemos utilizar Jenkins para buildear. Si queremos utilizar Jenkins para buildear C#, tendremos que asegurar que el servidor donde corre Jenkins tenga el correspondiente SDK instalado (o eventualmente necesitaremos un Jenkins Slave que tenga el SDK.) Esta situación se repite para cada tecnología/lenguaje que uno pretenda buildear. Más allá de la tarea de instalar el SDK en si misma, el punto es que hay que loguearse en el servidor para llevarla a cabo. Una forma de simplificar este setup es utilizar Docker. O sea, en lugar de instalar los SDK en el servidor de Jenkins, uno instala simplemente Docker y luego utiliza un contenedor Docker que contenga el SDK que cada proyecto requiera. Al mismo tiempo esto simplifica el escenario donde tenemos proyectos con dependencias de SDK que tiene conflictos entre si.

A mi parecer esta estrategia aún no está muy difundida pero me parece que a mediado plazo se impondrá como estándar de facto. De hecho, las últimas versiones de Jenkins (las que vienen nativamente con el plugin de Pipeline 2.5 o superior) simplifican mucho este setup. Basta con tener Docker instalado en el servidor de Jenkins y declarar la imagen builder a utilizar en nuestro Jenkinsfile.

El siguiente fragmento de código muestra un job de Jenkins que utiliza una imagen de node 8.9. Lo que hace es trivial, simplemente invoca node –version y escribe el output en un archivo de texto. Lo interesante es que el archivo de texto resultante queda dentro del workspace del job, o sea: Jenkins se está encargando de «sacar» el archivo que se genera dentro del contenedor Docker.

node {

    docker.image('node:8.9-alpine').inside {

        stage('Test') {

            sh 'node --version > version.txt'

        }

    }

}

Refactoring .Net applications: How-to NuGet

 

Let’s say you have two .Net applications: A and B and a shared component C. From a source code versioning point of view you could have:

  1. RepoFor(A, B, C)
  2. RepoFor(A, B) and OtherRepoFor(C)
  3. RepoFor(A, C) and OtherRepoFor(B)
  4. RepoFor(B, C) and OtherRepoFor(C)
  5. RepoFor(A)  and RepoFor(B) and RepoFor(C)

Except for scenario (1), all the other scenarios would require to clone more than repo, and at the same you could have additional issues when dependencies AC and BC are established at source code level.

The «elegant way» of solving this situations is to establish the dependency at binary level, that is: A and B should depend on C.dll not on C source code. So to do that you need NuGet.

NuGet is a package manager for .Net that will allow to publish packages containing .dlls (and some other stuff too).

The following diagram illustrates the suggested solution:

nuget

Here are 2 short videos I recorded to show how to create and publish NuGet packages.

 

Practicas DevOps: Monitoreo

Una problemática común para aquellos que trabajamos en el mundo del software es la disponibilidad de nuestras aplicaciones. En primera instancia es imprescindible entender las necesidades de disponibilidad que debe cumplir nuestra aplicación. Esto es una definición que viene dada por una restricción del negocio. En ese sentido hay aplicaciones que solo deben están disponibles en horario de oficina (de lunes a viernes a 9 a 18), mientras que hay otras que puede que solo requieran estar disponibles ciertos días por mes. Y obviamente también están aquellas aplicaciones que tienen que estar disponibles 7 x 24. Esta es una cuestión de negocio que tiene un impacto enorme en las cuestiones técnicas. Desde el punto de vista de desarrollo tenemos que tomar cierta precauciones en el diseño y codificación de nuestra solución. Al mismo tiempo también debemos observar ciertas cuestiones en lo que respecta a la arquitectura física de la solución. Finalmente debemos tener presente una serie de cuestiones operacionales como ser backups, failover, escalamiento, etc. Como consecuencia de varias de estas cuestiones surge la necesidad de ser capaces de detectar una interrupción del servicio ANTES que se entere el usuario final.  Más aún, lo ideal es detectar en forma anticipada una posible interrupción para intentar evitarla. Esto implica implementar una estrategia de monitoreo.
Cuando hablamos de monitoreo tenemos distintos niveles:
  • Capa 1: hardware / sistema operativo, aquí miramos cpu, memoria, disco, red, etc.
  • Capa 2: middleware, aqui miramos métricas particulares del midddleware como ser métricas de la JVM, del web server, la DB, etc
  • Capa 3: aplicación, aquí miramos cuestiones más concretas cercanas al dominio de nuestra app. Incluyo aquí tiempo de respuesta, tiempo de carga de las páginas, y también cuestiones como cantidad de usuarios con sesión activa, etc.
Para monitorear cada una de estas capas hay distintas alternativas. Cuando uno corre con una infraestructura de cloud, el proveedor de cloud típicamente provee monitoreo de capa 1. El monitoreo a este nivel es transparente para la aplicación.
Para capa 2 el monitoreo también puede hacerse de forma transparente, y las herramientas para hacerlo dependen en gran medida de cual sea nuestro middleware, o sea, no es lo mismo monitorear tomcat que nginx. Una herramienta de uso común aquí es Nagios (aunque Nagios también puedeusarse en capa 1).
Para capa 3 implementar monitoreo requiere algunos ajustes a nivel de aplicación, o sea, las soluciones tienen cierto grado de intrusión en nuestra aplicación y suelen requerir algunos cambios en nuestro código. Las soluciones son diversas y pueden mezclase. Un caso típico es utilizar Google Analytics para medir tiempos de respuesta y permanencia de los usuarios en ciertas páginas.
Obviamente existen algunas soluciones que proveen la posibilidad de monitorear las 3 capas de manera unificada. A mi parecer la solución más popular a en este segmento es New Relic.
Por otro lado el monitoreo implica 2 cuestiones centrales:
  1. Recolección de datos
  2. Ejecución de acciones ante determinadas situaciones. De mínima tenemos el envió de alertas, pero también podríamos activar acciones de escalamiento.
Lo mencionado anteriormente sobre los niveles de monitoreo aplica a la recolección.  Respecto de la acciones a ejecutar, ahí también tenemos diferencia en la solución de monitoreo elegida. En este sentido, si la aplicación va a estar disponible 7×24, es posible que el envío de mails no sea suficiente y tengamos que echar mano de mensajes a directos a un teléfono de guardia.
Continuará…

BDD, ATDD y SBE ¿es todo lo mismo?

En la actualidad nos encontramos con estos 3 acrónimos que en muchas ocasiones son utilizados como sinónimos y cuya diferencia no es del todo clara. Más aún, en Una Mirada Ágil los mencionamos a modo informativo sin entrar en mayor detalle pues consideramos que en esencia todos apuntan a lo mismo: la importancia central del trabajo colaborativo entre técnicos y la gente del negocio para especificar la funcionalidad a construir utilizando ejemplos concretos. Y también todas ponen el aspecto colaborativo por encima del aspecto técnico (ejecución automatizada).

Personalmente creo que las principales diferencias radican en que cada uno de estos términos surgió como consecuencia de distintas líneas de trabajo que se desarrollaron en paralelo con distintos protagonistas, todos ellos trabajando principalmente desde la industria y bajo un paradigma de desarrollo ágil. Más allá de los argumentos que pueda tener cada uno de los protagonistas para insistir con su terminología creo que adicionalmente hay una cuestión natural de «orgullo» (y posiblemente también de negocio/marketing) que en cierto modo dificulta la unificación de terminología. Como suele decirse: «Cada maestro con su librito».

Más allá de esto quisiera dedicar algunas líneas a cada propuesta en particular:

Behaviour-Driven Development (BDD)

Este es el término posiblemente más utilizado en la actualidad, muy asociado a la familia de herramientas Cucumber y cuyo mayor referente es Dan North. El mismo North define BDD como:

BDD is a second-generation, outside-in, pull-based, multiple-stakeholder, multiple-scale, high-automation, agile methodology. It describes a cycle of interactions with well-defined outputs, resulting in the delivery of working, tested software that matters. 

Resalto aquí el hecho de considerar BDD una metodología lo cual es posiblemente la mayor diferencia (a nivel de marketing al menos) con las otras técnicas.

Acceptance Test-Driven Development (ATDD)

Sin duda el punto inicial de todo esto fue TDD, cuya concepción original por Kent Beck era levemente distinta a la actual. Inicialmente Beck hablaba tanto de prueba unitarias como de usuario (customer tests en términos de XP), pero con el correr del tiempo el término TDD fue tomando una connotación unitaria, o sea, en la actualidad TDD se interpreta casi exclusivamente como UTDD (Unit Test-Driven Development). De ahí la necesidad de utilizar el término ATDD para referirse explícitamente a un ciclo de más alto nivel en el cual está involucrada la gente de negocio. Una curiosidad es que Beck en su libro TDD by Example menciona ATDD, pero como acrónimo de Application Test-Driven Development en lugar de Acceptance que es el término utilizado en la actualidad.

Specification by Example (SBE)

Este es el término impulsado por Gojko Adzic y personalmente es el que más me gusta. No porque proponga algo muy distinto, sino simplemente por la terminologia que propone. En el prefacio de su libro Specification by Example Gojko propone una terminología y explica porque la terminología alternativa comúnmente utilizada no le resulta apropiada.

Finalmente no quiero dejar de mencionar que hay algunos otros términos que también suelen utilizarse como sinónimos y que en esencia son lo mismo pero cuya popularidad es mucho menor. Entre ellos se encuentran Story Test Driven Development (STDD) y Example-Driven Development (EDD).

BDD, ATDD y SBE ¿es todo lo mismo? Si.

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.

Continuous: Integration vs Delivery vs Deployment

En los últimos dos años he repetido incontables veces la diferencia entre estas tres prácticas y dado que no encontré ninguna explicación online que me satisfaciera, he decidido escribir mi propia explicación.

Continuous Integration: el software suele desarrollarse en equipo, donde cada miembro trabaja en su máquina en una porción del software. En ese contexto, la práctica de Continuous Integration propone integrar de forma continua el trabajo realizado por cada miembro del equipo. Esto implica una serie de cuestiones como ser el uso de controlador de versiones y contar con un ambiente de integración donde puedan ejecutarse verificaciones sobre software integrado.

Continuous Delivery: en términos organizacionales esta práctica es poner en manos del negocio la decisión de cuándo ir a producción. Más concretamente eso implica que cada build exitoso pueda (si el negocio así lo decide) ir a producción. entiéndasee build como el artefacto resultante del proceso de integración)

Continuous Deployment: está práctica va más allá de Continuous Delivery e implica que cada build exitoso va automáticamente a producción. Tal como propone Jez Humble, un mejor nombre para esta práctica sería Continuous Release. Continuous Deployment implica Continuous Delivery pero no al reves.

Estas tres prácticas tienen un aspecto técnico relacionado a herramientas y aspecto humano relacionado a hábitos y reglas que las personas deben incorporar y que personalmente considero que es el mayor desafío a la hora de intentar implementar estas prácticas. Ejemplo: de nada sirve tener un controlador de versiones si los miembros del equipo hacen commit una vez por día.

El orden en que describí cada práctica tiene que ver con el orden natural de adopción de las misma. Cabe aclarar cada práctica puede implementarse con distintos «niveles de profundidad» los cuales dependerán del contexto de cada proyecto/organización.

Muchas veces al explicar estas prácticas la audiencia tiende a decir que quiere implementar Continuous Delivery ante lo cual suelo aclarar: «No todas las prácticas son necesarias para todo contexto» y a continuación pregunto: «¿Su negocio realmente necesita continuous delivery?» En determinados contextos tener Continuous Delivery puede ser imprescindible para que el negocio sea competitivo, mientras en otros contextos (posiblemente más estables a nivel de negocio), sea simplemente un nice-to-have.

Como comentaba un amigo que trabaja en la industria petrolera: «Nosotros tenemos 3 releases anuales planificados e inamovibles», en un contexto así posiblemente no se justifique el esfuerzo que implica adoptar continuous delivery. Distinto es el caso de un negocio muy variable que requiere de cambios constantes en sus aplicaciones donde no tener Continuous Delivery podría implicar perder el negocio.

Por su parte la práctica de Continuous Integration tiene algunas particularidades respecto de las otras dos prácticas. En primer lugar, es una práctica higiénica, lo cual implica que en términos generales siempre debe utilizarse. En segundo lugar es una práctica «a puertas cerradas» en el sentido que su uso está complementamente en manos del equipo de desarrollo. No es necesario aprobación y/o interacción con personas de otras áreas de las organización ni con el usuario. Si bien puede ser útil tener ayuda del grupo de infraestructura para montar un servidor de integración continua, la realidad es que no es algo imprescindible, el propio equipo puede montar un servidor de integración continua en la máquina de alguno de los miembros del equipo o bien podría utilizar algún servicio online (como Travis o CloudBees).

Para quienes quieran profundizar les recomiendo es artículo de Jez Humble: Continuous Delivery vs. Continuous Deployment.

Para cerrar les comparto un par de imagenes (de mi autoría) que esquematiza la diferencia/relación entre estas prácticas.

ci_y_cd

 

cd_y_cd

Selección de herramientas de prueba (parte 1)

Una de las decisiones a tomar al querer hacer pruebas automatizadas es qué herramientas utilizar. Para poder tomar esta decisión resulta importante entender mínimamente la arquitectura de una infraestructura de pruebas automatizadas. El siguiente gráfico resumen de forma muy general una arquitectura de modelo para esta problemática.

arq_pruebasSi bien el gráfico puede sugerir una arquitectura de capas, la misma rara vez se cumple a nivel de implementación pero si es cierto que para elemento representa un nivel de abstracción distinto en la estructura de la solución.

En el nivel de abstracción de más alto tenemos un lenguaje de especificación que nos permite expresar la prueba.
Un ejemplo de un lenguaje posible de especificación podría ser Gherkin.

En un segundo nivel tenemos un intérprete de ese lenguaje
que nos permitirá relacionar la especificación abstracta con fragmentos de código que escribiremos nosotros y que comúnmente se denominan «glue code».
Para el caso Gherkin tenemos como intérpretes las familia de herramientas Cucumber, en particular si quisieras escribir nuestro código en Java podríamos utilizar Cucumber-JVM.

En el tercer nivel tendremos un componente que denominamos **driver** que nos permitirá interactuar con nuestra aplicación. Lo que hace el driver en concreto es implementar el protocolo de comunicación necesario para interactuar con el sistema bajo prueba.
Siguiendo con el ejemplo anterior y asumiendo que el sistema bajo prueba es de tipo web, podríamos entonces utilizar Selenium Web Driver el ofrece una implementación en Java.

El siguiente elemento de nuestra arquitectura es la librería de aserciones, la cual nos permitirá precisamente hacer aserciones sobre el resultado de las operaciones realizadas sobre el sistema bajo prueba.
En este caso es común utilizar alguna librería de la familia xUnit. En el caso de Java utilizaríamos JUnit.

Finalmente, como último ítem de esta enumeración tenemos un motor de ejecución que se encarga de instanciar y ejecutar los elementos previamente mencionados.
En este caso una alternativa muy común en el mundo Java en particular es utilizar el mismísimo JUnit.

En la segunda parte de este artículo ofreceré algunos ejemplos concretos de implementación de esta arquitectura.

Métodos de clase

Conceptualmente los métodos de clase son métodos que tienen la particularidad de pertenecer a la clase y no a las instancias de la clase. Por esto es que para invocar a un método de clase no es necesario crear una instancia de la clase que contiene el método.

En aquellos lenguajes cuya sintaxis deriva de C, los métodos de clase se identifican con la palabra clave static y de ahí que en ocasiones se los llame métodos estáticos. Conceptualmente desde la POO creo que este nombre no es correcto pues mezcla una cuestión conceptual con un detalle de implementación de algunos lenguajes particulares.

public static doFoo() {
..
}

En Ruby, los métodos de clase de clase, se los identifica en su definición con el prefijo self.

def self.doFoo
...
end

El Smalltalk (pharo) los métodos de clase son definidos en un compartimento particular.

class_methods

Sobre el tamaño de los proyectos y los equipos en agile

Este es un tema que suele prestarse a debate cuando se habla de métodos ágiles. En diversas ocasiones he escuchado afirmaciones tales como:

Los métodos ágiles no sirven para proyectos grandes.

o

En mi equipo no podemos aplicar métodos ágiles porque somos 50 personas.

Quiero dedicar algunas líneas para desmistificar estas cuestiones.

Respecto del tamaño de los proyectos, en primer lugar debemos dejar en claro qué define el tamaño de un proyecto: ¿mucho presupuesto? ¿mucho alcance? ¿mucha gente?. Podríamos decir que el tamaño de un proyecto está dado por su alcance. Naturalmente la cantidad de personas involucradas y el presupuesto del proyecto suelen ser proporcionales al alcance del mismo.

Aclarado qué entendemos por tamaño, podemos entonces preguntarnos ¿existe alguna limitación de tamaño para aplicar métodos ágiles? La respuesta es no. Entonces ¿puedo hacer proyectos de cualquier tamaño usando métodos ágiles? Tampoco.

La cuestión pasa una vez más por el desarrollo iterativo incremental y los ciclos de feedback. En este sentido la propuesta del agilismo es particionar un proyecto grande en varios proyectos pequeños, trabajando en forma iterativa con versiones incrementales que incorporen el feedback en forma temprana.

¿Y que hay del tamaño de los equipos? La respuesta a esto se deriva del párrafo anterior, si trabajamos en proyectos chicos tendremos entonces equipos chicos. Suele  decirse que el tamaño de un equipo debe ser tal que lo puedas alimentar con dos pizzas.