Respaldos y recuperación

Git y GitHub: la historia de tu aplicación

Git registra versiones del código. Cada registro, llamado commit, reúne una modificación y explica su propósito: una nueva funcionalidad, una mejora o la corrección de un problema. Así podemos comparar lo que había antes y después, identificar el cambio y recuperar una versión cuando corresponde.

GitHub es el espacio compartido donde organizamos ese historial y revisamos el trabajo. Las ramas de desarrollo permiten preparar cambios separados de la versión aprobada. Una solicitud de integración reúne las diferencias para revisarlas antes de incorporarlas a main.

Main conserva las revisiones aprobadas para las entregas. Para saber qué está realmente en producción, relacionamos cada despliegue con su commit y su imagen Docker: integrar un cambio y publicarlo son pasos distintos.

Docker: preparar una aplicación reproducible

Una aplicación necesita código, librerías y una configuración de ejecución. Docker permite empaquetar el código y sus dependencias en una imagen identificada por versión. El contenedor ejecuta esa imagen en la infraestructura preparada para el proyecto.

Esto facilita probar una entrega y trasladarla a producción conservando su contenido. La configuración específica de cada entorno y sus credenciales se suministran por separado. Los datos de los usuarios también se conservan fuera de la imagen: reemplazar un contenedor no debe significar perder la información del negocio.

La imagen Docker permite recuperar el componente de aplicación de una entrega anterior. Para recuperar el servicio completo, también necesitamos sus datos, archivos, configuración y accesos.

GitHub Actions: del cambio a la entrega

GitHub Actions ejecuta un flujo de tareas definido para el proyecto. Puede comprobar el código, construir la imagen y desplegarla. Los entornos y sus reglas permiten establecer qué ramas pueden publicar, qué permisos se utilizan y cuándo debe aprobarse una entrega. Cómo controla GitHub Actions los despliegues.

Las personas revisan y aprueban; GitHub Actions realiza el despliegue. El paso a producción sigue un flujo automatizado, en lugar de editar los archivos del servicio manualmente. Este «robot» ejecuta instrucciones previamente definidas: no decide por su cuenta qué publicar. Actúa después de las comprobaciones y aprobaciones configuradas, con permisos limitados y un registro de su ejecución.

1. Preparar el cambio

   Trabajar en una rama de desarrollo y registrar commits con la solicitud y el propósito de la modificación.

2. Revisar e integrar

   Comparar el cambio, comprobar su funcionamiento e incorporarlo a main cuando esté aprobado.

3. Construir e identificar

   Preparar la imagen Docker y asociarla con la revisión del código para reconocer exactamente la entrega.

4. Validar en la nube

   Comprobar la aplicación en un entorno de validación separado de producción, con configuración y datos adecuados para las pruebas.

5. Publicar y comprobar

   Ejecutar el despliegue con los controles definidos y verificar los recorridos principales de la aplicación.

6. Conservar la trazabilidad

   Registrar la versión publicada y conservar los componentes y las copias necesarios para una recuperación coordinada.

El flujo, las aprobaciones y las pruebas se configuran según el alcance del servicio y la infraestructura del cliente.

Trabajamos en la nube

Desarrollamos y operamos los proyectos en infraestructura de nube, con entornos de desarrollo, validación y producción separados. El equipo y el cliente pueden revisar avances en espacios preparados para cada etapa; producción atiende la operación real.

Trabajamos con Google Cloud Platform, Microsoft Azure y Amazon Web Services. Elegimos el proveedor y los servicios según los requisitos de la aplicación, las integraciones y la infraestructura del cliente. Un proyecto puede utilizar un proveedor o una combinación justificada por sus necesidades.

Google Cloud Platform

La arquitectura de recuperación se define según los componentes y los objetivos del servicio, considerando dónde conservar y restaurar las copias.

Recuperación en Google Cloud

Microsoft Azure

Los flujos de GitHub Actions pueden coordinar el despliegue en Azure, incluyendo los recursos de infraestructura definidos para una aplicación.

Despliegues en Azure

Amazon Web Services

AWS Backup permite centralizar políticas y tareas de respaldo para recursos compatibles. Su configuración depende de los servicios utilizados por el proyecto.

Respaldos en AWS

Código y datos tienen protecciones distintas

El historial de Git conserva el código. Una base de datos cambia con la operación diaria y necesita copias independientes. Lo mismo ocurre con los documentos cargados, las configuraciones y los secretos: cada componente requiere su propio mecanismo de conservación y acceso.

Acordamos cuánto historial conservar, cuánto tiempo puede tardar la recuperación y cuánta información reciente podría perderse entre dos copias. Estos objetivos se definen por servicio y se comprueban mediante pruebas de restauración.

Cómo recuperamos una entrega

1. Evaluar y coordinar

   Identificar qué componentes están afectados y acordar responsables, autorizaciones y el punto al que se quiere volver.

2. Seleccionar los componentes

   Localizar la revisión de código, la imagen y las copias de datos y archivos compatibles con esa entrega.

3. Restaurar y validar

   Recuperar en un entorno controlado de nube y comprobar integridad, accesos y funcionamiento. Una versión antigua del código debe ser compatible con la estructura de la base de datos.

4. Retomar la operación

   Coordinar el retorno al servicio, comprobar los procesos con el cliente y registrar lo realizado para mejorar el plan.

Por ejemplo, si una entrega afecta un proceso, podemos evaluar volver a la imagen anterior. Si además se dañó información, recuperar el código no basta: debemos seleccionar una copia de datos adecuada y revisar el efecto sobre los registros posteriores.