rami, build, rilasci e multi-piattaforme

Question

rami, build, rilasci e multi-piattaforme

Naviga le tue risposte

#1 da (1 voti)

4

Vorrei verificare quali sono le migliori pratiche disponibili. Ho i seguenti requisiti:

Ho un repository che viene utilizzato per lo sviluppo (master e sviluppo rami). Vorrei tenere traccia dei candidati alfa / beta / release e rilasciare build. Sto pensando di creare rami per alpha / beta / rc / rel e poi quando mi fonderò push sviluppare in alpha e poi in alpha in beta ecc ecc. Ma in questo caso, il ramo master rimane senza alcun utilizzo utile e lo sviluppo funziona solo nella fase pre-alpha. Dopo una versione alpha, devo ramificarmi dal ramo alfa.
Voglio tenere traccia in un VCS dell'intero pacchetto fornito ai clienti. Quindi, sto pensando di creare un repository separato con build di rilascio e tutto il materiale aggiuntivo (documenti, licenza, ecc. Etc).
L'applicazione è multipiattaforma, il che significa che per ognuno di questi ho bisogno di almeno altri tre rami (win32, win64 e macos)

Tutto sommato, sembra un processo molto complicato. Quindi, qual è un approccio comune qui?

Grazie

branching cross-platform

posta John Kouraklis 18.06.2016 - 17:18

fonte

1 risposta

Leggi altre domande sui tag branching cross-platform

Architettura senza server: come implementare le modifiche nella logica aziendale comune? Puoi concedere in licenza un fork di una libreria di dominio pubblico?

score 1 · Answer 1

Preferisco lavorare su "main" o "trunk" e non su branch per le versioni precedenti, ma rametto dopo il rilascio quando ho bisogno di fornire una correzione per qualche versione precedente in the wild, cerco assolutamente di minimizzare la quantità di versione diversa che devo mantenere. Quando sei in versione beta continuerai a supportare la versione alpha del tuo software? Penso che alpha / beta / rc / release sia sequenziale, non parallelo, non ha bisogno di rami, esprime solo la prontezza / stabilità del tuo 'tronco'.
Distribuzioni che ho creato da un server di build, associo la distribuzione con il numero di build e la revisione del controllo di versione. In questo modo posso creare un ramo 'release' in seguito, se necessario, per una hot-fix / patch. Lo faccio raramente, dal momento che cerco di correggere l'ultima versione (prova a mantenere tutte le installazioni nella versione più recente).
Non ho nessuna vera esperienza di cui parlare qui, ma presumo che la maggior parte del codice sarà effettivamente la stessa, usando le direttive del compilatore come suggerito da alcuni commenti sembra una strategia migliore. È anche possibile selezionare le implementazioni specifiche della piattaforma utilizzando la configurazione di iniezione delle dipendenze. Se si diramano per piattaforma, si potrebbe correre il rischio che i rami si allontanino così distanti che qualsiasi tentativo di fusione tra di loro diventa un grave dolore. Raccomando di trovare astrazioni per evidenziare le differenze della piattaforma.

Preferisco mantenere la ramificazione al minimo, secondo la mia esperienza, porta a un'integrazione tardiva, scoraggia il refactoring (ti imbatterai in fusioni non fondibili o molto complesse). Mantengo le caratteristiche instabili / non terminate fuori produzione utilizzando attiva / disattiva .