Sigue tu propio camino con GitLab
Compartir en redes sociales
Sigue tu propio camino con GitLab
Val Naipaul
23rd enero, 2024
10 min de lectura
Val Naipaul
23rd enero, 2024
10 min de lectura
Ir a la sección
Ir a la sección
Enfoques habituales
Enfoque propuesto
¿Y qué ocurre con Auto DevOps?
Si trabajas en la parte de plataforma o de DevOps y te encuentras ante una migración o implementación de GitLab (SaaS o autogestionado), verás que GitLab tiene muchos botones aquí y allí.
De hecho, es una plataforma completa que cubre todas tus necesidades con su propio SCV central, canalizaciones de CI/CD, gestión de paquetes, análisis de composición de software y capacidades de planificación, entre otras más funciones.
Pero ¿necesitas implementar todas sus funciones para lograr tus objetivos? Especialmente si ya tienes GitLab Runners en la nube afectando a tus finanzas.
En este blog, te proponemos un enfoque para planificar una migración o implementación de GitLab que ofrezca valor a las partes interesadas pronto y ayude a los equipos a interactuar con GitLab en sus propios términos, sin tener que ir a toda máquina.
Enfoques habituales
Antes de comentar el enfoque que proponemos para una migración o implementación de GitLab, vamos a mencionar algunos enfoques habituales para tener más contexto, quizá alguno de estos sea el más adecuado para ti.
Big bang (migración)
El enfoque big bang implica iteraciones de análisis, configuración, ETL y validación, posiblemente utilizando contenido fuente representativo al principio, progresando hasta llegar al contenido fuente completo y culminando en una migración final a modo de “big bang”.
El principal beneficio es un punto de transición claro para todas las partes involucradas, aunque el valor diferirá hasta alcanzar dicho punto. La naturaleza iterativa de este enfoque puede crear también ineficiencias estructurales, en forma de gastos generales en torno a las iteraciones de migración.
Incremental por fases (migración)
En un enfoque incremental, el contenido de origen se divide y migra en incrementos. Si bien se puede hacer de forma iterativa, como con el enfoque del big bang, sus iteraciones son más manejables.
Desde un enfoque por fases, las capacidades del entorno de destino se activan por fases, y cada fase se basa en la anterior.
Con estos dos enfoques, el valor se obtiene antes que con el método del big bang, pero tanto las plataformas de origen como las de destino están activas durante un período prolongado; desde el primer incremento o fase hasta la última, lo que puede resultar molesto y confuso.
Ingeniería de plataformas con autoservicio (migración/implementación)
Con el enfoque de ingeniería de plataformas con autoservicio, un equipo de expertos sienta las bases (configuración, automatización y protección) que permitirán a los equipos de desarrollo aprovechar GitLab, ya sea migrando contenido, incorporando o creando nuevos proyectos mediante plantillas permitidas y avaladas.
Aunque este enfoque puede funcionar sin un marco para una experiencia estandarizada del desarrollador; es decir, una plataforma interna para desarrolladores (IDP, por sus siglas en inglés), al basarse en el conocimiento compartido y la disciplina de equipo, realmente brilla con uno. Las opciones de IDP incluyen Backstage, Compass, Venue.sh y el propio GitLab.
Enfoque propuesto
Un enfoque revolucionario de migración o implementación de GitLab que prioriza el valor
El enfoque que proponemos prioriza la entrega de valor a las partes interesadas, a la vez que marca el ritmo de la implementación para garantizar un compromiso sólido entre los usuarios y GitLab.
Por ejemplo, si tus equipos están impacientes por usar GitLab Review Apps para colaborar (y así reducir sus gastos de infraestructura), quizás deberías considerar las integraciones de repositorios externos como una opción de Review Apps antes de que se haya completado la migración de los repositorios de Git o incluso antes de iniciarla.
Si bien acelerar el lanzamiento puede tener sentido en algunos aspectos, también puede ser beneficioso ralentizar otros, como reflejar automáticamente las incidencias procedentes de una herramienta de planificación existente en GitLab Team Planning. Esto permitirá a los desarrolladores adaptar la migración a su propio ritmo de trabajo, con un nivel de interrupción mínimo.
Por cierto, aunque no se suele utilizar en el contexto de la implantación o migración de plataformas, la filosofía de “Shift Left” es el núcleo de este enfoque. De este modo, enriquecerás tu plan teniendo en cuenta las distintas partes interesadas y sus preocupaciones (por ejemplo, el coste o la experiencia de los desarrolladores), así como las preocupaciones normales que supone la implantación o migración de plataformas.
Principios generales
Este enfoque consiste en identificar primero tus criterios de éxito con GitLab y luego priorizar cada uno de ellos en función de tres atributos:
- Importancia/urgencia o “tamaño”
- Coste de la implementación
- Tracción (el capital humano, la experiencia y el compromiso necesarios)
Proceder con la migración o la implementación de acuerdo con las prioridades determinadas aportará valor a las partes interesadas antes, al tiempo que fomentará el compromiso de los equipos con GitLab.
Establecer tus criterios de éxito.
¿Con qué criterios se medirá el éxito (según todas las partes interesadas, no solo según tu equipo)? Establece al menos dos criterios, pero no más de cinco.
Tus criterios, como las conocidas métricas DORA, pueden asociarse con DevOps. Pero recuerda que estamos hablando de tu entorno: ¿predominan las preocupaciones de seguridad y cumplimiento?, ¿existe un interés significativo por el rigor y la transparencia en torno a las pruebas?
Prioriza tus criterios de éxito y combínalos con las funciones de GitLab
Para cada criterio de éxito:
- Asigna un número para representar el tamaño relativo, utilizando 1 como el más bajo (los criterios más importantes/urgentes tienen mayor prioridad). Deja espacios entre los criterios para representar mejores valores relativos; por ejemplo, 1, 2, 3, 5, 10.
- Asigna un número que represente el coste relativo de la implementación (incluidas herramientas y procesos) para pasar del estado actual al estado de destino (con respecto al criterio), utilizando 1 para el nivel máximo (los criterios con menor coste de implementación son más prioritarios). Para el estado de destino, piensa a corto y medio plazo, pero recuerda que debes tener un poco de ambición: llegar allí debe parecer un logro.
- Asigna un número que represente la tracción relativa, utilizando 1 para la menor (los criterios con mayor tracción merecen mayor prioridad). Pregúntate si dispones del capital humano, la experiencia y el compromiso necesarios para obtener beneficios.
- Ahora clasifica el criterio frente a los demás según el tamaño, coste y tracción del producto, de modo que las prioridades más altas tengan un número más alto.
- Identifica las características de GitLab que te podrían ayudar (o entorpecer) y explica cómo. Empieza con un criterio inclusivo y perfecciónalo según sea necesario, posiblemente consultándolo con las partes interesadas.
Por ejemplo:
Criterios de éxito: Colaboración
- Tamaño: 5
- Coste: 4
- Tracción: 4
- Valor: 80
Funciones relevantes de GitLab
- InnerSourcing con una jerarquía de grupos mínima
- Saca el contenido sensible de los repositorios y activa Secret Detection para ayudar a InnerSourcing (y mejorar la seguridad)
- Técnicas de composición de canalizaciones, como la reutilización de canalizaciones usando plantillas, componentes de CI/CD y el catálogo de CI/CD
Criterios de éxito: costes operativos
- Tamaño: 1
- Coste: 3
- Tracción: 3
- Valor: 9
Funciones relevantes de GitLab
- Review Apps para entornos de prueba efímeros
Criterios de éxito: costes operativos
- Tamaño: 3
- Coste: 1
- Tracción: 1
- Valor: 3
Funciones relevantes de GitLab
¿Y qué ocurre con Auto DevOps?
Pero ¿qué pasa con Auto DevOps? ? ¿No incluye diversos modelos de ramificación, metodologías de desarrollo e historia; es decir, contenido no uniforme? ¿No podríamos saltarnos esta priorización y entregarlo todo a la vez con Auto DevOps (dejando a un lado los costes operativos de la nube)?
No, y no. Auto DevOps (que no es más que un conjunto de trabajos de canalización curada) funciona como buen modelo y punto de partida para DevSecOps, que se presta a la personalización o inspiración para tus propios componentes reutilizables de CI/CD y el catálogo de CI/CD, pero actúa simplemente como punto de partida y no tanto como modelo de copia.
Para terminar
Esperamos que esta entrada de blog te haya aportado información útil para llevar a cabo una migración o implementación de GitLab, ya sea SaaS o autogestionada, ahora con una visión más amplia sobre cómo planificar buenos resultados para tu entorno.
Con el enfoque que hemos propuesto, priorizando tus criterios de éxito en función de tu respectivo tamaño, coste de implementación y tracción , las partes interesadas de tu proyecto no tardarán en ver el valor que les aporta GitLab. Tus usuarios se implicarán positivamente con GitLab al ver que la implementación tiene en cuenta sus preocupaciones.
Como mencionamos anteriormente, GitLab tiene muchos botones aquí y allí. Para sacarle el mayor partido a GitLab siguiendo el enfoque que te proponemos para su migración o implementación, infórmate sobre todas las funciones que pone a tu alcance (según el plan de suscripción aplicable, Premium o Ultimate). De esta forma, sabrás qué características son las que mejor se adaptan a tus criterios de éxito.
¡Contacta con nosotros para obtener más información!
Escrito por
Val Naipaul
Consultor principal de DevOps
Val aplica el pensamiento de DevOps a problemas del mundo real, y para ello se encarga de desarrollar nuestras prácticas de DevOps y de compartir ideas y experiencias con clientes y socios. Le gusta trabajar con historias y perspectivas diversas para impulsar la innovación.