Tradicionalmente, en las grandes compañías suele existir una división de responsabilidades muy estricta donde las tareas son llevadas a cabo por grupos muy especializados, que se acaban convirtiendo en silos. En TIC, los desarrolladores crean aplicaciones y los equipos de operaciones las despliegan en las infraestructuras que gestionan. Esta organización se ha comprobado que es ineficiente ya que se producen retrasos e imprecisiones cuando un grupo tiene que transferir las tareas al otro (ver Fig. 61).
Fig. 61 Desarrollo y Operaciones por separado [33]
Para mejorar la eficiencia y, de esta manera, reducir el coste y el Time To Market (TTM) surge el movimiento técnico y cultural DevOps, que integra las tareas de Desarrollo y Operaciones (ver Fig. 62).
65
DevOps se origina de alguna manera a partir de las metodologías ágiles [34]. Por todos es sabido que uno de los principios del proceso de desarrollo ágil es entregar software funcional en pequeñas y frecuentes entregas para aumentar el valor entregado al cliente. De esta forma, se elimina la primera grieta en el ciclo de vida de desarrollo (ver Fig. 63) pero tiene como consecuencia inmediata que al equipo de Operaciones de TIC se le empiece a acumular un elevado número de entregables para desplegar. Por lo tanto, el equipo de Operaciones no puede ir al ritmo del equipo de Desarrollo y se convierte en un cuello de botella [35].
Por tanto, se puede decir que DevOps surge como un complemento al proceso ágil de desarrollo de software, eliminando la segunda grieta (ver Fig. 63) en el ciclo de vida de desarrollo, asegurando así que el código se despliega inmediatamente en producción y no se interrumpe el proceso.
Fig. 63 Eliminación grietas en el ciclo de vida de desarrollo [35]
El flujo de trabajo (workflow) de DevOps (ver Fig. 64) consiste en desarrollar una aplicación, desplegarla, monitorizarla y aprender de su uso en producción, modificarla en respuesta a lo que se haya visto y repetir el ciclo [36].
66
Los equipos más exitosos de desarrollo pueden llegar a desplegar varias veces en un día, ya que esta es la mejor manera de responder a las necesidades del cliente. Para que sea posible, el ciclo de desarrollo y despliegue tiene que ser repetible, predecible y tan corto como sea posible para entregar valor a los clientes más rápidamente y mejorar la calidad del software. La idea es el tiempo que transcurre desde que se tiene una idea para una característica y los clientes la están usando y proporcionando feedback nuevamente, debe ser tan corto como sea posible.
Para establecer este proceso se deben seguir los siguientes buenas prácticas o patrones: automatización total, control de versiones, e integración y entrega continua
2.6.1
Automatización Total
Las tareas manuales son lentas y propensas a errores, por lo tanto, automatizar tantas como sea posible ayuda a establecer un workflow rápido, fiable y ágil [12]. La automatización de las tareas de desarrollo y despliegue de una aplicación que hace uso de una gran cantidad de servicios en la nube es si cabe más importante para evitar errores. El portal de gestión de Microsoft Azure permite monitorizar y gestionar todos los servicios. Ésta gestión es una forma fácil de crear, configurar y eliminar servicios, sin embargo no deja de ser un proceso manual. Si se van a desarrollar aplicaciones en producción, sea el tamaño que sea, especialmente en equipo, se recomienda utilizar el portal de Microsoft Azure para su gestión y después automatizar el proceso que se va a estar repitiendo continuamente. Esta automatización se puede conseguir mediante el uso de scripts en PowerShell (ver Sección 2.3.1) para los que utilicen sistemas Windows o scripts en Azure Command-Line Interface (CLI)15 para los que utilicen sistemas Linux o Mac.
2.6.2Control de versiones
Se llama control de versiones a la gestión de los diversos cambios que se realizan sobre los elementos de algún producto o una configuración del mismo. Una versión, revisión o edición de un producto, es el estado en el que se encuentra el mismo en un momento dado de su desarrollo o modificación. El control de versiones es esencial en todos los proyectos de desarrollo y no solo cuando se trabaja en equipo ya que, entre otras cosas, nos da la posibilidad de deshacer acciones y salvaguardar todo lo referente a un proyecto evitándonos perder tiempo si algo sale mal [12].
67
Aunque un sistema de control de versiones puede realizarse de forma manual, es muy aconsejable disponer de herramientas que faciliten esta gestión. En el mercado existen multitud de sistemas de control de versiones como, por ejemplo, el sistema de control de versiones distribuido Git16 o el sistema de control de versiones centralizado Team Foundation Version Control (TFVC)17.
En este sentido, Visual Studio Team Services (VSTS) proporciona una solución ALM completa, gratuita para equipos de hasta 5 usuarios, que ofrece un conjunto de servicios de colaboración con tecnología de la nube para que el equipo pueda trabajar de manera eficiente en proyectos de software de cualquier índole y envergadura [37]. Así VSTS soporta:
Sistemas de control de versiones, en concreto Git y TFVC.
Integración continua y entrega continua (despliegue) en Microsoft Azure.
Test de carga automatizados: simulan una carga de miles de usuarios posibilitando encontrar cuellos de botella antes de desplegar en producción.
Comunicación en tiempo real entre los miembros del equipo.
Gestión de proyectos ágil mediante la gestión del product backlog del producto, de los
sprints y de boards (pizarras/kanban) de tareas pendientes, realizadas y cerradas.
2.6.3Integración y Despliegue Continuo
La integración continua [38] es una práctica, propuesta por Martin Fowler, cuya base es integrar de manera automática lo más frecuentemente posible la compilación, ejecución de pruebas y despliegue de un proyecto. De esta manera, la capacidad de detectar errores se incrementa, ya que los errores se detectan en un tiempo temprano. La integración continua activa la construcción automática (que suele incluir test unitarios) de la aplicación en cuanto se produzca algún cambio en el código fuente gestionado en el sistema de control de versiones.
El despliegue continuo va un paso más allá: después que se ha construido la aplicación, se despliega en el entorno deseado. Generalmente se recomienda que se haga despliegue continuo de forma automática a los entornos de desarrollo, test y ensayo y de forma manual y controlada, tras unas pruebas de aceptación, al entorno de producción. Si no se considerase necesario un chequeo previo, se puede optar por desplegar en producción directamente.
16 https://git-scm.com
68
3
Caso de Estudio
Un caso de estudio es una técnica didáctica o investigación para el análisis y evaluación cualitativa de un fenómeno susceptible de estudio. Consiste en la descripción de una situación real o ficticia para que sea analizada para mejorar el conocimiento y habilidades en el área. Un caso de estudio aporta un toque de realismo para practicar y aprender a identificar como aplicar el conocimiento y habilidades recientemente adquiridas.