En UbiqWare, nos centramos en ayudar a otras organizaciones a que su actividad en torno a la fabricación de software y su operación sea lo más eficiente posible. Para ello, utilizamos DevOps como modelo de referencia.
DevOps es una filosofía, inicialmente acuñada por Patrick Debois al dar el nombre devopsdays a una conferencia sobre agilidad, desarrollo y operaciones, tras el éxito de una presentación sobre el tema en la conferencia Agile Toronto 2008. Dicha filosofía organiza el ciclo de vida del software en ocho fases, como ilustra la siguiente imagen.
En las próximas publicaciones en este blog, contaremos cómo desde UbiqWare contribuimos a la mejora en la gestión del ciclo de vida del software de nuestros clientes y socios, indicando en detalle nuestra aproximación a cada una de las ocho fases. Por ello, os brindamos a continuación un resumen muy breve de las tareas que ayudamos a llevar a cabo en cada una de ellas.
- PLAN: La planificación de un proyecto consiste en trasladar los requisitos proporcionados por el cliente a tareas de proyecto (ítems de la pila de producto, en términos de Agilidad), comprobando el cumplimiento de los requisitos a partir de la completitud de las tareas de proyecto definidas para satisfacer cada uno de éstos. Si, además, definimos los criterios de aceptación de las tareas a través de pruebas de software (si se pueden ejecutar de forma automatizada, mejor), estaremos haciendo Desarrollo Guiado por Pruebas. Un ejemplo de herramienta de planificación ágil de proyecto sería Jira, que se ve muy bien complementada por Confluence, la solución de gestión documental basada en wiki del mismo fabricante.
- CODE: Una vez tenemos definida una tarea, es necesario implementarla. En el caso de software, esto implica “codificarla” o trasladarla a código fuente. El código fuente de nuestro proyecto software (o de un componente de nuestro proyecto, si está organizado por ejemplo en frontend y backend) lo entregaremos a un repositorio de código. Generalmente, utilizaremos Git como tecnología de referencia para mantener repositorios de código. Aplicaremos también algún flujo de trabajo, como Git Flow, para organizar las contribuciones de los miembros del equipo y para desencadenar ciclos de integración continua. Obviamente, debemos asegurarnos de que el código sea implementado con sentido. Por ello, observaremos todas las buenas prácticas propias de la Ingeniería del Software, con el pertinente análisis del código por parte de expertos humanos y la ayuda siempre bienvenida de herramientas automáticas de análisis de calidad del código (por ejemplo, SonarQube). Un ejemplo de proveedor de repositorios Git es GitLab (y algo más que eso, pues es una solución integral para la gestión de proyectos software basada en DevOps).
- BUILD: Una vez tenemos código fuente en un repositorio, deberíamos ser capaces en cualquier momento de construirlo para poder ser ejecutado. Para ello, se utilizará un servidor de construcción (build server), que permitirá construir software en las mismas condiciones (usando siempre la misma versión de sistema operativo, de compilador -en el caso de utilizar un lenguaje de programación de alto nivel que debe ser traducido a un lenguaje ejecutable de más bajo nivel- o de las herramientas de asistencia a la construcción necesarias -preprocesadores, ofuscadores, etc.-). De esta forma, evitaremos las consecuencias que alguna vez hemos sufrido al “generar el software cada uno en su equipo”. El uso de un build server va a permitir automatizar ciclos de integración continua (BUILD-TEST), de entrega continua (BUILD-TEST-RELEASE) y de despliegue continuo (BUILD-TEST-RELEASE-DEPLOY). Jenkins, CloudBees, GitLab CI/CD, Azure Pipelines o AWS CodePipeline son ejemplos de tecnologías de CI (integración continua) y CD (entrega y despliegue continuos).
- TEST: Una vez nuestro software ha sido construido, debemos ejecutar todas las pruebas del software razonablemente posibles, recomendando especialmente la inversión en pruebas automáticas, siendo conscientes de que hay pruebas que sólo un humano puede resolver (de momento J ). Las pruebas del software son un aspecto de la ingeniería de software que da para muchos artículos, y así esperamos hacerlo próximamente. Selenium, Jasmine, JUnit or NUnit son algunos frameworks de automatización de pruebas para distintas tecnologías de desarrollo.
- RELEASE: Una vez nuestro software ha sido probado, es “digno” de ser registrado en un repositorio de artefactos, en el que se almacenan las sucesivas versiones del software que se van generando. Un artefacto es un entregable binario a partir del cual podemos instalar o desplegar software. Algunos ejemplos son archivos .jar o .war (Java), .msi o .exe de instalación de software en Windows, paquetes NPM de aplicaciones web o bibliotecas JavaScript, ficheros .zip, etc. . Nexus, Artifactory, AWS CodeArtifact, Azure Artifacts or a Docker registry, such as Docker Hub, are examples of artifact repositories.
- DEPLOY: A partir de un artefacto, podemos copiar el mismo a un entorno de ejecución e instalar o desplegar la aplicación en el mismo, para que comience a funcionar. Este tipo de proceso suele estar automatizado en un paso al efecto en un ciclo de despliegue continuo en cualquiera de las tecnologías listadas en la fase BUILD, o cualquier otra similar.
- OPERATE: Los entornos de ejecución deben estar correctamente dimensionados y configurados para garantizar un funcionamiento correcto del software. Generalmente, se trabaja al menos con cuatro:
- Entorno de desarrollo (los equipos informáticos de cada miembro del equipo de desarrollo).
- Entorno de pruebas (p.e., ejecutando en él la última versión del software disponible en las ramas develop de los repositorios de código involucrados en nuestro proyecto).
- Entorno de pre-producción (que replica el entorno de producción tan fielmente como se pueda, ejecutando la última versión del software en la rama main/master en los repositorios del proyecto).
- Entorno de producción (con la última versión en main/master).
Las aproximaciones basadas en una gestión ágil de la infraestructura TI, con la gestión de la infraestructura como código a la cabeza (IaC, Infrastructure-as-Code), van a facilitar adaptar la misma a contextos cambiantes del negocio y de la propia tecnología, ya sea en proveedores cloud como en entornos on-premise. Cualquier sistema operativo (Linux, Windows, MacOS, etc.) ejecutado de forma nativa o bien dentro de cualquier tecnología de virtualización, entornos de ejecución de contenedores como Docker, tecnologías de gestión de clusters de contenedores como Kubernetes, o proveedores cloud (que añaden servicios serverless a sus servicios de virtualización), como AWS o Azure, son ejemplos de tecnologías y proveedores de infraestructura.
- MONITOR: Esta es una de las fases a las que desgraciadamente se le presta menos atención, siendo vital medir cómo estamos rindiendo para determinar cuellos de botella en cuya resolución centrarnos y en comprobar que nuestra gestión del ciclo de vida del software es cada vez mejor, a través de la adopción incremental de DevOps. En futuros artículos veremos cómo monitorizar el rendimiento (funcional y no funcional) del software que fabricamos, el rendimiento de la infraestructura TI sobre la que nuestro software se ejecuta, y lo bien (y mal) que estamos rindiendo como equipo en torno a la metodología de gestión de proyecto y a la filosofía DevOps, examinando los indicadores de todas las herramientas de asistencia a la gestión del ciclo de vida del software.
Nuestros próximos artículos irán comentando en detalle acerca de cada una de las fases, de herramientas utilizadas en algunas de ellas, de casos de éxito y también, como no, de algunos casos de fracaso (que a veces aportan incluso más).
