come gestire un rilascio di entrambi i dati sw e config

Naviga le tue risposte
3

nel mio repository Ho una cartella sw e una cfg (config) sotto il trunk, sto pensando che quando rilascio rilascerò entrambi nella cartella releases ad es. v1 della mia app, con dati di configurazione di Londra. Se voglio pubblicare anche la v1 della mia app su NewYork, penso che dirò i miei dati di configurazione da main e li aggiusterò nella cartella di rilascio. Suona bene? ho perso qualcosa? Voglio essere in grado di dire a 12 mesi da ora in quale città è disponibile la versione dell'app, ed essere in grado di supportare anche i loro dati di configurazione. Acclamazioni 

Trunk
  sw
    qweqwe.cs, asdasd.cs etc.
  cfg
    setupData.inixmlwhatever

Releases
  London
    sw@v1
    cfg - London config data

  NewYork... app at v1, NewYork cfg
  Milan... app at v2, cfg data the same as London's but called milan.cfg
  Tokyo... app at v2 but with a Tokyo specific patch, with cfg data the same as Milan

di dovrei andare: 

Trunk
    sw
    cfg

Releases
    swV1
    swV2
    cfgTokyo
    cfgLondon
    cfgMilan

Con quest'ultimo, non so quale versione dell'app installata a Londra ecc. Potrei usare i tag per aggirare questo, ma poi qualcuno potrebbe spostare il tag. Con il primo, ho un sacco di calci di appV1 (che sto bene, i rami sono economici ecc. Ma sembra meno organizzato).

Saluti

    
posta timB33 11.09.2014 - 21:44
fonte

2 risposte

5

Se a un certo punto nel tempo hai 3 città, esistono 3 diverse cartelle di configurazione, ciascuna in "produzione" e in manutenzione. E quando il tuo prodotto si evolverà e cambierai qualcosa nelle configurazioni, dovrai adattare tutte e tre le configurazioni in parallelo. In entrambi i casi, avrai bisogno di una copia di lavoro di ciascuna città in parallelo. Quindi ti servono tutti nel bagagliaio, non in rami diversi. Questo modello rifletterà questo: 

Trunk
    sw
    cfgTokyo
    cfgLondon
    cfgMilan

Quando crei la versione v1 ora, hai 

 Releases
     v1
        sw
        cfgTokyo
        cfgLondon
        cfgMilan

E sai esattamente che hai fornito v1 per queste 3 diverse città (se il software è effettivamente installato e utilizzato nella produzione è una domanda completamente diversa).

Dopo, aggiungi New York, ma solo alla v2. Quindi la prossima versione potrebbe essere simile a questa: 

 Releases
     v2
        sw
        cfgTokyo
        cfgLondon
        cfgMilan
        cfgNewYork

Ancora una volta, ora vedi esattamente quale città è assegnata alla versione 2. Se devi aggiungere una nuova città a una versione precedente (diciamo, vuoi aggiungere Berlin alla v1), puoi creare un "ramo di manutenzione" basato su v1, aggiungi "cfgBerlin" e quando lo distribuisci, lo metti sotto Release / v1.1.

Fai un favore a te stesso e non creare patch specifiche per città in diversi rami "sw", consegnati solo in quella determinata città - metti le cose specifiche della città esclusivamente nei tuoi file di configurazione. Se hai bisogno di un tale tipo di patch, cambia il codice sotto sw nel tuo trunk in modo che controlli alcuni nella configurazione per attivare il comportamento specifico - quindi "sw" non sarà ramificato, manterrai comunque una linea di sviluppo principale per tutte le tue città Altrimenti finirai nella gestione della configurazione.

    
risposta data 11.09.2014 - 22:33
fonte
2

Consiglio vivamente di evitare le filiali per questo (come qualcuno che ha lavorato con sviluppo sia su ramo che su tronco, quest'ultimo è molto molto da preferire ). La copiatura si impegna per sempre tra di loro, con pochissime possibilità per una panoramica o una soluzione rapida su tutta la linea, se necessario. Il controllo della versione non è la gestione della configurazione ; per questo c'è Puppet, Chef e una serie di altre soluzioni molto più adatte per il solo questo tipo di situazione . E non dovresti fare affidamento su un albero dei sorgenti per sapere cosa è installato dove - come fai a sapere se la versione X per il sito Y è effettivamente stata distribuita lì? Ispezionando cosa c'è sul sito Y, in esecuzione my_software --version , cat /usr/local/share/my_software/version o qualcosa di simile. Se non hai nemmeno accesso in lettura, il processo di implementazione dovrebbe occuparsi dell'aggiornamento di alcuni servizi centrali in cui puoi scoprire cosa pensa ogni sito.

    
risposta data 11.09.2014 - 23:28
fonte

Leggi altre domande sui tag

Quando si crea una libreria, esiste un modo per rendere certe classi interamente interne alla libreria e non esposte all'utente della libreria? [duplicare] Gli argomenti più efficaci a favore del miglioramento della qualità del codice, per un manager [chiuso]