impatto dell'integrazione continua sul dimensionamento dei biglietti

under CI rules would a developer be integrating the commits (that pass unit testing) he or she did for that day into the mainline

Le funzionalità che stai sviluppando dovrebbero essere sviluppate in pezzi, in modo da poter verificare continuamente che passino tutte le tue build / test. Ci auguriamo che i tuoi processi CI siano configurati per l'esecuzione sul tuo ramo e sul tuo master.

Se stai lavorando su un repository che si muove rapidamente (un sacco di unioni da padroneggiare), quando lavori su un ramo di una caratteristica devi spesso inserire e unire il master.

Quindi, quando esegui i tuoi commit, stai lavorando a stretto contatto su ciò che è attualmente il tuo master branch. Quando questo attiva l'elemento di configurazione, ottieni il vantaggio dell'IC - convalida e feedback relativi al tuo codice corrente.

Tuttavia, se non è possibile eseguire l'elemento della configurazione nei rami senza che il codice venga unito al master o non sia in grado di attivare l'elemento di configurazione per l'esecuzione su un ramo, è consigliabile suddividere il ticket.

Pragmaticamente molto dipenderà dal flusso di lavoro del tuo team. Se hai solo un paio di fusioni a settimana, la risposta è meno importante che se la tua squadra si fonde 20 volte al giorno. Si desidera evitare la deriva del ramo e in particolare la "deriva del ramo CI" se non è possibile eseguire CI sui rami.

is that ticket to large for CI and in turn the ticket would need to be broken down into smaller tickets where each one of those new smaller tickets would need to be done in a day or less?

Non strettamente richiesto, anche se è comunque un'idea decente.

Il punto di CI è di eseguire processi automatizzati quando si commette / unga il codice. Se non lo fai, e aspettando 5 o più giorni prima di farlo, non stai davvero facendo CI. Va bene e se quel processo funziona per te grande - non è proprio parallelo alle idee centrali di CI. Amazon Web Services ha una buona definizione sul loro sito (enfasi mia):

Continuous integration is a DevOps software development practice where developers regularly merge their code changes into a central repository, after which automated builds and tests are run. Continuous integration most often refers to the build or integration stage of the software release process and entails both an automation component (e.g. a CI or build service) and a cultural component (e.g. learning to integrate frequently). The key goals of continuous integration are to find and address bugs quicker, improve software quality, and reduce the time it takes to validate and release new software updates.

In the past, developers on a team might work in isolation for an extended period of time and only attempt to merge their changes to the master branch once their work was completed. This batched process made merging accumulated code changes difficult and time-consuming. This is compounded when small bugs accumulate for a long time without correction. These factors combined made it harder to deliver updates to customers quickly.

With continuous integration, developers frequently commit to a shared repository using a version control system such as Git. Prior to each commit, developers may choose to run local unit tests on their code as an extra verification layer before integrating. A continuous integration service detects commits to the shared repository, and automatically builds and runs unit tests on the new code changes to immediately surface any functional or integration errors.

Se non lo fai, tu "non farai CI", ma di nuovo dipende dal flusso di lavoro del tuo team. Ma riconoscere le modifiche alle funzionalità di batch è quasi la situazione del problema esatto che ha sviluppato dei tipi di processi CI da risolvere (vedere la definizione Amazon).

Non penso che dovresti cambiare il modo in cui ti avvicini ai biglietti solo perché stai facendo un'integrazione continua, specialmente se il tuo approccio alla gestione dei ticket sta funzionando per te.

Sebbene Grady Booch possa aver definito l'integrazione continua come fusione in una linea principale più volte in un giorno, preferisco pensare all'integrazione continua come un insieme di buone pratiche: avere il repository del codice nel controllo della versione, automatizzare la build, integrare il integra il controllo della versione in modo da avere una build pass / fail su ogni commit, con test automatizzati, l'integrazione di test automatici nel processo di compilazione e semplificando l'accesso alla build. L'unica altra cosa da fare è mantenere il processo di creazione on-commit veloce, ma fornendo comunque feedback utili - a seconda del sistema, potrebbe non essere possibile eseguire tutti i test ad ogni commit e potrebbe essere necessario rinviare alcuni test ad un livello inferiore -time (notti, week-end, orari in cui il sistema può funzionare per periodi di tempo più lunghi e il team di sviluppo non è in attesa dei risultati).

Poiché desideri ricevere regolarmente un feedback e ottieni il tuo feedback dal processo di creazione, devi impegnarti nei rami che vengono creati e testati regolarmente. Spesso, questo è parlato in termini di finitura di una funzionalità o correzione di un bug. Tuttavia, alcune funzionalità sono più grandi. Non penso che un commit debba risolvere interamente un problema. Un commit potrebbe eseguire alcuni refactoring per supportare l'implementazione di una funzionalità di correzione dei bug. Un commit potrebbe aggiungere ulteriori test unitari (e qualsiasi codice per farli passare - non si dovrebbero rompere i build) in preparazione delle modifiche al codice. Un commit potrebbe scrivere alcuni nuovi metodi che fanno parte della tua funzione, ma potrebbe non essere ancora chiamato (e per metodi pubblici, test di nuove unità per garantire che funzionino ). Oppure un commit potrebbe essere la funzionalità stessa.

Il modo in cui gestisci questi commit intermedi prima che la funzionalità sia completa dipende da te. La mia attuale squadra ha una regola empirica: lavorare su un ticket che richiede più di 2 ore di tempo a testa bassa consente di fare una sottotask. Potrebbe funzionare o meno per te.

Concentrati sulle buone pratiche a vantaggio della tua squadra piuttosto che su come le persone hanno definito termini. Solo perché "l'integrazione continua" ha una determinata definizione che include il commit più volte al giorno non significa che non puoi usare e vedere un beneficio dagli altri aspetti dell'IC.