En algún momento de mi vida profesional escuché que todos los desarrolladores comenzamos con un Hello World e íbamos escribiendo código de la manera que se nos hacía más fácil. Arrastrábamos controles y los conectábamos con código en code-behind de forma que nuestro código era difícil de leer, pero funcionaba.

Conocimos patrones de diseño y fuimos mejorando nuestro código, llegando al punto de no querer programar de forma sucia sin usar una buena estrategia. Después fueron las pruebas unitarias, repositorios de código, pero eso va en otro punto.

Cada día como desarrolladores estamos cambiando y es lo increíble de esta profesión. Siempre hay algo nuevo que aprender y mejorar.  Y si eso es lo mejor de nuestra profesión: ¿Por qué siempre creemos que algo que nos ayudará a mejorar la forma de entregar nuestro trabajo es malo y nos quita tiempo? Se puede resumir en tiempo y costos.

En una empresa para la que trabajé no usábamos repositorios de código y no teníamos una buena forma de enviar versiones de una app. Lo aprendimos a la mala. Creábamos versiones para cada plataforma (iOS, Android, Windows) y era tener a una persona encargada de actualizar números de versión, generar el changelogs, compilar todas las versiones y usar dos computadoras (Windows y MacOS) para hacer todo este proceso en tiempos de entregas. Posteriormente enviábamos un email al equipo de testing o cliente con las nuevas versiones en un .zip y dejarlo en limbo o esperar a que le haya llegado el email. Y el tiempo de respuesta para conocer los errores y los cambios que se necesitaba podía llegar a tomar una revisión hasta 3 días. Eso sin contar el tener que ponernos de acuerdo en ver cómo se produjo un error en la app.

Lo mismo pasa en desarrollo web: Alguien tiene que ser el encargado de actualizar los paquetes dentro del servidor IIS o si tienes la suerte de usar Azure, hacer el publish de tu proyecto. Y esto se podía poner peor: No tener las credenciales de acceso al servidor, no contar con las herramientas correctas en tu máquina local para poder hacer el deployment a producción o que la persona encargada de hacer este proceso estuviera fuera de la oficina, o de vacaciones.

Aquí es donde entra DevOps.

Si hubiera tenido las herramientas correctas hace tiempo, como desarrollador, sólo me estaría enfocando en lo que en verdad espera la empresa de mi y es generar más valor al producto desarrollando más características. O en el peor caso corrigiendo errores.

Este flujo podría mejorar iniciando con una planeación con Scrum o Agile: Separando y ordenando tareas para ir desarrollando pequeños entregables. Haciendo uso de tableros tipo Trello por nuestras tareas: dividiendo entre lo pendiente, en curso o terminado. Así tendríamos todo ordenado para saber en dónde estamos trabajando diariamente.

Usar git para administrar nuestro código y hacer revisiones de código con nuestro equipo. También incluir pruebas unitarias, ¡O incluso pruebas de UI!

Si todo esto llega a estar correcto podemos agregar herramientas de telemetría y análisis para conocer cómo nuestros usuarios usan nuestro producto y si llegase a salir mal algo o un error en nuestro código, en automático reportarlo a nuestro backlog como Bug y poder planear nuestro próximo sprint en base a estos datos.

Y así es como DevOps nos ayudaría a conocer mas sobre nuestro producto y entregarle valor a nuestro cliente.

Eso es un escenario muy brillante, pero siempre hemos tenido problemas como desarrolladores en adaptarnos a algo que es diferente y toma tiempo optimizar y aprender. Eso sin contar que nuestros empleadores siempre se oponen a querer mejorar o invertir tiempo en algo que les podría ayudar en futuro.

DevOps no tiene una definición correcta y todos creen tenerla, hasta que ven que no es la correcta. No es simple automatización de tareas. No solo hacen trabajo los desarrolladores y el área de Operaciones (o ventas, producto, etc) no tenga que estar involucrado mas que en resultados, cuando solo requieren que el equipo entregue un producto que desde el inicio estuvo mal vendido, mal estimado o mal desarrollado y que DevOps sea la salvación de ese proyecto.

DevOps, como lo menciona Donovan Brown es la unión de ambas partes (Desarrolladores y Operaciones) /incluyendo/ el producto, para dar entrega continua de valor para nuestros usuarios finales. El final del día eso es lo que tenemos y debemos entregar: Hacer que nuestro usuario final sea el más beneficiado de todo esto. Si solo se queda en un lugar, todavía no tenemos la definición correcta y no se está implementando de forma correcta.

Azure DevOps nos podría ayudar a completar estas tareas. Desde la planeación de nuestro proyecto, almacenamiento de código en repositorios git, la compilación y despliegue hacia producción y conocer más sobre el uso que le dan nuestros usuarios mediante reportes y análisis de crashes.

En otro post conoceremos más de cada producto de Azure DevOps y ver el poder de integración que se tiene.