Por qué la tecnología de colaboración de GitLab es fundamental para GitOps: una demostración
El software de colaboración como GitLab facilita los flujos de trabajo de GitOps. Este artículo incluye una demostración de cómo GitLab impulsa GitOps a través de la colaboración.
GitOps se refiere al uso de un repositorio de Git como la fuente única de la verdad (SSOT) para todo el código que se utiliza en la creación de infraestructura y la implementación de aplicaciones. Al utilizar un sistema de control de versiones, como Git, como la fuente única de la verdad (SSOT), los ingenieros pueden actualizar el código fuente subyacente para sus aplicaciones en un formato de entrega continua.
El sistema control de versiones garantiza la documentación y la visibilidad, mientras que un registro de auditoría permite el cumplimiento. GitOps facilita la reversión de los cambios y proporciona un lugar para acceder a la información más actualizada para ayudar a los equipos a comprender el estado actual desde la perspectiva de los equipos de desarrollo de software y operaciones.
GitLab es una aplicación única para todo el ciclo de vida de DevOps y sirve como una plataforma de colaboración que permite a las partes interesadas participar en el proceso de producción de código. La colaboración es un aspecto importante del proceso de GitOps, porque los equipos en todo el ciclo de vida del desarrollo, desde los equipos de infraestructura y desarrollo hasta las partes interesadas de seguridad y negocios, requieren un método a la perfección para colaborar para enviar el código de manera rápida y eficiente.
GitOps no se trata solo del código, se trata de la colaboración y GitLab permite que todos los equipos trabajen en una sola plataforma.
Este artículo incluye una demostración de cómo GitLab impulsa GitOps a través de la colaboración. La demostración cubre épicas y tickets, que están vinculados en secciones posteriores.
Planificar un proyecto con epopeyas
Dado que la implementación de GitOps se centra en el control de versiones, el primer paso es definir el alcance del proyecto e identificar a las partes interesadas. A continuación, los miembros del equipo pueden compartir cualquier otra información que pueda ser necesaria para que el proyecto se lleve a cabo, como la programación, los cambios en la infraestructura como código, los cambios que deben revisarse y, finalmente, implementarse en la producción.
Después de abrir un epic en el repositorio asociado, los equipos pueden agregar objetivos y tareas en la descripción. Una épica permite a los equipos realizar un seguimiento de los tickets en diferentes proyectos e hitos. Un ticket es el medio principal para colaborar ideas y planificar el trabajo en GitLab.
** Ejemplo de épicas y tickets **
En este ejemplo de Épicas, llamado Scale the Cloud, los equipos pueden ver el proceso detrás de la expansión de un clúster de Kubernetes en GitLab. Debido a que GitLab es multicloud, hay tres tickets separados para la demostración que articulan lo que se requiere para implementar el clúster de Kubernetes en cada entorno único: Azure (AKS), Google (GKE) y Amazon (EKS).
Fomentar la colaboración y la transparencia con GitLab
A nivel de épica, los equipos pueden ver que el ticket para escalar dentro del clúster de EKS ya se completó. Al hacer clic en el ticket, se revela que se creó una solicitud de fusión a partir de las tareas descritas en el ticket y que la solicitud de fusión ya está fusionada.
Para ver lo que cambió exactamente entre el código original y el código actual, haga clic dentro de la solicitud de fusión. Desde aquí, los equipos pueden ver todas las pruebas que pasaron antes o después de la fusión, consultar el historial de comentarios para identificar los cambios y tomar nota de quién aprobó y fusionó el código.
El ticket para escalar a GKE aún no se completó. La solicitud de fusión sigue siendo un trabajo en curso (WIP), lo que significa que aún no se ha cambiado nada. Hay un comentario sobre la solicitud de fusión de Terraform, que muestra que el recuento de nodos debe cambiar de dos a cinco nodos para preparar el entorno de GKE para la implementación. Quien apruebe la solicitud de fusión (MR) hace clic en “Resolver el estado del trabajo en curso (WIP)” para iniciar el pipeline y puede optar por eliminar la rama fuente para fusionar el recuento de nodos actualizado.
Para que GitLab sea una herramienta de colaboración efectiva, también debe ser transparente, por lo que todos en la organización pueden ver un ticket y la solicitud de fusión asociada de forma predeterminada. El ticket y el MR pueden asignarse a un colaborador, o se lo puede etiquetar a este en la sección de comentarios para agregarlo a su Lista de tareas pendientes.
Al volver a la vista de épicas, que es lo que las partes interesadas usarán a menudo para ver el progreso del proyecto, los equipos pueden ver que la implementación para adaptar GKE a cinco nodos está en curso.
Al usar GitLab para un flujo de trabajo de GitOps, todos los miembros del equipo pueden trabajar desde el mismo sistema y comprender el estado de los proyectos. Ya sea en la infraestructura o en el desarrollo de aplicaciones, todos los cambios siguen el mismo proceso: definir el cuerpo del trabajo, asignarlo a las personas, colaborar con los compañeros de equipo e implementar ese código y usar el repositorio de Git como esa fuente única de la verdad.
¿Todo listo para comenzar?
Descubra lo que su equipo puede hacer con una plataforma de DevSecOps unificada.