Llegamos a ustedes gracias a:



Columnas de opinión

Cómo llevar a cabo ciclos de desarrollo y lanzamiento más cortos

[05/02/2019] Antes de agile, scrum y devops, el desarrollo de software a menudo se realizaba durante ciclos de lanzamiento de varios meses. Esto se debía, en gran parte, a que la complejidad en los requisitos funcionales, integraciones, la arquitectura de la aplicación, herramientas de desarrollo e infraestructura dificultaban llevar a cabo ciclos de desarrollo más rápidos. Incluso cuando el desarrollo agile se convirtió en un proceso de desarrollo generalizado y las herramientas de desarrollo mejoraron, las organizaciones se centraron en los ciclos de lanzamiento que oscilaban entre varias semanas a unos pocos meses.

Hoy en día, los equipos de desarrollo que han implementado pipelines de integración y entrega continua (CI/CD) están tomando medidas para acortar sus ciclos de lanzamiento de aplicaciones. La integración continua automatiza la compilación y da inicio a las automatizaciones de prueba, mientras que la entrega continua automatiza los impulsos de código y los procesos de entrega a un entorno de desarrollo o prueba específico. Los dos procesos, cuando se gestionan con herramientas como Jenkins, TravisCI, CircleCI, Azure Pipelines o AWS CodePipeline; automatizan la colaboración y los pipelines que se requieren para una entrega de aplicaciones más rápida y más frecuente.

Pero tener CI/CD no es suficiente. También requiere cambios en los procesos de negocios, la cultura y otras prácticas técnicas. Echemos un vistazo a algunos detalles.

Determine por qué se necesitan ciclos de desarrollo más cortos

Ir más rápido tiene algunas ventajas comerciales y técnicas. Permite un tiempo de comercialización más rápido, especialmente cuando las aplicaciones proporcionan un valor competitivo; permite una mejora significativa de la productividad; impulsa una fuerza laboral más feliz o proporciona otras mejoras de usabilidad. También puede reducir el riesgo cuando las implementaciones tienen menos cambios y es menos probable que tengan problemas o dependencias imprevistas. Las organizaciones con prácticas devops muy maduras, que operan en áreas híper competitivas pueden hacer operativas las implementaciones continuas, la práctica adicional de implementar en la producción varias veces al día.

Pero ir más rápido tiene un costo en la maduración de los procesos técnicos y empresariales que permiten conducir de forma segura a una velocidad más rápida. Además, la implementación continua puede no ser la respuesta correcta para su negocio o aplicación, especialmente si afectan los flujos de trabajo fundamentales, operan en entornos regulados, o son tecnologías que impactan la vida.

Así que, antes de apretar el acelerador, es importante hacerse algunas preguntas y que los equipos de negocios y tecnología alineen las motivaciones:

  • ¿Por qué ir más rápido?
  • ¿Cómo mejorar más rápido las experiencias de los usuarios?
  • ¿Qué tan rápido es lo suficientemente rápido?
  • ¿Se puede medir el impacto de entregar lanzamientos más frecuentes?
  • ¿Cuáles son los riesgos y preocupaciones en el despliegue que se tiene con más frecuencia?
  • ¿Qué otros negocios y prácticas técnicas necesitan acelerar en paralelo para soportar la velocidad más alta?
  • ¿Cómo sabrá la organización si los despliegues son demasiado frecuentes?

Una vez que se respondan estas preguntas, tendrá más claro en qué prácticas enfocarse y qué nivel de madurez se requiere.

Las pruebas automatizadas y las prácticas de seguridad mejoran la confiabilidad

El hecho de que su automóvil pueda recorrer a 150 kilómetros por hora no significa que las carreteras sean seguras para conducir tan rápido. Esto también es válido para el desarrollo de software; así que, tanto las pruebas automatizadas como la seguridad integrada deben formar parte del pipeline de CI/CD para garantizar que las versiones sean válidas para la implementación de producción.

Para evaluar las pruebas, considere la posibilidad de catalogar una lista completa de casos de prueba que deberían automatizarse. La lista debe ser amplia y abarcar la funcionalidad de la aplicación, las APIs, las integraciones y los procesos en segundo plano. También debe haber volumen y variedad de datos de prueba estadísticamente significativos que puedan usarse para recorrer estos casos de prueba.

Una vez que estén catalogados, se pueden usar como un punto de referencia. ¿Qué porcentaje del catálogo tiene pruebas automatizadas? ¿Cuánto tiempo se tarda en realizar estas pruebas?

Si se automatiza un alto porcentaje de las pruebas y el costo de ejecución es bajo, es un indicador de que pueden integrarse en el pipeline de CI/CD y utilizarse para validar ciclos de lanzamiento más frecuentes.

