Supporto e test di più versioni di una libreria software in un progetto Maven

Naviga le tue risposte
3

La mia azienda ha diverse versioni del suo software principale in uso dai nostri clienti in qualsiasi momento. Il mio compito è quello di scrivere software Java su misura per i clienti in base alla versione del software di base che sono in esecuzione.

Ho creato una libreria Java comune che esegue molte delle attività che richiedo regolarmente in un progetto normale. Questo è un progetto Maven che distribuisco al nostro Artifactory locale e quando possibile abbino altri progetti Maven.

Attualmente questa libreria include la versione 1.3 del nostro software di base, ad esempio: 

<dependency>
  <groupId>com.foo</groupId>
  <artifactId>core-software</artifactId>
  <version>1.3</version>
</dependency>

Di conseguenza, questa è l'unica versione di cui sono assolutamente sicuro sia compatibile grazie al successo dei test unitari. Come posso automatizzare meglio i test con altre versioni del software principale per garantire la compatibilità?

Una possibilità è creare una serie di progetti Maven che incorporino la mia libreria e sostituiscano la versione del software di base: 

<!-- Override core version -->
<dependency>
  <groupId>com.foo</groupId>
  <artifactId>core-software</artifactId>
  <version>1.2</version>
</dependency>
<!-- Incorporate shared library: -->
<dependency>
  <groupId>com.foo</groupId>
  <artifactId>common-lib</artifactId>
  <version>1.0</version>
</dependency>

Potrei quindi eseguire i test unitari dal mio progetto principale per assicurarmi che tutti passino (ho bisogno di capirlo). Il vantaggio di questo approccio è che posso incorporare questi progetti Maven aggiuntivi nel mio server di integrazione continua e ricevere avvisi ogni volta che un check-in rompe la compatibilità con un'altra versione del software di base.

Qualcuno può suggerire un'alternativa migliore?

    
posta Duncan Jones 26.11.2012 - 11:47
fonte

2 risposte

2

Potresti utilizzare più profili Maven nel tuo progetto, ignorando la versione del software di base in ciascun profilo. Quindi, crea il tuo software CI con ogni profilo.

Il profilo potrebbe dire questo: 

<profiles>
  <profile>
    <id>old</id>

    <!-- When this profile will turn on... -->
    <activation>
      <property>
        <name>buildVer</name>
        <value>old</value>
      </property>
    </activation>

    <!-- What this profile changes... -->
    <dependencies>
      <dependency>
        <groupId>com.foo</groupId>
        <artifactId>core-software</artifactId>
        <version>1.2</version>
      </dependency>
    </dependencies>
  </profile>

  <profile>
    <id>veryold</id>
    <activation>
      <property>
        <name>buildVer</name>
        <value>veryold</value>
      </property>
    </activation>
    <dependencies>
      <dependency>
        <groupId>com.foo</groupId>
        <artifactId>core-software</artifactId>
        <version>1.0</version>
      </dependency>
    </dependencies>
  </profile>
</profiles>
    
risposta data 27.11.2012 - 13:03
fonte
0

Se si applica, puoi creare una succursale nel controllo del codice sorgente per ogni versione e impostare lo strumento CI per creare / testare tutte le diramazioni attive .

Questo potrebbe essere problematico se hai un ramo attivo che non vuoi costruire / testare. Dovresti risolverlo in base alle tue esigenze, ma ti suggerisco di prendere in considerazione il controllo della versione se possibile.

    
risposta data 26.11.2012 - 15:25
fonte

Leggi altre domande sui tag

Esiste una regola empirica per quale impostazione di zoom di una mappa bing dovrebbe essere basata sul numero di miglia che si desidera visualizzare? Tipi di container in Golang