eventuali problemi con l'utilizzo di git in un ambiente CI?

Question

eventuali problemi con l'utilizzo di git in un ambiente CI?

#1 da (4 voti)

4

Lavoro in un negozio che vive con il suo processo di CI. Abbiamo tradizionalmente utilizzato SVN e stiamo considerando di passare a git (vogliamo sfruttare la sua facilità di ramificazione, archiviazione, ecc.). Pensando in termini che un sistema di controllo del codice sorgente distribuito, per sua stessa natura, sembra porre la necessità di un repository centrale come una preoccupazione secondaria, non crea sfide per un processo di CI? Finché lo sviluppatore esegue un "commit", quindi "push", il concetto di un repository centrale come lo avrei conosciuto con SVN esiste ancora, facendo sì che CI generi solo una configurazione diversa (pull da git piuttosto che da svn)?

Qualche problema culturale (gli sviluppatori spingono al repository principale meno spesso e invece si limitano a commettere localmente forse)?

Mi piacerebbe sentire le storie di successo / insuccesso da un gruppo che usa la CI con git.

git continuous-integration

posta jayraynet 11.05.2011 - 06:47

fonte

1 risposta

Leggi altre domande sui tag git continuous-integration

Best practice per la convalida di messaggi XML Qual è un buon modo per rappresentare (programmaticamente) grafici / reti?

score 4 · Accepted Answer

Non aggiunge ulteriori complessità che non possono essere considerate opportunità. Sebbene tu possa utilizzare Git in modo completamente disaccoppiato e decentralizzato, molti progetti di solito si basano su uno (o più) repository "benedetti", e questi sono i repository che il server CI dovrebbe costruire.

Potresti avere repository "benedetti" per il repository principale (come quello che spedisci da), così come alcuni per i rami che alla fine raggiungono la fine della linea. Puoi utilizzare il tuo server CI per fare ciò che sa fare meglio, rilevare revisioni tossiche sul link qualsiasi in quella catena.

Quindi in molti modi, è meglio, perché prendi cose prima che vengono messe nel bagagliaio centrale e fuori in natura per saltare in aria gloriosamente. Tuttavia, l'arte in realtà non è il processo CI, sta istituendo un flusso di lavoro Git che ti consente di posizionare build CI in punti chiave.

Uso Hudson con entrambi i progetti Git e Mercurial, condividendo un flusso di lavoro simile. Git è in realtà il più facile tra i due, poiché le filiali in Git sono un po 'più facili da gestire. In genere, abbiamo un piccolo team con un lead, il team leader riceve richieste per accedere a un repository di filiale benedetto. Se i controlli CI sono positivi, il responsabile del team invia una richiesta di estrazione al project manager, che accede a un repository -next . Se le build CI sono a posto, finisce nel repository di rilascio singolo (combinato). Quindi puoi eseguire test praticamente in ogni fase del processo, o meno, a seconda delle tue esigenze.