¿Cómo lograr una transición fluida del modelo de organización “el único gran repositorio VCS para todos los productos” al modelo “muchos repositorios VCS pequeños”?

Es un escenario común que la base de código de un producto en poder de un repositorio en algún sistema VCS evolucione hasta un punto en el que se pueda ver que esa base de código contiene varios productos. Dividir la base de código en varios repositorios de VCS, cada uno dedicado a un solo producto, puede aprovechar varios beneficios (consulte Beneficios de tener un producto por repositorio de VCS sobre el modelo de repositorio de inflado a continuación). En el aspecto técnico, dividir la base de código es un paso bastante fácil ya que la mayoría de los VCS admiten esta operación. Sin embargo, la división podría generar problemas de ingeniería relacionados con las pruebas automatizadas, la entrega continua, la integración de servicios o la supervisión (consulte Problemas planteados por la división.) Las organizaciones que planean realizar una división de este tipo, por lo tanto, necesitan saber cómo realizar esta transición de la manera más fluida posible, es decir, sin interrumpir su entrega y monitoreo. El primer paso de esto es probablemente comprender mejor la noción de proyecto y cómo delinear la división en una base de código monolítico.

En las respuestas a estas preguntas, me gustaría ver:

1. Un intento de dar una definición funcional de lo que es un producto, lo que proporciona criterios prácticos para delinear productos en una base de código existente.

2. De acuerdo con esta definición de trabajo, elabore un plan que realmente realice la división. Podemos hacer la suposición simplificadora de que el código base es procesada por un sistema totalmente automatizado sdlc implementación continua-integración y entrega continua . Es decir, cada rama es validada por un conjunto de pruebas automatizado implementado en la base de código actual y cada fusión con alguna rama "mágica" genera artefactos de producto que se prueban y se implementan. ( Los artefactos del producto son, por ejemplo , tarballs de origen, documentación, paquetes de software binario, imágenes de Docker , AMI, unikernels).

3. Tal plan es satisfactorio si explica cómo eludir el

Problemas planteados por la división

1. ¿Cómo se relacionan los procedimientos de prueba automatizados con el repositorio monolítico preexistente y los repositorios divididos?

2. ¿Cómo se relacionan los procedimientos de implementación automatizados con el repositorio monolítico preexistente y los repositorios divididos?

3. ¿Dónde se almacena el código para los procedimientos de implementación automatizados?

4. ¿Dónde se almacenan las estrategias de infraestructura , monitoreo y alta disponibilidad ?

5. Cómo asegurarse de que un desarrollador necesita solo una base de código a la vez (pero posible utiliza artefactos de otras bases de código).

6. ¿Cómo puede una herramienta como git-bisect

Nota marginal: Beneficios de tener un producto por repositorio VCS sobre el modelo de repositorio hinchado

Tener varios repositorios pequeños que contienen la base de código para un producto específico tiene las siguientes ventajas sobre el enfoque de "repositorio hinchado":

1. Con un repositorio inflado, es difícil revertir una versión cuando un producto es inestable, porque el historial se mezcla con otro historial del producto.

2. Con un repositorio inflado, es difícil revisar el historial del proyecto o las extracciones, con repositorios pequeños, es más probable que leamos esta información. (¡Esto podría ser específico para VCS como git, donde a diferencia de svn, no podemos pagar subárboles!)

3. Con un repositorio hinchado, tenemos que hacer mucho más baile de rama cuando nos desarrollamos. Si tenemos N repositorios, podemos trabajar en paralelo en N ramas, si solo tenemos 1 repositorio, solo podemos trabajar en una rama, o tenemos una carga de copias de trabajo que también son una molestia para manejar.

4. Con varios repositorios pequeños, los registros dan un mapa de calor del proyecto. Incluso pueden usarse como un proxy de difusión de conocimiento en el equipo de desarrollo: si no me comprometí en el repositorio X desde hace 3 meses, podría ser bueno asignarme en un equipo que trabaje en el repositorio X para que esté al tanto de los desarrollos en ese componente

5. Con repositorios pequeños, es más fácil obtener una visión general clara de un componente. Si todo va en un solo depósito grande, no hay artefactos tangibles que delineen cada componente, y la base de código puede derivar fácilmente hacia la gran bola de lodo .

6. Los repositorios pequeños nos obligan a trabajar en interfaces entre componentes. Pero dado que queremos tener una buena capsulación, este es un trabajo que deberíamos hacer de todos modos, por lo que lo consideraría una ventaja para los repositorios pequeños.

7. Con varios repositorios pequeños, es más fácil tener varios propietarios de productos.

8. Con varios repositorios pequeños, es más fácil tener estándares de código simples que sean pertinentes para un repositorio completo y que puedan verificarse automáticamente.

Es una pregunta fascinante para la cual las respuestas reales pueden no existir realmente; Aprecio que si bien trató de mantener la pregunta contextualizada en el VCS, naturalmente se amplió por sí sola hasta el diseño de infraestructura y la planificación de implementación.

Sin embargo, parece que muchos de nosotros estamos trabajando en este tipo de transición, que puede ser emocionante, pero al mismo tiempo tan frustrante y doloroso; y me gustaría compartir mis experiencias y puntos de vista, tratando de no ser pedante, y solo porque no sea un buen ingeniero, también para no ser aburrido.

