• Categoría de la entrada:DevOps
  • Tiempo de lectura:5 minutos de lectura

En 2006, con el lanzamiento de AWS Elastic Compute, Amazon inició una revolución en la forma en que nosotros, como desarrolladores, consumimos y usamos la computación y otros recursos necesarios para implementar y mantener las aplicaciones que escribimos.

No mucho después, la infraestructura como código comenzó a estallar en escena con proyectos como Puppet, Ansible y Terraform.

A medida que estas tecnologías maduraron, se hizo evidente que escalar aplicaciones en un entorno moderno o en la nube requería componentes reproducibles y reutilizables, y la infraestructura como código se convirtió en el estándar de oro para garantizar la asignación adecuada de recursos a una aplicación.

Al mismo tiempo, el espacio de la infraestructura y el mundo del software continuaron evolucionando.

El concepto de entrega y lanzamiento continuos de software se puso de moda y fue popularizado por las grandes empresas de tecnología.

A medida que la entrega continua de software se vuelve más común, se han creado nuevas soluciones en el espacio de infraestructura para mantenerse al día.

Kubernetes y el auge de la tecnología sin servidor prometieron una vez más liberar a los desarrolladores de la necesidad de preocuparse por la infraestructura.

En un mundo posterior a DevOps, ¿Cómo se piensa en la infraestructura como código y las aplicaciones como una unidad cohesiva?

La respuesta es, ingresando a GitOps.

¿Qué es GitOps?

GitOps conceptualmente no es tan diferente de la infraestructura como código o la entrega continua. De hecho, en muchos sentidos, es la convergencia de esos dos conceptos.

Los desarrolladores y los equipos de operaciones pueden compartir un repositorio común de código y GitOps permite una experiencia similar a la de un desarrollador para administrar aplicaciones y su infraestructura subyacente.

De esa manera, puedes usar GitOps como modelo operativo para infraestructuras modernas como Kubernetes, sin servidor y otras tecnologías nativas de la nube.

El control de versiones y la integración continua son herramientas esenciales para implementar software de manera continua y confiable.

GitOps trae ambas mejores prácticas de software a las operaciones al hacer que el repositorio sea la fuente central de la verdad para toda la infraestructura requerida para ejecutar aplicaciones.

Con GitOps, cualquier cambio en la infraestructura se confirma en el repositorio de git junto con cualquier cambio en la aplicación.

Esto permite a los desarrolladores y operadores utilizan patrones de desarrollo familiares y estrategias de bifurcación.

A partir de ahí, una solicitud de combinación proporciona el lugar central para colaborar y sugerir cambios.

Una vez fusionado con la línea principal, CI/CD debe configurarse para implementar automáticamente tanto la aplicación como los cambios de infraestructura.

La forma en que esto permite la sincronización entre desarrolladores y operadores es lo que puede ser muy atractivo de GitOps como la próxima iteración de DevOps.

¿Por qué GitOps?

¿Por qué tantas organizaciones grandes y pequeñas están considerando cambiarse a una cultura más centrada en GitOps?

A medida que el software se ha comido el mundo, la excelencia operativa empresarial se ha alineado directamente con la capacidad de entregar software de calidad más rápido.

La supervivencia empresarial depende de prácticas de desarrollo de software adaptables y eficientes. Esas prácticas requieren nuevos procesos y cambios en la forma en que pensamos sobre la gestión del cambio.

En muchas prácticas de software, el concepto de revisión y aprobación del código es donde entra en juego la mayoría de los controles y equilibrios para implementar el código de producción.

Los procesos y herramientas que son externos al cambio de código solo sirven para aumentar el tiempo del ciclo e inhibir la capacidad de una organización para implementar el código rápidamente.

Una vez que una organización ha adoptado la integración continua y la revisión de código como el lugar para la aprobación de la solicitud de cambio, es una progresión natural discutir la idea de la entrega continua a producción después de que se superen las puertas de CI y las aprobaciones humanas.

A medida que GitOps lleva ese concepto un paso más allá e integra la tubería a la producción directamente en el flujo de trabajo de solicitud de combinación y git, se ha convertido en un tema candente y se convertirá en el flujo de trabajo normal para las organizaciones de software eficientes.

Quitar las herramientas y los pasos innecesarios de la ruta crítica hacia la producción permite que una organización entregue mejores productos más rápido, sin sacrificar la gobernanza necesaria para implementar el código.

Compartir es Vivir!

Comparte tu opinión