Versiones de plataforma de destino con Git en un entorno corporativo cerrado

Context

Desarrollamos una cantidad de complementos que se ensamblan en aplicaciones Eclipse RCP 3.X. Usamos una única plataforma de destino, que se basa en repositorys P2 porque este es el único sabor admitido por Tycho.

Target Plaform VS SCM

Nuestro acceso a Internet es bastante restringido. No podemos acceder a repositorys P2 disponibles públicamente, incluso si configuramos proxies. Por lo tanto, descargamos las cremalleras de repositorys P2 y las ponemos en control de fuente para que el equipo pueda compartirlas y versionarlas. Sin embargo, creemos que tener contenido binary en SCM es a menudo una mala práctica.

Nos estamos preparando para migrar de ClearCase a Git. Al hacerlo, estamos considerando cambiar la forma en que administramos nuestra plataforma objective para mejor. Hemos pensado en diferentes escenarios pero carecemos de experiencia para medir sus pros y contras. Aquí están los primeros resultados de nuestras reflexiones:

Escenario 1: usar un repository de Git separado para la plataforma de destino

  • Pros:
    • Los complementos son compartidos
    • Luego podemos volver a una versión anterior "física" de la plataforma objective
    • Cambiar la plataforma de destino es tan fácil como manipular files
  • Contras:
    • Binarios en SCM
    • Cada instancia de repository utiliza mucho disco para mantener todo el historial de la plataforma de destino

Escenario 2: Uso de Nexus con complementos para la administración de repositorys P2

  • Pros:
    • Los complementos son compartidos
    • Depósito ligero: solo se debe versionar el file foo.target
  • Contras:
    • Nunca usamos Nexus previamente
    • Cambiar el contenido de la plataforma objective es más complejo
    • Necesitamos mantener manualmente una copy archivada de cada versión de los contenidos de la plataforma objective

Preguntas

¿Cómo se maneja el control de versiones de la plataforma objective con Git en una networking corporativa cerrada? ¿Qué piensas sobre los escenarios anteriores y sus respectivos pros y contras? ¿Podría sugerir otras soluciones?

Al utilizar Nexus y Nexus Unzip Plugin , hay una solución muy buena que satisface tus necesidades de tener una plataforma objective reproducible y build independientemente del acceso a Internet:

  • Configure Nexus y asegúrese de tener un repository m2 en el que pueda implementar, por ejemplo, con deploy-file .
  • Descargue los repositorys p2 que necesita como files comprimidos (o cree estos files zip usted mismo si no se ofrecen para su descarga).
  • Implemente los repositorys p2 comprimidos en el repository de Nexus m2, utilizando una versión que no sea SNAPSHOT. Los artefactos que no son SNAPSHOT en Nexus son inmutables, por lo que cuando haces reference a los repositorys de p2 a través de su URL en Nexus, siempre obtienes el mismo contenido.
  • Instale Nexus Unzip Plugin y configúrelo para "ocultar" / servir el contenido del repository en el que se ha desplegado. De esta forma, los repositorys p2 comprimidos obtienen una URL "descomprimir" que los hace parecer depósitos regulares de p2 a Eclipse y / o Tycho.
  • Finalmente, cree un file de definición de destino que haga reference solo a los repositorys de p2 en su Nexus, y coloque ese file en su repository de git.

Hemos utilizado esta configuration con éxito en nuestro entorno corporativo desde hace bastante time, por lo que le recomendaría que también pruebe este enfoque.

Esto es similar a su solución 2, pero con un plugin Nexus diferente. No necesita ninguno de los complementos para el "soporte de repository p2" explícito para la solución descrita. Además, no necesita hacer ningún file adicional del contenido de su plataforma de destino.


Descargo de responsabilidad: El plugin Nexus Unzip es ofrecido por el proyecto Tycho, del cual soy committer.