Diseño

La infraestructura y la arquitectura deberían ir juntas para escribir un software moderno. Bien acoplado, si quieres. Puede sonar extraño usar esas palabras, pero ciertamente no estamos hablando del código en sí mismo: quiero decir que deben ser parte del mismo plan. Cuando llegaron las nubes y la gente comenzó a escribir software para ellos, ¿cuántas personas se dieron cuenta de que al poner las bolas de barro allí, serían las mismas bolas de barro en un lugar diferente (?) Tal vez algunas personas con visión de futuro podrían prever eso, y probablemente estén trabajando en devops hoy. Como devops es solo una palabra de moda con tantos significados diferentes para diferentes personas, he visto lugares en los que el equipo de devops se sentaría en cada reunión de arquitectura; otros lugares en los que solo hay automatización. Para lograr este tipo de transformación, tenemos que luchar para sentarnos allí.

Confianza

La transición debe mantenerse aislada, en el sentido de que debe existir un corte coherente de la historia, que proporcione la transición en sí misma y solo, sin ningún otro cambio (después de varios meses de preparación). ¿Con qué confianza uno lo aprobaría y presionaría el botón rojo?

Quiero decir que la base de código debe cambiar para acomodar la nueva estructura VCS, y será muy difícil mantenerla fusionada durante el desarrollo. (para este problema puede haber estrategias de facilitación, hablaré de una común más adelante, que puede ayudar a paralelizar un poco el desarrollo).

Bueno, apuesto a que la única forma es con las pruebas de comportamiento, y se debe lanzar el mismo conjunto de pruebas de comportamiento para verificar lo antiguo con la nueva base de código. No estamos verificando que la aplicación se comporte como se espera aquí, sino que la transición no altera el comportamiento. ¡Tener exámenes fallidos puede ser algo bueno! Si siguen fallando!

De hecho, es muy poco común que las bolas de lodo se prueben bien; por lo general, el código está muy estrechamente acoplado y, probablemente, para la mayoría del código heredado, no se desarrolló con un enfoque basado en pruebas, ni siquiera pruebas unitarias.

Si falta el código de prueba, se escribirá primero.

Estrategia

Sí, la transición debe mantenerse aislada; pero al mismo tiempo integrado. Sé que puede parecer una locura aquí, pero no encontraría otras palabras para describir cómo la confianza puede mantener el ritmo de los negocios. Muy pocas, si es que no hay ninguna, a las compañías les gustaría detener el desarrollo de una gran base de código monolítico, para hacer espacio para esta transición, y no estamos haciendo que suceda con solo lanzar una moneda. Tal vez cientos de desarrolladores podrían estar contribuyendo continuamente a la base de código (usaría la palabra de manipulación aquí, desde nuestro POV). Si bien nuestro trabajo debe abordar una instantánea específica para proporcionar confianza, tenemos que mantenernos rebajados (no en un sentido aquí), para evitar quedarnos atrás para siempre.

La estrategia de implementación aquí puede dar diferentes experiencias. Una línea común de desarrollo es envolver / adaptar (exponiendo puntos finales con esquemas reorganizados opcionalmente) ramas de implementación más nuevas (bueno, viviendo en otros repositorios en este caso), cuando necesitan interactuar con el núcleo. La transición con una estrategia como esta, junto con la refactorización, al mismo tiempo puede ofrecer un escenario POC para la transición de VCS y, más adelante, un enfoque paso a paso. Véalo como esculpir la bola de barro. Sí, la vida ofrece muchas cosas más divertidas.

Deuda técnica

Las esferas de gestión empresarial comenzaron a comprender la deuda técnica y a tenerla en cuenta. No, tacha eso, no es cierto. Si bien es cada vez más común recopilar mediciones y datos de calidad, en términos de análisis de código estático, revisión de código, resultados de pruebas de comportamiento y rendimiento, y generar buenos informes y todo ... sigue siendo increíblemente difícil hacer que el negocio acepte un continuo enfoque de refactorización. El valor comercial de la misma. "Estamos siguiendo un proceso ágil, y esto no traerá ninguna mejora a las características, ¿no?" . Básicamente, al hacerlo, están negando la existencia de deuda técnica. Veo esto como el paso necesario perdido común para poder comenzar cualquier transición de arquitecturas monolíticas a microservicios.

Reagrupación

Después de todo esto, es posible que aún desee proporcionar una vista única similar a un repositorio en la que pueda crear más de un solo producto. Por cualquier motivo, es decir, curr / próximo lanzamiento, multimarca, compilaciones de clientes. Herramientas como Google Repo pueden ayudar en este caso. Nunca usé uno yo mismo, pero sé que necesitaré algún día.

Pruebas de integración

Con los microservicios, las pruebas de integración asumen un contexto diferente, de "probar la propia API". Pueden existir y existirán niveles más altos de pruebas, funcionales o de rendimiento, pero ¿significan mucho sin una prueba de integración adecuada? Sería como tener pruebas de integración sin pruebas unitarias. Por supuesto no. Por eso, si necesita git bisect, lo ejecutará en una rama del repositorio de microservicios, olvídese de ejecutar eso en el repositorio de mudball.

PD. este es un borrador, mi inglés es malo y lo arreglaré algún día