El próximo Jueves 19 de Septiembre, en el contexto del encuentro de la comunidad ágil de Buenos Aires, estaré dando la charla de referencia.
La cita es a partir de las 18.30 en las instalaciones del MUG, como siempre la entrada es gratuita pero requiere registración.
Algunos detalles más sobre la charla los pueden encontrar en la página de registración.
Una cuestión clave en todo contexto de continuous delivery son las pruebas automatizadas. De poco sirve pasar «rápido» entre ambientes, si no podemos garantizar cierta calidad de lo que estamos poniendo en cada ambiente.
Cuando uno construye aplicaciones desde cero, es relativamente fácil generar pruebas automatizadas. El uso de técnicas como BDD y TDD junto con algunos patrones de diseño permiten generar aplicaciones testeables y con alto nivel de cobertura.
Pero no siempre trabajamos sobre aplicaciones nuevas. En ocasiones nos toca trabajar con aplicaciones ya existentes, que muchas veces no cuentan con pruebas y que han sido desarrolladas sin tener en cuenta la testeabilidad. En los contextos ágiles a este tipo de aplicaciones se les suele llamar aplicaciones legacy.
Por suerte son pocos los proyectos, en los que trabajando como programador, he tenido aplicaciones legacy. Sin embargo, trabajando como consultor, me he cruzado bastante a menudo con clientes llenos de este tipo.
Mi estrategia para trabajar con aplicaciones legacy es comenzar haciendo algunas pruebas funcionales que cubran los principales flujos de la aplicación. Y luego a gradualmente comenzar a modificar la aplicación haciendola testeable y agregando distintos tipos de tests según sea posible.
Una combinación de herramientas que me ha resultado interesante para hacer pruebas funcionales es SeleniumIDE + TestNG.
Selenium IDE es una herramienta de automatización de pruebas del tipo Record & Play que funciona integrada con el explorador FireFox y permite que uno vaya recorriendo la aplicación y poniendo aserciones en determinados puntos. Luego la misma herramienta permite reproducir la prueba grabada. Si bien a primera vista la estrategia puede parecer muy interesante, la realidad es que no es tan simple. De hecho este tipo de herramientas de automatización de pruebas ha tenido varias críticas (algunas de las cuales comparto), por diversos motivos que han sido tratados, entre otros, por George Meszaros.
Por su parte TestNG, es una herramienta al estilo JUnit, pero a diferencia de esta, tiene un foco más amplio que la prueba unitaria y por ello provee algunas funcionalidades muy útiles para hacer pruebas funcionales.
A partir de estas dos herramientas, mi estrategia es:
Dos cuestiones importantes a considerar para utilizar este enfoque y que son las que abarca el punto 5 son:
Bien, esto es todo por el momento.
Como siempre, si tienen alguna consulta/inquietud, no duden en escribirme.
La semana pasada participé de un evento virtual organizado por ITSMF. Fue mi primera vez en un evento de esto tipo.
En un primer momento me sentí un poco incómodo, pues sentía que hablaba sólo y yo estoy a acostumbrado a interactuar con la audiencia en todas mis exposiciones. Pero luego de hablar unos minutos, empecé a percibir la interacción de la audiencia en la plataforma, lo cual me tranquilizó.
La sesión se realizó utilizando una plataforma específica para este tipo de eventos: Brightalk. La misma requería subir el material a exponer, en formato PPT/ODP. Luego loguearse en la plataforma como orador y desde ahi manejar la el avance de los slides. Para el audio, el orador debía conectarse vía telefónica. Al mismo tiempo, la plataforma tenia un espacio de chat y la posibilidad de hacer compulsas, dos herramientas muy útiles para interactuar con la audiencia.
Agradezco a la gente de ITSMF y en particular a Juan José (@PinkFloydF) por la invitación.
La sesión está disponible aquí.
Hace un tiempo salió publicado un artículo en InfoQ sobre el tema de referencia. Hay algunas cosas del modelo propuesto en el artículo que no me cierran pero más allá de eso creo que hay dos puntos destacados en el planteo:
Al mismo tiempo resulta que una empresa con la que estoy trabajando actualmente, ha definido su plan de implementación de Entrega Contínua basado en este modelo. En 6 meses les cuento que tal vamos.
¿Cuánto tiempo pasa desde que el usuario expresa su necesidad hasta que el software que la satisface llega al ambiente productivo donde puede utilizarlo? ¿Cuánto de ese tiempo se debe a a ejecución de procesos manuales? ¿Cuántos errores introducen esos procesos manuales? Si no tienes las respuestas a estas preguntas, o si las tienen y te gustaria mejorarlas no dejes de asistir a esta ponencia sobre Continuous Delivery.
Este es el resumen de la sesión en la que voy a estar dictando mañana, martes 14 de Mayo. Esto es en el contexto de un evento virtual organizado por ITSMF . El título de la sesión es: De la idea al ambiente de producción. La intención es presentar la práctica de Continuous Delivery surgida dentro del movimiento ágil. Voy a comenzar presentando algunas cuestiones «conceptuales» y luego hablaré de algunas experiencias concretas de implementación en las que he participado. Mi intención es mezclar un poco de teoría y poco de mundo real.
Como parte del mismo evento habrá otras dos sesiones:
La primer sesión es las 10 am (hora Argentina) y me sesión en particular es a las 12.
El evento es totalmente gratuito, pueden encontrar más detalles de la presentación y el link para registración aquí.
La semana pasado estuve trabajando en el tema de referencia. Como suele ocurrir cuando se trabaja con tecnología Microsoft, el stack de herramientas a utilizar es bastante distinto del utilizado al trabajar con tecnologias no-Microsoft.
Como build server hicimos un primer intento de usar TFS, pues el proyecto ya lo venia utilizando como repositorio de código y herramienta de gestión. Pero luego de dos problemas, desistimos y decidimos apostar a lo seguro: Team City. ¡Ja!, seguro que más de uno pensó que iba a decir Jenkins. No, hace un año aproximadamente analicé ambas herramientas y llegué a la conclusión que para ambientes Microsoft era más apropiado utilizar Team City.
Como herramienta de build usamos MSBuild.
Para realizar los pasajes entre ambientes, dado que nuestra aplicación es web, optamos por la propuesta de Microsoft: MSDeploy.
Continuará…
No quiero entrar en detalle sobre definiciones, beneficios e impedimentos relacionados a esta práctica. Creo que hay suficientes fuentes de información en la web al respecto (con solo googlear el término continuous delivery encontraremos alrededor de 18.000.000 resultados).
Asumiendo que el lector ya está familiarizado con las definiciones básicas, quiero compartir mi visión de esta práctica.
Un concepto central en la práctica de continuous delivery es el denominado Deployment Pipeline. El mismo modela el proceso de la organización para materializar la implementación de una idea/necesidad del negocio. Dos puntos a destacar:
La primera parte de este este Deployment Pipeline debe darlo el equipo de desarrollo con la implementación de la práctica de integración continua, lo cual puede llegar a ser un interesante desafío si el equipo trabaja sobre código legacy (entiéndase legacy=sin pruebas). Aquí es importante destacar que incorporar la práctica de integración continua va mucho más allá de poner un Build Server a monitorear el repositorio, compilar el código y ejecutar los tests.
La segunda parte del Deployment Pipeline es la que involucra a otros sectores de la organización, pues es la parte que recorre los distintos ambientes hasta llegar a producción.
Como comenté el lunes, estoy comenzando a trabajar con una organización en la implementación de la práctica de Continuous Delivery. La situación actual resulta por demás desafiante:
Ufff, ¡cuantas cosas! ¿por donde empezar? Personalmente me gusta empezar explicitando la visión del proyecto para asegurar que todo el mundo esté alineado y que todo esfuerzo esté en sintonia con las necesidades. En este caso, el sponsor del proyecto fue muy explícito:
«El pasaje desde el ambiente de desarrollo hasta el ambiente de pre-producción debe ser automático«
Este es un interesante punto de partida, ya que la visión habla de ambientes, comencemos hablando de ellos. Mi propuesta default suele comenzar con 3 ambientes: desarrollo, staging y producción. Y luego ajustar en caso que el contexto requiera de algo distinto.
Otros de los puntos a trabajar es la definición de la estrategia de manejo de código, lo cual incluye no solo definir una herramienta (en este caso en particular será Git) sino también la forma en que se administrará el código (en esta caso vamos a evaluar el esquema conocido como Git Flow).
El siguiente punto que me parece muy importante definir son las condiciones que debe cumplir todo incremento entregado por los equipos de desarrollo para poder entrar al ambiente de staging: porcentaje de cobertura, cumpliendo te estándares de codificación, revisión por pares, etc, etc.
Continuará…
En los últimos 2 meses me he visto involucrado en 3 iniciativas de Continuous Delivery y hoy comienzo un nuevo proyecto para ayudar a una empresa a implementar esta práctica.
En la mayoría de estos últimos casos en los que he participado, partimos de un contexto donde ya estaba implementada la práctica de integración contínua, lo cual facilita en gran parte las cuestiones técnicas. Al mismo tiempo me he encontrado que uno de los principales desafios al intentar implementar la práctica de Continuous Delivery se encuentra a nivel organizacional, ya que require de la participación de otros sectores más allá de equipo de desarrollo.
La herramienta que suelo recomendar es Jenkins con el agregado del plugin Build Pipeline, aunque tengo en mi backlog de experimentos hace un spike usando Travis para aplicaciones hosteados en Heroku.
Blog de NicoPaez 