Estrategia de integración continua - Ref. Proyecto vs Branching/Merging

Question

Supongamos que tiene 7 proyectos principales en una base de código heredada (una API empresarial). La base de código tiene aproximadamente 50 aplicaciones que hacen referencia a uno o más de los proyectos centrales. Solo un par de las 50 aplicaciones siguen funcionando después de una migración de vss a tfs que se realizó manualmente en forma de pera. Para que las aplicaciones vuelvan a funcionar, muchas han sido retiradas de la API empresarial y colocadas en su propio proyecto TFS.

estoy tratando de persuadir a sus colegas que deben no hacer una rama de los proyectos básicos y poner la copia en proyectos de TFS separadas y sólo fusionar adiciones al proyecto básico de nuevo en la API de la empresa después de la liberación de PROD. Obviamente, la integración continua será mucho más difícil cuando sea menos frecuente.

Estoy tratando de convencer a los colegas de que sería mejor sacar los proyectos centrales de la API empresarial y ponerlos en su propio proyecto TFS y luego hacer referencia a bin/Debug.

¿Es mejor que Branch, copie la (s) rama (s) para separar Proyectos TFS y luego Merge (y vea conflictos al final) o es mejor encapsular proyectos centrales y forzar a un equipo de 20 a usar una sola copia de cada uno de los proyectos centrales?

Answer 1

Estoy bastante seguro de que quiere que sus equipos hagan referencia a los binarios ya construidos de las API principales. La granularidad correcta de la reutilización es la granularidad de la versión (una versión versionada). Consulte el informe C++ de Robert C Martin desde 96 y nuestra explicación aquí: http://www.urbancode.com/html/resources/articles/reuse-maturity-model.html

Básicamente, parece que los equipos están en pánico y simplemente hacen lo más simple eso podría recuperarlos y poder entregarlos. Esa ruta es comprensible, pero creo que es mejor si reconocen que sería mejor tener sus bibliotecas comunes como una base de código compartido y que reutilizar el código en lugar de las DLL es malo, y la deuda técnica debe abordarse cuando las cosas se estabilicen. .

Answer 2

Realmente depende de la madurez de su código compartido. Yo diría que hay tres enfoques que puede seguir, cada uno con sus propias ventajas y desventajas:

Opción 1: Directamente referencia a salir de su propio proyecto de equipo

Team Project Application 1 
--> Development 
     --> ... 
--> MAIN 
     --> Sources 
      --> Application 1 
       --> Application1.sln 

Team Project Application 2 
--> Development 
     --> ... 
--> MAIN 
     --> Sources 
      --> Application 2 
       --> Application1.sln 

Team Project CoreProject 1 
--> Development 
     --> ... 
--> MAIN 
     --> Sources 
      --> CoreProject1.csproj 

Con este enfoque, se puede establecer en su CI se construye para que todas las aplicaciones comiencen a desarrollarse una vez que se haya registrado en un CoreProject.
que están obligados a tener los proyectos de equipo correlacionado localmente con una convención (o de lo contrario se romperá la compilación)

Este es un buen enfoque si cambia constantemente la CoreProject & necesita esos cambios reflejados rápidamente a todas las aplicaciones afectadas.
También implica que puede permitirse la inestabilidad en una determinada aplicación, si un cambio radical en un CoreProject lo inflige.

Opción 2: Indirectamente referencia a ellos a través de ramificación

Team Project Application 1 
--> Development 
     --> ... 
--> MAIN 
     --> SharedSources 
      --> CoreProject1_branch 
       --> CoreProject1.csproj 
     --> Sources 
      --> Application 1 
       ---> Application1.sln 

Team Project Application 2 
--> Development 
     --> ... 
--> MAIN 
     --> SharedSources 
      --> CoreProject1_branch 
       --> CoreProject1.csproj 
     --> Sources 
      --> Application 2 
       ---> Application1.sln 

Team Project CoreProject 1 
--> Development 
     --> ... 
--> MAIN 
     --> Sources 
      --> CoreProject1.csproj 

Con este enfoque, cada vez que se haya registrado cambios en CoreProject1, es necesario organizar una fusión para cada aplicación afectada. Esto supone cierto esfuerzo, pero le da tiempo para estabilizar CoreProject en su propio patio de juegos y luego combinarlo con sus aplicaciones.
Este enfoque implica que también tiene una definición de compilación para cada CoreProject.
En general, esta es una buena forma de proceder si valora la estabilidad de CoreProject. & no puede permitirse 'contaminar' sus aplicaciones en caso de que los cambios causen problemas. Este es por cierto el enfoque que buscamos.

Opción 3: Hacer referencia de archivo en cada aplicación

Team Project Application 1 
--> Development 
     --> ... 
--> MAIN 
     --> SharedBinaries 
      --> CoreProject1_branch 
       --> CoreProject1.dll 
     --> Sources 
      --> Application 1 
       ---> Application1.sln 

Team Project Application 2 
--> Development 
     --> ... 
--> MAIN 
     --> SharedBinaries 
      --> CoreProject1_branch 
       --> CoreProject1.dll 
     --> Sources 
      --> Application 2 
       ---> Application1.sln 

Team Project CoreProject 1 
--> Development 
     --> ... 
--> MAIN 
     --> Sources 
      --> CoreProject1.csproj 

Con este enfoque, usted 'd necesidad de comprobar en la salida binaria de un CoreApplication construir en cada aplicación.
Esto solo se recomienda si confía en que CoreApplication es estable &, no necesita depurarlo regularmente.

Esencialmente la opción 2 & opción 3 son similares, separados por el conocido debate "referencia proyecto vs. archivo". Ver here para un recurso SO, se puede recuperar mucho más a través de búsquedas.

Si sus proyectos principales se deben a cambios constantes y/o tienen una baja cobertura de prueba de unidad, debe ir a la opción 2 (o 3).
Si confía en su calidad, optar por la opción 1 es una buena opción, ya que mejorará en gran medida su productividad general.

Sin ningún conocimiento de sus productos y su calidad, simplemente basándonos en los números bastante grandes que proporciona (20 personas, 50 soluciones, 7 proyectos centrales), optaría por la opción 2/3.

Otra sugerencia importante: sucede más que a menudo que los proyectos compartidos no tienen ningún medio de prueba separada. Si este es el caso y los proyectos centrales no tienen pruebas de unidades propias, ningún plan de prueba dedicado, etc. no tiene sentido hacer nada más que la opción 1.

Un gran recurso adicional al respecto es el work de los guardabosques de ALM.