SVN / Git Come amministrare i rami

0

Sono il capo tecnico di una piccola azienda (6 sviluppatori). Al momento utilizziamo SVN e passiamo lentamente a Git, dopo che tutti hanno ricevuto il loro addestramento.

Attualmente i nostri clienti sono quelli che "innescano il grilletto" sull'integrazione delle filiali. Il che significa che alcuni moduli o funzionalità sono stati creati e quindi, questa funzione si trova in un ramo fino a quando il client non chiede di farlo funzionare. Quando va in diretta, uniamo il ramo in un ambiente di staging e facciamo test. Quindi una volta che il test conferma che tutto funziona come dovrebbe, allora uniamo le modifiche nel trunk per il live push.

È fatto in questo modo perché spesso abbiamo un sacco di sviluppo parallelo e spesso i requisiti cambiano sempre al volo. Quindi, per isolare e controllare cosa va dove, inseriamo ogni modulo o funzione nel suo ramo.

Per molto tempo abbiamo avuto problemi con la gestione delle filiali. Quindi, ad esempio, potremmo costruire un ramo con la caratteristica A. Passeranno sei mesi e infine il cliente o il gestore dello sviluppo vorranno spostare quella modifica in anticipo, se uno di loro si ricorda . Questo è il mio problema. Quali sono alcuni modi in cui posso tenere traccia di quali rami sono stati uniti? o non uniti? Un modo centralizzato per tenere d'occhio tutti questi cambiamenti.

Questa può essere una sfida da gestire, perché spesso come lead nella mia azienda, mi viene richiesto di gestire progetti, codice, revisione del codice, integrazione su diverse piattaforme. I lead qui non sono silo, dobbiamo essere parte di ogni sviluppo ovunque. Così spesso, in qualsiasi momento, avrò fino a 7-10 voci diverse nella mia lista degli impegni, e l'integrazione e la gestione delle filiali possono scivolare tra le crepe.

    
posta ShinEmperor 12.12.2018 - 20:42
fonte

2 risposte

3

Se disponi di molto sviluppo parallelo, considera l'utilizzo di un ramo principale e di un interruttore a scorrimento.

Richiede una disciplina extra per garantire che la build funzioni (anche se il codice di attivazione della funzionalità è incompleto) e per creare, utilizzare e quindi pulire in seguito i commutatori di funzionalità. Questo può essere in parte compensato con strumenti di analisi statica e test automatici per dimostrare che la funzionalità funziona, ma anche per garantire la sua indisponibilità al momento dello spegnimento.

I benefici però sono che l'unione è un non-problema, perché ci sono pochissimi rami e quelli che esistono sono unificati rapidamente. Inoltre questo rimuove anche gran parte della gestione delle filiali. Scollega anche le distribuzioni dalle versioni. Questa può essere una vendita molto bella per i tuoi clienti / dipartimento marketing, assicurandoti sia la stabilità, sia i miglioramenti dell'usabilità, dal momento che le nuove funzionalità possono essere disattivate in caso di problemi imprevisti.

Se si dispone di un ambiente avverso al rischio o se è necessario supportare diverse linee di rilascio, utilizzare il meccanismo di diramazione per attivare un ramo di rilascio. Da questo ramo possono essere rimosse funzionalità incomplete o non rilasciabili. Questo va bene in quanto il ramo non verrà mai unito al ramo principale. Le correzioni dei difetti possono essere progettate sulla linea principale e quelle allegre raccolte sul ramo di rilascio.

    
risposta data 13.12.2018 - 01:20
fonte
0

Potrei pensare a 2 modi per gestire il tuo scenario

  1. Elimina il ramo dopo l'unione: una volta fuso il ramo, cancellalo. In questo modo saprai che tutti i rami presenti andranno a vivere un giorno. delete-branch

  2. Rinomina il ramo dopo l'unione: se ritieni di aver bisogno del ramo per riferimento futuro, invece di eliminare il ramo, rinomina il ramo. rename-branch

risposta data 12.12.2018 - 23:30
fonte