Las herramientas técnicas

Code versioning (Control de versiones de código)

En el desarrollo informático, el código de un gran proyecto se divide en miles de archivos. Es muy probable que varios desarrolladores trabajen en el mismo archivo a la vez.

Cada desarrollador escribe su código localmente en su máquina y cuando termina, lo registra en un tronco común ubicado en un servidor remoto.

Sin embargo, si dos desarrolladores han trabajado con el mismo código en el mismo archivo, existe el riesgo de que surjan conflictos a la hora de guardarlo en el tronco común. ¿Qué código debe conservarse en ese caso? No existe un sistema de bloqueo sobre los archivos, que haga que cuando yo lo uso, los demás no puedan modificarlo. Un buen software de gestión de versiones de código es perfectamente capaz de hacer frente a este tipo de conflictos. Es la base para trabajar en equipo sin perder tiempo esperando a que los archivos estén disponibles. La referencia en este ámbito es, con diferencia, la aplicación GitHub. Este tipo de aplicación permite realizar todas las acciones que un desarrollador puede llevar a cabo en su día a día: recuperar todo el código del proyecto del tronco común y copiarlo localmente.

Esto se denomina crear el espacio de trabajo del desarrollador, donde podrá añadir, eliminar o modificar los archivos del proyecto. Una vez finalizado su trabajo, puede cargar el resultado en el tronco común. Esta acción requiere algunas comprobaciones antes de validar los cambios. Este tipo de aplicación también permite disponer de todo tipo de información sobre los ficheros: por ejemplo, quién introdujo qué código, cuándo, por qué, quién borró, quién modificó, quién hizo el café... bueno eso no, olvidémoslo, ¡tampoco nos pasemos!

Esto es una imagen de mi pantalla, donde estoy escribiendo código en el archivo ElecConsumptionController.cs.

Un proyecto puede contener miles de archivos de este tipo, con lo que el número total de líneas de código del proyecto puede superar con creces el millón. En la jerga informática, el tronco común se denomina branch Main (por rama principal) o repositorio remoto. Esta rama contiene todo el código...

Integración continua

El objetivo de la integración continua (CI) es procesar cada merge realizado en la rama Main; se integra su código con el de sus colegas.

Como recordatorio, cuando un desarrollador ha terminado su código, hace una Pull Request para enviar su trabajo. Una vez que esta PR ha sido validada, comienza la integración continua. Hoy en día, la integración continua hace mucho más que una simple integración del código (merge) en la rama Main. Después del merge, se encuentran un conjunto de filtros colocados uno detrás de otro que se ejecutarán automáticamente, uno tras otro, tan pronto como el código se fusione en la rama Main. Todos estos filtros dispuestos en una cola se denominan pipeline o workflow (flujo de trabajo) de la aplicación.

Estos filtros son, pues, elementos ejecutables (una aplicación, un script, un job, un fragmento de código, un servicio, un servicio web, un microservicio, etc.) que se ejecutarán secuencialmente en el orden en que aparezcan en el pipeline. 

El objetivo de la CI es garantizar que el merge del nuevo código en la rama Main no ha provocado ningún error, para que no construyamos un package (paquete) de entrega lleno de bugs (o errores). Hoy en día, como ya hemos mencionado, la CI se alimenta de otros tipos de control; por abuso del lenguaje, llamamos integración continua...

Despliegue continuo

Desplegar una aplicación significa instalarla en una máquina para que los usuarios puedan utilizarla. El despliegue continuo (o CD por Continuous Deployment) es el siguiente paso lógico tras la integración continua. Una vez que la canalización CI ha creado nuestro package de entrega, todo lo que queda por hacer es instalar este package en un servidor para que la aplicación pueda empezar a utilizarse.

Antes, esto se hacía manualmente, pero hoy, gracias al CD, podemos instalar nuestra aplicación sobre la marcha en cualquier entorno.

La mayoría de los sistemas de despliegue continuo requieren una larga fase de configuración para especificar los diferentes entornos en los que queremos instalar nuestro package de entrega. Una vez hecho, podemos instalar nuestra aplicación en cualquier servidor con un clic de ratón. Al acoplar un sistema de despliegue continuo con un sistema de integración continua, obtenemos el dúo CI/CD. Cuando desplegamos, podemos estar seguros de que los packages de entrega que recibimos del CI se han probado a fondo. De esta manera, se reducen considerablemente los errores que podrían haber a través de todas las pruebas.

Como hemos dicho, grandes empresas como Amazon, Facebook, Netflix, etc. han optado por desplegar directa y automáticamente el menor cambio tan pronto como se valida. El objetivo es reducir el time-to-market...

Los microservicios

Podríamos hablar de la arquitectura de microservicios durante horas, pero nos limitaremos a entender globalmente los conceptos que giran en torno a esta fantástica tecnología basada en contenedores.

El esquema a continuación describe distintas formas de ejecutar un programa:

Para ejecutar un programa informático, lo mínimo que se necesita es un ordenador con un sistema operativo (u OS, por Operating System) y un sistema de archivos. Este ordenador debe, por supuesto, tener componentes electrónicos como un microprocesador, una memoria RAM, un disco duro, etc. El sistema operativo se comunicará con todos los componentes electrónicos de la máquina para ejecutar un programa recuperado del sistema de archivos.

En términos generales, cuando usted ejecuta una aplicación, el OS carga el código de la aplicación en la memoria RAM y el microprocesador ejecuta las líneas de código del programa. En los años 90, tenía una red en casa con dos ordenadores que ejecutaban el OS Windows NT, un ordenador que ejecutaba Unix (el precursor de Linux) y una máquina AS400 que ejecutaba OS400. Todas estas máquinas ocupaban mucho espacio.

El día que las máquinas virtuales aparecieron en el mercado, pronto se solucionó el problema.

La tecnología VM o virtualización consiste en simular una o varias máquinas en una máquina real. En otras palabras, con un solo ordenador es posible tener varias máquinas, cada una funcionando con su propio OS. Cada máquina virtual instalada en el ordenador simulará otro ordenador con su propio sistema operativo. En el esquema anterior, en la columna central, hemos instalado tres VM en una máquina con Windows Server 2016: una VM con Windows Server 2012, otra con Red Hat y una tercera simulando el OS Windows 10. Así que tenemos cuatro máquinas, una real y tres virtuales. Al encender el ordenador, se iniciará Windows Server 2016 y, en la pantalla, un software como VMware (un hipervisor) mostrará las VM instaladas en el ordenador. Así, para trabajar en Red Hat, por ejemplo, todo lo que tiene que hacer es cambiar a la VM de Red Hat. Concretamente, obtendrá una ventana que simulará su entrada en un sistema Red Hat; en cierto modo, será su máquina Red Hat. Todo...