Para la seguridad, los equipos deberían usar los principios del proyecto OWASP para diseñar aplicaciones seguras. Si la aplicación se despliega en Azure, revise e implemente las prácticas de validación de seguridad de CI/CD de Microsoft. Los usuarios de Jenkins pueden integrar plug-ins para realizar pruebas de penetración, llevar a cabo análisis de código estático, escanear bibliotecas de código abierto y otras pruebas de vulnerabilidad. Si la aplicación utiliza contenedores, implemente las prácticas de seguridad de Docker, revise las mejores prácticas de seguridad de Kubernetes, y considere estas siete herramientas de seguridad de contenedores.

Preparación operativa para implementaciones más frecuentes

Incluso cuando la aplicación está diseñada para implementaciones más rápidas y frecuentes, todavía existe trabajo por hacer en el extremo operativo, para poder soportar esta frecuencia y velocidad.

Lo último que deberían hacer los tecnólogos es lanzar aplicaciones con mayor frecuencia, sin tener una defensa sólida de monitoreo de aplicaciones para detectar y ayudar a resolver problemas de producción. Los usuarios no van a admitir implementaciones frecuentes, si éstas crean inestabilidad o degradan el rendimiento. Al igual que las pruebas automatizadas, los monitores de aplicaciones también requieren una cobertura suficiente para garantizar que los centros de operación de red (NOC) sean alertados de forma proactiva cuando no se está ejecutando toda o parte de una aplicación.

Con las alertas implementadas, las organizaciones de TI deben revisar los procedimientos para manejar la respuesta a incidentes. Si un gran porcentaje de incidentes empieza a escalar a los desarrolladores, el aumento de la frecuencia de lanzamiento puede abrumarlos y causar una disminución en la velocidad de desarrollo general.

También es una buena idea evaluar qué analítica web o móvil está habilitada y está siendo utilizada por los equipos de negocios y tecnología. Lanzar software con más frecuencia y no medir los resultados ni obtener información sobre el uso, es como conducir a ciegas. Los equipos deben tener visibilidad sobre si sus cambios están proporcionando impactos positivos a los usuarios.

Definir conjuntos de características mínimamente viables

Los equipos pueden tener todas las prácticas técnicas listas para implementaciones más frecuentes, pero si los propietarios de productos agiles solicitan funciones complejas que requieren mayores esfuerzos de desarrollo, es más difícil lanzar más rápido y con más frecuencia.

En estas situaciones, preguntar a los propietarios de productos sobre sus requisitos es un buen comienzo. Proporcionar estimaciones agile para ilustrar la complejidad y la línea de tiempo de las características solicitadas, puede abrir un cuadro de diálogo sobre cómo encontrar formas de simplificar los requisitos o encontrar la solución. Tenga en cuenta que la mayoría de los propietarios de productos prefieren nuevas características y mejoras para los usuarios con mayor rapidez, por lo que proporcionar opciones y nuevas ideas puede dar como resultado mejores soluciones para los usuarios y más fáciles de implementar.

Además, algunos equipos de desarrollo buscan implementar indicadores de características, pruebas canario y pruebas A/B para controlar cuánta nueva funcionalidad está disponible, cuántos usuarios obtienen acceso inicial, y si la nueva funcionalidad está mejorando la experiencia del usuario. Tener estas capacidades incorporadas en el proceso de desarrollo y la arquitectura de la aplicación es una herramienta altamente estratégica para validar el diseño de características y permitir ciclos de lanzamiento más frecuentes.

Desarrolle una competencia principal comunicando los lanzamientos y cambios de aplicaciones

Es posible que los equipos de desarrollo no estén al tanto de todos los procesos empresariales relacionados con las versiones de software. Los lanzamientos que enfrentan o afectan a los clientes, a menudo requieren comunicación con los usuarios sobre nuevas funciones, cambios en la documentación y, en ocasiones, la ejecución de un plan de marketing completo.

Los usuarios de aplicaciones empresariales tienen expectativas similares y desean notificaciones antes y después de los lanzamientos. Además, si la aplicación produce feeds de datos o expone APIs, se debe notificar a los desarrolladores internos y externos que consumen estos servicios.

Las organizaciones que implementan aplicaciones regularmente deben considerar hacer que las comunicaciones proactivas formen parte de los procesos empresariales y técnicos. Esta es la mejor manera de asegurarse de que los usuarios estén conscientes y se adapten a un proceso de lanzamiento más frecuente.

Isaac Sacolick es el autor de Driving Digital: The Leader's Guide to Business Transformation through Technology, que cubre muchas prácticas como agile, devops y ciencia de datos, que son fundamentales para los programas de transformación digital exitosos. Sacolick es uno de los CIO sociales más reconocidos, blogger desde hace mucho tiempo en Social, Agile and Transformation y CIO.com, y presidente de StarCIO.