Compartir a través de

Experiencia de desarrollador de bucle interno para equipos que adoptan GitOps

En este artículo se describe cómo un marco de desarrollo de bucle interno establecido puede mejorar la productividad del desarrollador para los equipos que adoptan GitOps con clústeres de Kubernetes habilitados para Arc o Azure Container Service (AKS).

Marcos de bucle de desarrollo interno

Los equipos de desarrollo nativos de la nube que trabajan con contenedores pueden beneficiarse de un sólido marco de bucle de desarrollo interno. Los marcos de bucle de desarrollo interno ayudan en el proceso iterativo de escribir código, construir y depurar.

Las funcionalidades de los marcos de bucle de desarrollo interno incluyen:

  • Automatización de pasos repetitivos, como compilar código e implementar en el clúster de destino.
  • Capacidad mejorada para trabajar con clústeres remotos y locales, y compatibilidad con la depuración de túneles locales para la configuración híbrida.
  • Capacidad de configurar un flujo personalizado para la productividad basada en el equipo.
  • Administración de las dependencias de microservicios.
  • Recarga activa, reenvío de puertos, registro y acceso al terminal.

Según la madurez y la complejidad del servicio, los equipos de desarrollo pueden elegir entre las opciones de configuración del clúster para acelerar el bucle de desarrollo interno:

  • Todo local
  • Todo remotos
  • Híbrido

Muchos marcos admiten estas funcionalidades y hay varias ofertas de mercado disponibles, como DevSpace, Scaffold y Tilt.

Transición del bucle interno al bucle externo

Después de evaluar y seleccionar un marco de desarrollo de bucle interno, puede construir una transición fluida del bucle interno al bucle externo.

Como se describe en el escenario de ejemplo de CI/CD mediante GitOps, un desarrollador trabaja en el código de la aplicación dentro de un repositorio de la aplicación. Dicho repositorio de aplicaciones también contiene plantillas de Helm o Kustomize de implementación de alto nivel.

Las canalizaciones CI/CD:

  • Generar los manifiestos de bajo nivel a partir de las plantillas de alto nivel, agregando valores específicos del entorno.
  • Crean una solicitud de incorporación de cambios que combina los manifiestos de bajo nivel con el repositorio de GitOps que contiene el estado deseado para el entorno específico.

Se pueden generar manifiestos similares de bajo nivel localmente para el bucle de desarrollo interno, mediante el uso de los valores de configuración locales del desarrollador. Los desarrolladores de aplicaciones pueden iterar los cambios de código y usar los manifiestos de bajo nivel para implementar y depurar aplicaciones. La generación de manifiestos de bajo nivel se puede integrar en un flujo de trabajo de bucle interno con la configuración local del desarrollador. La mayor parte del marco de bucle interno permite configurar flujos personalizados, ya sea mediante la extensión a través de complementos personalizados o mediante la inserción de la invocación de scripts basada en enlaces.

Ejemplo de flujo de trabajo de bucle interno creado con el marco DevSpace

Para ilustrar el flujo de trabajo del bucle interno, podemos ver un escenario de ejemplo. En este ejemplo se usa el marco DevSpace, pero se puede usar el mismo flujo de trabajo general con otros marcos.

Este diagrama muestra el flujo de trabajo del bucle interno.

Diagrama que muestra el flujo del bucle interno.

Este diagrama muestra el flujo de trabajo para la transición de bucle interno a bucle externo.

Diagrama que muestra la transición del bucle interno al bucle externo.

En este ejemplo, nuestro desarrollador de aplicaciones:

  • Crea un archivo devspace.yaml para configurar el bucle interno.
  • Escribe y prueba el código de la aplicación mediante el bucle interno para comprobar su eficacia.
  • Realiza la implementación en el almacenamiento provisional o en producción con el bucle externo.

Para actualizar, ejecutar y depurar la aplicación, ya sea en un clúster local o remoto, el desarrollador de aplicaciones realiza los pasos siguientes:

  1. Actualiza la configuración local del entorno de desarrollo representado en el archivo .env.

  2. Ejecuta devspace use context y selecciona el contexto del clúster de Kubernetes.

  3. Selecciona un espacio de nombres con el que trabajar mediante la ejecución de devspace use namespace <namespace_name>.

  4. Itera los cambios en el código de la aplicación e implementa y depura la aplicación en el clúster de destino mediante la ejecución de devspace dev.

  5. Se ejecuta devspace dev para generar manifiestos de bajo nivel en función de la configuración local e implementa la aplicación. Estos manifiestos de bajo nivel se configuran con ganchos DevSpace en devspace.yaml.

    • Dado que DevSpace permite la recarga en caliente, utilizando la sincronización de archivos para copiar los cambios más recientes dentro del contenedor, el contenedor no tiene que volver a generarse para cada cambio de código.
    • La ejecucióndevspace dev también implementa cualquier dependencia configurada en devspace.yaml, como las dependencias de back-end a front-end.

  6. Comprueba los cambios accediendo a la aplicación a través del reenvío configurado a través de devspace.yaml.

  7. Una vez finalizados los cambios, se depura la implementación ejecutando devspace purge y creando una solicitud de cambios nueva para fusionar los cambios en la rama de desarrollo del repositorio de la aplicación.

Nota:

Encuentre el código de ejemplo para este flujo de trabajo en nuestro repositorio de GitHub.

Pasos siguientes