Collaborazione con github e test del codice

4

La procedura nella mia squadra è che tutti impegniamo il nostro codice nello stesso ramo di sviluppo. Abbiamo un server di test che esegue codice aggiornato da questo ramo in modo che possiamo testare il nostro codice sui server. Questo server di prova è esposto su Internet in modo da poter verificare i callback da servizi di terze parti come sendgrid. (dove si specifica un url per sendgrid per aggiornarti sullo stato delle e-mail inviate)

Il problema è che se vogliamo unire il ramo di sviluppo al ramo master per pubblicare nuove funzionalità sui nostri server di produzione, alcune funzionalità che potrebbero non essere state pronte verranno applicate ai server di produzione.

Quindi stiamo pensando di far lavorare ogni sviluppatore su un ramo di funzionalità / argomento in cui ognuno di loro lavora sulle proprie funzionalità e quando è pronto, uniscilo nel ramo di sviluppo per il test e poi nel ramo principale.

Tuttavia, poiché il nostro server di test recupera solo le modifiche dal ramo di sviluppo, gli sviluppatori non sono in grado di testarne le funzionalità. Sebbene questo non sia un problema enorme in quanto possono testarlo sul proprio computer locale, l'unico problema che prevedo è se vogliamo testare i callback da servizi di terze parti usando il nostro server di test durante lo sviluppo di una funzione .

Come possiamo gestire questo problema?

Nota: non siamo utenti avanzati di git. Usiamo l'app Github per MacOSX e Windows per impegnare il nostro lavoro.

Setup: è un progetto PHP. Non abbiamo alcuna forma di configurazione della CI e non abbiamo le conoscenze per farlo. Alla fine vogliamo usare Jenkins ma al momento ci stiamo concentrando solo sul nostro prodotto minimo vitale.

    
posta wyred 30.11.2012 - 08:52
fonte

2 risposte

3

Una soluzione è lasciare che anche il server di test costruisca i rami quando vengono effettuati i commit. Ad esempio, a Jenkins può essere detto di monitorare alcuni o tutti i rami in un repository e ogni volta che rileva un commit su un ramo, esso costruirà quel ramo. Vedi per es. Git, Feature Branches e Jenkins - o in che modo ho imparato a smettere di preoccuparmi di build danneggiate

Potresti avere una convenzione di denominazione per i rami "scratch" che non dovrebbero essere testati, e lasciare che Jenkins costruisca solo i rami "reali" della feature.

Un'altra soluzione comune consiste nell'avere una sorta di ramo di integrazione tra i rami delle funzionalità e il master (o avere i rami "master" e "release"). Quindi tutti si fondono con il master una volta che una funzione è pronta, tutto è testato su master, ma le fusioni in "release" avvengono solo quando una funzionalità è sufficientemente testata per essere implementata. Vedi per es. Un modello di branching Git riuscito per un approccio popolare.

    
risposta data 30.11.2012 - 09:33
fonte
2

Potresti fare qualcosa di simile a ciò che fa git project con il ramo "pu".

In git (il progetto) lo sviluppo è fatto sui rami dell'argomento. Durante lo sviluppo, questi rami sono spesso ridefiniti sull'ultimo master o, se dipendono da altri sviluppi recenti, next . Ogni volta che vengono ridefinite, vengono tutte unite in un ramo chiamato pu . Il ramo viene sempre eliminato e creato da unire nuovamente tutti gli argomenti. Quando la funzione viene testata, viene unita a "next", che non è mai rimbalzo e che è finalmente integrata in "master". Quindi puoi avere un server di prova che mostra questo "pu" (sviluppo) e possibilmente un altro che mostra il "prossimo" (pre-produzione).

    
risposta data 30.11.2012 - 09:45
fonte

Leggi altre domande sui tag