Hai studiato i comandi Git, ma vuoi capire come avviene concretamente l'integrazione continua (Continuous Integration, CI)? O forse vuoi ottimizzare le tue attività quotidiane? Questo corso ti fornirà competenze pratiche sull'integrazione continua utilizzando un repository su GitHub. Questo corso non è pensato come una sorta di wizard da cliccare, al contrario, compirai le stesse azioni che le persone fanno realmente sul lavoro, nello stesso modo in cui lo fanno. Spiegherò la teoria mentre seguirai i passaggi ad essa correlati.

Cosa faremo?

Proseguendo, costruiremo progressivamente un elenco di passaggi tipici per la CI, che è un ottimo modo per memorizzare questo elenco. In altre parole, creeremo un elenco di azioni che gli sviluppatori effettuano per realizzare l'integrazione continua. Utilizzeremo anche un semplice set di test per avvicinare il nostro processo CI alla realtà.

Questo GIF mostra schematicamente i commit nel tuo repository man mano che prosegui nel corso. Come puoi vedere, non c'è nulla di complicato, solo l'essenziale.

Affronterai i seguenti scenari standard per la CI:

• Lavorare su una funzionalità;
• Applicare test automatici per garantire la qualità;
• Implementare una task prioritaria;
• Risoluzione dei conflitti durante la fusione dei rami (merge conflict);
• Si verifica un errore in ambiente di produzione.

Cosa imparerai?

Potrai rispondere a domande come:

• Che cos'è l'integrazione continua (CI)?
• Quali tipi di test automatici vengono utilizzati nella CI e in risposta a quali azioni vengono avviati?
• Che cos'è una pull request e quando è necessaria?
• Che cos'è lo sviluppo orientato ai test (Test Driven Development, TDD) e come si ricollega alla CI?
• Fondere (merge) o applicare modifiche sopra (rebase)?
• Ripristinare o correggere nella versione successiva?

Inizialmente ho tradotto ovunque termini come "pull request", ma alla fine ho deciso di ripristinare alcune frasi in inglese in alcuni punti per ridurre il grado di assurdità nel testo. A volte userò un 'gergo da programmatore' come il curioso verbo "committare" dove le persone lo usano realmente sul lavoro.

Che cos'è l'integrazione continua?

Integrazione continua, o CI, è una pratica tecnica che implica che ogni membro del team integri il proprio codice nel repository comune almeno una volta al giorno, e il codice risultante deve essere in grado di compilarsi senza errori.

Ci sono divergenze riguardo questo termine

L'oggetto della disputa è la frequenza di integrazione. Alcuni sostengono che unire il codice solo una volta al giorno non sia sufficiente e che l'integrazione debba avvenire in modo continuo. Viene citato come esempio un team in cui tutti prelevano il codice aggiornato al mattino e si integrano una volta alla sera. Sebbene questa sia un'obiezione ragionevole, si considera comunque che la definizione 'una volta al giorno' sia sufficientemente pratica, precisa e adatta a team di varie dimensioni.

Un'altra obiezione è che C++ non è più l'unico linguaggio utilizzato nello sviluppo, e la semplice richiesta di una compilazione senza errori, come modo di validazione, è insufficiente. Un certo insieme di test (ad esempio, unitari, eseguiti localmente) dovrebbe anche concludersi positivamente. Attualmente, la comunità tende a voler rendere tale requisito obbligatorio, e in futuro 'compilazione + test unitari' probabilmente diventerà la norma, se non è già accaduto.

Integrazione continua si differenzia da consegna continua (Continuous Delivery, CD) in quanto non richiede un candidato al rilascio dopo ogni ciclo di integrazione.

Elenco dei passaggi che utilizzeremo durante il corso

1. Preleva l'ultimo codice. Crea un ramo da master. Inizia a lavorare.
2. Crea commit nel tuo nuovo ramo. Compila e testa localmente. Passato? Vai al passaggio successivo. Fallito? Correggi errori o test e riprova.
3. Pusha nel tuo repository remoto o nel ramo remoto.
4. Crea una richiesta di pull. Discuta le modifiche, aggiungi ulteriori commit mentre la discussione continua. Fai passare i test nel ramo della funzionalità.
5. Unisci/riforma i commit da master. Fai passare i test sul risultato dell'unione.
6. Distribuisci dal ramo della funzionalità alla produzione.
7. Se tutto va bene in produzione per un certo periodo, unisci le modifiche a master.

️ Preparazione

Assicurati di avere il software necessario

Per seguire questo corso avrai bisogno di Node.js e client Git.

Puoi utilizzare qualsiasi client Git, ma fornirò solo i comandi per la riga di comando.

Assicurati di avere installato un client Git che supporti la riga di comando

Se non hai ancora installato un client Git che supporti la riga di comando, puoi trovare le istruzioni per l'installazione qui.

Prepara il repository

Dovrai creare una copia personale (fork) del repository modello con il codice per il corso su GitHub. D'accordo, chiamiamo questa copia personale repository del corso.

Fatto? Se non avete cambiato le impostazioni predefinite, il vostro repository del corso probabilmente si chiama continuous-integration-team-scenarios-students, è nel vostro account GitHub e l'URL appare così

https://github.com//continuous-integration-team-scenarios-students

Io chiamerò questo indirizzo semplicemente <URL репозитория>.

Le parentesi angolari come <тут> indicheranno che dovete sostituire espressioni come queste con i valori corrispondenti.

Assicuratevi che GitHub actions siano attive per questo repository del corso. Se non sono attive, per favore attivatele cliccando il grande pulsante al centro della pagina, che potete raggiungere facendo clic su Actions nell'interfaccia di GitHub.

Non potrete completare il corso seguendo le mie istruzioni se GitHub Actions non saranno attive.

Potete sempre utilizzare la funzione di GitHub per visualizzare Markdown per vedere lo stato attuale della lista che stiamo creando, qui

https://github.com//continuous-integration-team-scenarios-students/blob/master/ci.md

Riguardo le risposte

Anche se il modo migliore per completare questo corso è fare tutto da soli, potreste incontrare delle difficoltà.

Se sentite di non capire cosa fare e non potete andare avanti, potete dare un'occhiata al ramo solution, che è presente nel vostro repository di partenza.
Per favore, non effettuate merge solution in master durante il corso. Potete utilizzare questo ramo per capire cosa fare, o per confrontare il vostro codice con quello originale, utilizzando tutte le funzionalità che Git ci offre. Se siete completamente persi, potete sostituire completamente il vostro ramo master con il ramo solution e poi resettare la vostra directory di lavoro allo stato del corso che vi serve.

Usate questo solo se ne avete veramente bisogno

Commitate il vostro codice

git add .
git commit -m "Backup del mio lavoro"

Questi comandi

• rinominano master in master-backup;
• rinominano solution in master;
• switchano (checkout) su un nuovo ramo master e sovrascrivono il contenuto della directory di lavoro;
• creano un ramo "solution" da "master" (che prima era "solution") nel caso aveste bisogno del ramo "solution" in futuro.

git branch -m master master-backup
git branch -m solution master
git checkout master -f
git branch solution

Dopo queste operazioni, potete utilizzare git log master per scoprire quale commit vi serve.
Potete ripristinare la vostra directory di lavoro a questo commit così:

git reset --hard

Se sei soddisfatto del risultato, a un certo punto dovrai pubblicare le tue versioni del repository in un repository remoto. Non dimenticare di specificare esplicitamente il ramo remoto quando lo fai.

git push --force origin master

Si prega di notare che utilizziamo git push --force. È improbabile che tu voglia farlo spesso, ma abbiamo qui uno scenario estremamente specifico con un utente del repository che, per di più, sa cosa sta facendo.

Iniziamo a lavorare

Iniziamo a compilare la nostra lista di passi CI. Di solito inizi questo passo estraendo l'ultima versione del codice dal repository remoto, ma non abbiamo ancora un repository locale, quindi invece lo cloniamo dal remoto.

️ Compito: aggiorna il repository locale, crea un ramo da master, inizia a lavorare

1. Clona il repository del corso da <URL репозитория>.
2. Esegui npm install nella cartella del repository del corso; ci serve per installare Jest, che usiamo per eseguire i test.
3. Crea un ramo e chiamalo feature. Passa a questo ramo.

4. Aggiungi codice di test in ci.test.js tra i commenti con la richiesta di farlo.

   it('1. estrai l'ultima versione del codice', () => {
     expect(/.*pull.*?/ig.test(fileContents)).toBe(true);
   });
   
   it('2. aggiungi commit', () => {
     expect(/.*commit.*?/ig.test(fileContents)).toBe(true);
   });
   
   it('3. esegui il push al ramo remoto con lo stesso nome', () => {
     expect(/.*push.*?/ig.test(fileContents)).toBe(true);
   });
   
   it('4. crea una richiesta di pull e continua a lavorare', () => {
     expect(/.*pulls+request.*?/ig.test(fileContents)).toBe(true);
   });

5. Aggiungi il testo con i primi 4 passi nel file ci.md.

   1. Esegui il pull dell'ultima versione del codice. Crea un ramo da `master`. Inizia a lavorare.    
   2. Crea commit sul tuo nuovo ramo. Compila e testa localmente.  
   Passato? Vai al passo successivo. Fallito? Correggi errori o test e riprova.  
   3. Esegui il push nel tuo repository remoto o ramo remoto.  
   4. Crea una richiesta di pull. Discusso le modifiche, aggiungi altri commit  
   mano a mano che la discussione continua. Fai passare i test sul ramo feature.  

   Team

# Клонируйте репозиторий курса
git clone <repository URL>
cd <repository name>

# Выполните npm install в каталоге репозитория курса; он установит Jest, который мы используем для запуска тестов.
npm install

# Создайте ветку и назовите ее feature. Переключитесь на эту в ветку.
git checkout -b feature

# Отредактируйте ci.test.js как описано выше.
# Отредактируйте ci.md как описано выше

Crea commit nel nuovo ramo, compila e testa localmente

Stiamo per impostare i test affinché vengano eseguiti prima del commit, e poi faremo il commit del codice.

Scenari tipici in cui i test vengono eseguiti automaticamente

• Localmente:
  • Continuamente o in risposta a modifiche pertinenti nel codice;
  • Al salvataggio (per linguaggi interpretati o compilati JIT);
  • Durante la compilazione (quando è necessaria la compilazione);
  • Al momento del commit;
  • Quando si pubblica in un repository condiviso.

• Sul server di build o nell'ambiente di build:
  • Quando il codice viene pubblicato in un ramo/repository personale.
  • Il codice viene testato in questo ramo.
  • Il risultato potenziale di una fusione viene testato (di solito con master).
  • Come fase della integrazione continua / del pipeline di consegna continua

In genere, più velocemente vengono eseguiti i test, più spesso puoi permetterti di eseguirli. Una tipica distribuzione delle fasi può apparire così.

• Test unitari rapidi - durante la build, nella pipeline CI
• Test unitari lenti, test rapidi dei componenti e test di integrazione - durante il commit, nella pipeline CI
• Test lenti dei componenti e di integrazione - nella pipeline CI
• Test di sicurezza, test di carico e altri test lunghi o costosi - nelle pipeline CI / CD, ma solo in determinati modi / fasi / pipeline di build, ad esempio durante la preparazione di un candidato al rilascio o quando eseguiti manualmente.

️ Compito

Propongo di eseguire prima i test manualmente, utilizzando il comando npm test. Dopo di che, aggiungiamo un git hook per eseguire i nostri test al momento del commit. C'è un problema: i Git hook non sono considerati parte del repository, quindi non possono essere clonati da GitHub insieme agli altri materiali del corso. Per installare il hook, devi eseguire install_hook.sh o copiare il file repo/hook/pre-commit nella cartella locale .git/hooks/.
Al momento del commit vedrai che vengono eseguiti test e verificheranno se alcuni termini chiave sono presenti nell'elenco.

1. Esegui i test manualmente, utilizzando il comando npm test nella cartella del tuo repository del corso. Assicurati che i test siano stati eseguiti.
2. Imposta un hook per il commit (pre-commit hook) eseguendo install_hook.sh.
3. Fai il commit delle modifiche nel repository locale.
4. Assicurati che i test vengano eseguiti prima del commit.

Il tuo repository dovrebbe apparire così dopo aver eseguito queste azioni.

Team

# Установите pre-commit hook выполнив install_hook.sh.  

# Закоммитьте изменения в локальный репозиторий. Используйте "Add first CI steps" в качестве сообщения при коммите.
git add ci.md ci.test.js
git commit -m "Add first CI steps"

# Убедитесь, что тесты запускаются перед коммитом.  

Pubblica il codice nel repository remoto o in un ramo remoto

Una volta completato il lavoro in locale, gli sviluppatori di solito rendono il proprio codice pubblico affinché possa essere infine integrato con quello condiviso. Con GitHub, questo di solito si ottiene pubblicando il lavoro in una copia personale del repository (fork personale) o in un ramo personale.

• Utilizzando i fork, lo sviluppatore clona un repository remoto condiviso, creando una copia remota personale, nota come fork. Dopo, clona questo repository personale per lavorarci localmente. Quando il lavoro è completato e i commit sono creati, li inserisce nel proprio fork, dove sono accessibili ad altri e possono essere integrati nel repository condiviso. Questo approccio è comunemente usato nei progetti open source su GitHub. È anche utilizzato nel mio corso avanzato [Team Work and CI with Git] (http://devops.redpill.solutions/).
• Un altro approccio è quello di utilizzare solo un repository remoto e considerare solo il ramo master del repository condiviso "protetto". In questo scenario, i singoli sviluppatori pubblicano il loro codice in rami del repository remoto, in modo che altri possano visualizzare questo codice, se va tutto bene, fondere con master il repository comune.

In questo corso specifico utilizzeremo un flusso di lavoro che utilizza i rami.

Pubbliciamo il nostro codice.

️ Compito

• Pubblica le modifiche nel ramo remoto con lo stesso nome del tuo ramo di lavoro

Team

git push --set-upstream origin feature

Crea una pull request

Crea una pull request con il titolo Steps review. Imposta feature come "head branch" e master come "base branch".

Assicurati di aver impostato master nel tuo fork del repository come "base branch", non risponderò a richieste di modifica nel repository con i materiali del corso.

Nel gergo di GitHub, "base branch" è il ramo su cui basi il tuo lavoro, mentre "head branch" è il ramo che contiene le modifiche proposte.

Discuti le modifiche, aggiungi nuovi commit man mano che la discussione continua

La pull request (PR)

La pull request (PR) è un modo per discutere e documentare il codice, nonché per condurre una revisione del codice (code review). Le pull request prendono il nome da un modo comune di integrare le singole modifiche nel codice condiviso. Di solito, una persona clona un repository remoto ufficiale del progetto e lavora sul codice localmente. Successivamente, inserisce il codice nel proprio repository remoto personale e chiede ai responsabili del repository ufficiale di prelevare (pull) il suo codice nei propri repository locali, dove lo esaminano e, se necessario, lo integrano (merge) nel codice. Questo concetto è anche noto con altri nomi, come merge request.

In realtà, non è necessario utilizzare la funzione di pull request di GitHub o piattaforme simili. I team di sviluppo possono utilizzare altri metodi di comunicazione, inclusi colloqui faccia a faccia, telefonate o e-mail, ma ci sono comunque diverse ragioni per utilizzare tali pull request in stile discussione su un forum. Ecco alcune di esse:

• discussioni organizzate relative a cambiamenti specifici nel codice;
• come luogo per visualizzare feedback su lavori non completati sia da test automatici che da colleghi;
• formalizzazione delle revisioni del codice;
• per poter successivamente chiarire le ragioni e le considerazioni dietro a un determinato frammento di codice.

Di solito, crei una pull request quando hai bisogno di discutere qualcosa o ricevere feedback. Ad esempio, se stai lavorando a una funzionalità che può essere implementata in vari modi, puoi creare una richiesta di modifica prima ancora di scrivere la prima riga di codice, per condividere le tue idee e discutere i tuoi piani con i co-autori. Se il lavoro è più semplice, la pull request viene aperta quando qualcosa è già stato completato, registrato e può essere discusso. In alcuni scenari, puoi aprire un PR solo per motivi di controllo della qualità: per eseguire test automatici o avviare una revisione del codice. Qualunque cosa tu decida, non dimenticare di @menzionare le persone il cui approvazione è necessaria nella tua pull request.

Di solito, quando crei un PR, fai quanto segue.

• Indichi cosa stai proponendo di modificare e dove.
• Scrivi una descrizione che spiega lo scopo delle modifiche. Puoi voler:
  • aggiungere qualcosa di importante che non è ovvio dal codice, o qualcosa di utile per comprendere il contesto, come bug correlati e numeri dei commit;
  • @menzionare tutti con cui desideri iniziare a collaborare, oppure puoi @menzionarli nei commenti in un secondo momento;
  • chiedere ai colleghi di aiutarti con qualcosa o di controllare qualcosa in particolare.

Dopo aver aperto un PR, vengono eseguiti i test configurati per essere eseguiti in tali situazioni. Nel nostro caso, sarà lo stesso set di test che abbiamo eseguito localmente, ma in un progetto reale potrebbero esserci test e verifiche aggiuntive.

Si prega di attendere il completamento dei test. Puoi visualizzare lo stato dei test nella parte inferiore della discussione della PR nell'interfaccia di GitHub. Procedi quando i test saranno terminati.

️ Aggiungi una nota sulla casualità dell'elenco dei passaggi CI

L'elenco utilizzato in questo corso è casuale e soggettivo, dobbiamo aggiungere una nota a riguardo.

️ Compito: creare una richiesta di pull per questa annotazione

1. auth0 master.
2. Crea un branch di nome bugfix.
3. Aggiungi il testo dell'annotazione alla fine del file ci.md.

   > **GitHub flow** è talvolta usato come soprannome per riferirsi a un tipo di sviluppo basato su trunk quando il codice viene distribuito direttamente dai branch delle funzionalità. Questo elenco è solo un'interpretazione che utilizzo nei miei [corsi DevOps](http://redpill.solutions). Il tutorial ufficiale è [qui](https://guides.github.com/introduction/flow/).

4. Commetti le modifiche.
5. Pubblica il branch bugfix nel repository remoto.
6. Crea una richiesta di pull di nome Aggiunta di una nota con il branch principale bugfix e il branch basemaster.

Assicurati di aver impostato master nel tuo fork del repository come "base branch", non risponderò a richieste di modifica nel repository con i materiali del corso.

Ecco come dovrebbe apparire il tuo repository.

Team

# Переключитесь на ветку master. Создайте ветку bugfix.
git checkout master

# Создайте ветку bugfix-remark.
git checkout -b bugfix

# Добавьте текст примечания внизу ci.md.

# Закоммитьте изменения
git add ci.md
git commit -m "Add a remark about the list being opinionated"

# Опубликуйте ветку bugfix в удалённый репозиторий.
git push --set-upstream origin bugfix

# Создайте pull request при помощи интерфейса GitHub как описано выше

Approva la richiesta di pull "Aggiunta di una nota"

️ Compito

1. Crea una richiesta di pull.
2. Clicca su "Unisci richiesta di pull".
3. Clicca su "Conferma unione".
4. Clicca su "Elimina branch", non ci serve più.

Questo è un diagramma dei commit dopo l'unione.

️ Continua a lavorare e ad aggiungere test

Lavorare insieme su una richiesta di pull spesso porta alla necessità di ulteriore lavoro. Di solito è il risultato di una revisione del codice o di una discussione, ma nel nostro corso simuleremo questo aggiungendo nuovi elementi alla nostra lista di passaggi CI.

Nell'integrazione continua viene di solito applicata una certa copertura di test. I requisiti di copertura dei test variano e si trovano di solito in un documento intitolato "linee guida per i contributori". Procederemo semplicemente aggiungendo un test per ogni voce nella nostra lista di controllo.

Quando svolgi i compiti, prova prima a commettere i test. Se hai impostato correttamente il pre-commit hook in precedenza, il test appena aggiunto verrà eseguito, non passerà e nulla verrà commesso. Nota: in questo modo scopriremo che i nostri test controllano effettivamente qualcosa. Curiosamente, se avessimo iniziato con il codice prima dei test, il superamento dei test potrebbe significare che il codice funziona come previsto oppure che i test in realtà non controllano nulla. Inoltre, se non avessimo scritto i test in primo luogo, potremmo dimenticarli del tutto, poiché nulla ci ricorderebbe di farlo.

Sviluppo guidato dai test (TDD)

Il TDD raccomanda di scrivere i test prima del codice. Il normale processo di lavoro utilizzando TDD sembra così.

1. Aggiungi un test.
2. Esegui tutti i test e assicurati che il nuovo test non superi.
3. Scrivi il codice.
4. Esegui i test, assicurati che tutti i test superino.
5. Esegui il refactoring del codice.
6. Ripeti.

Poiché i risultati dei test, che non sono stati superati, vengono solitamente mostrati in rosso, e quelli superati in verde, questo ciclo è anche noto come 'rosso-verde-refactoring'.

️ Compito

Prima prova a fare il commit dei test e a farli fallire, poi aggiungi e commit il testo della lista dei passi CI. Vedrai che i test passano ("verdi").
Poi pubblica il nuovo codice nel repository remoto e osserva come vengono eseguiti i test nell'interfaccia di GitHub nella parte inferiore della discussione della pull request, e lo stato del PR viene aggiornato.

1. auth0 feature.

2. Aggiungi questi test a ci.test.js dopo l'ultima chiamata it (...);.

   it('5. Unisci/ribalta i commit da master. Fai passare i test sul risultato della fusione.', () => {
     expect(/.*merge.*commits.*testss+pass.*/ig.test(fileContents)).toBe(true);
   });
   
   it('6. Distribuisci dal ramo di funzionalità alla produzione.', () => {
     expect(/.*Deploy.*tos+production.*/ig.test(fileContents)).toBe(true);
   });
   
   it('7. Se tutto è buono in produzione per un certo periodo di tempo, unisci le modifiche a master.', () => {
     expect(/.*merge.*tos+master.*/ig.test(fileContents)).toBe(true);
   });

3. Prova a fare il commit dei test. Se pre-commit il hook è impostato, il tentativo di commit fallirà.
4. Dopo aggiungi questo testo a ci.md.

   5. Unisci/ribalta i commit da master. Fai passare i test sul risultato della fusione.
   6. Distribuisci dal ramo di funzionalità con un bug furtivo alla produzione.
   7. Se tutto è buono in produzione per un certo periodo di tempo, unisci le modifiche a master. 

5. Fai le modifiche e commit localmente.
6. Pubblica le modifiche nel ramo feature.

Ora dovresti avere qualcosa di simile a questo

Team

# Переключительна ветку feature
git checkout feature

# Добавить тесты в ci.test.js как описано выше

# Добавьте в индекс ci.test.js чтобы позже закоммитить
git add ci.test.js

# Попытайтесь закоммитить тесты. Если pre-commit hook установлены, коммит не произойдёт.
git commit

# Теперь добавьте текст в ci.md как описано выше

# Внесите изменения и закоммитьте их
git add ci.md
git commit -m "Add the remaining CI steps"

# Опубликуйте изменения в ветку feature
git push

Conflitto di fusione

Vai alla pull request Steps review.

Anche se non abbiamo fatto nulla di sbagliato e i test per il nostro codice sono passati, non possiamo ancora unire il ramo. feature e master. Questo perché un altro ramo bugfix è stato unito con master mentre lavoravamo su questo PR.
Questo crea una situazione in cui il ramo remoto master ha una versione più recente rispetto a quella su cui abbiamo basato il ramo. feature. A causa di ciò, non possiamo semplicemente riavvolgere l'HEAD master fino alla fine del ramo. feature. In questa situazione dobbiamo o unire (merge) o applicare i commit feature sopra (rebase) master. GitHub può effettivamente eseguire fusioni automatiche se non ci sono conflitti. Purtroppo, nella nostra situazione entrambe le branche hanno modifiche in conflitto nel file ci.md. Questa situazione è nota come conflitto di fusione (merge conflict) e dobbiamo risolverla manualmente.

Merge o rebase

Merge

• Crea un commit di fusione (merge commit) aggiuntivo e mantiene la cronologia delle operazioni.
  • Mantiene i commit originali delle branche con le rispettive timestamp e autori.
  • Conserva gli SHA dei commit e i riferimenti a questi nelle discussioni delle richieste di modifica.
• Richiede una soluzione unica dei conflitti.
• Rende la cronologia non lineare.
  • La cronologia può risultare difficile da leggere a causa del gran numero di branche (sembra un cavo IDE).
  • Complica il debug automatico, rendendo ad esempio git bisect meno utile: troverà solo il commit di fusione.

Rebase

• Riproduce i commit dell'attuale branch sopra la base uno alla volta.
  • Si formano nuovi commit con nuovi SHA, il che fa sì che i commit su GitHub siano associati alle richieste di pull originali, ma non ai commenti corrispondenti.
  • I commit possono essere ricombinati e modificati nel processo o persino uniti in uno solo.
• Potrebbe essere necessario risolvere più conflitti.
• Permette di mantenere una cronologia lineare.
  • La cronologia può essere più semplice da leggere, a meno che non sia eccessivamente lunga senza ragioni valide.
  • Il debug automatico e la risoluzione dei problemi sono un po' più semplici: rende possibile git bisect, potrebbe rendere i rollback automatici più chiari e prevedibili.
• Richiede la pubblicazione del branch con i commit trasferiti con l'opzione --force quando usato con le richieste di modifica.

Di solito, i team concordano di utilizzare sempre la stessa strategia quando devono fondere le modifiche. Questo può comportare una fusione "pulita" o un'applicazione "pulita" dei commit sopra, oppure qualcosa di intermedio, come eseguire l'applicazione dei commit in modalità interattiva (git rebase -i) localmente per branche non pubblicate in un repository comune, ma con merge per le branche "pubbliche".

Qui utilizzeremo il merge.

️ Compito

1. Assicurati che il codice nel branch locale master sia aggiornato dal repository remoto.
2. auth0 feature.
3. Inizia la fusione con il branch master. Verrà segnalato un conflitto di fusione relativo a modifiche in conflitto in ci.md.
4. Risolvete il conflitto in modo che nel testo rimanga sia la nostra lista di passaggi CI che una nota su di essa.
5. Pubblica il commit di merge nel ramo remoto feature.
6. Controlla lo stato della pull request nell'interfaccia utente di GitHub, aspettando finché il merge non viene risolto.

Team

# Убедитесь, что код в локальное ветке `master` обновлён из удалённого репозитория.
git checkout master
git pull

# Переключитесь на ветку feature
git checkout feature

# Инициируйте слияние с веткой master 
git merge master

# A merge conflict related to concurrent changes to ci.md will be reported
# => Auto-merging ci.md
#    CONFLICT (content): Merge conflict in ci.md
#    Automatic merge failed; fix conflicts and then commit the result.

# Разрешите конфликт так, чтобы и наш список шагов CI, и замечание о нем остались в тексте.
# отредактируйте ci.md чтоб он не содержал маркеров конфликта слияния
git add ci.md
git merge --continue
# при коммите можете оставить сообщение по умолчанию

# Опубликуйте коммит слияния в удаленную ветку feature.
git push

# Проверьте статус запроса на изменения в пользовательском интерфейсе GitHub, дождитесь пока слияние не будет разрешено.

Ottimo lavoro!

Hai terminato di lavorare con la lista, e ora devi approvare la pull request in master.

️ Compito: Approva la pull request "Steps review"

1. Apri la pull request.
2. Clicca su "Unisci richiesta di pull".
3. Clicca su "Conferma unione".
4. Clicca su "Delete branch", poiché non ci serve più.

Questo è il tuo repository attualmente

Errore in produzione

Si dice che "i test possono essere usati per dimostrare la presenza di bug, ma mai per dimostrare la loro assenza". Anche se avevamo dei test che non ci hanno mostrato bug, un insidioso errore è riuscito a entrare in produzione.

In uno scenario simile, dobbiamo prenderci cura di:

• quello che è stato distribuito in produzione;
• il codice nel ramo master con il bug, da cui gli sviluppatori possono iniziare a lavorare di nuovo.

Rolback o correggere nella prossima versione?

"Rollback" è il deployment di una versione precedente nota per essere corretta in ambiente di produzione e il revert dei commit contenenti bug. "Correggere nella prossima versione" significa aggiungere una correzione in master e distribuire una nuova versione il prima possibile. Poiché le API e gli schemi del database cambiano nel corso del deployment del codice in un ambiente di produzione, con la consegna continua e una buona copertura di test, il rollback è generalmente molto più complesso e rischioso rispetto alla correzione nella prossima versione.

Poiché il rollback non comporta alcun rischio nel nostro caso, seguiremo questa strada, in quanto ci permette di

• correggere il bug in produzione il prima possibile;
• rendere il codice in master subito pronto per iniziare un nuovo lavoro.

️ Compito

1. auth0 master localmente.
2. Aggiorna il repository locale dal repository remoto.
3. Annulla il commit di merge della PR Steps review in master.
4. Pubblica le modifiche nel repository remoto.

Questa è la cronologia del repository con il commit di merge annullato

Team

# Переключитесь на ветку master.
git checkout master

# Обновите локальный репозиторий из удалённого репозитория.
git pull

# Отмените коммит слияния PR Steps review в master.
# Мы отменяем коммит слияния, поэтому нам нужно выбрать ветку истории, которую мы захотим оставить
git show HEAD

# предположим, что коммит, который был последним в ветке master до слияния, был отображён предыдущей командой первым
git revert HEAD -m 1
# можете не менять сообщения коммитов

# Опубликуйте изменения в удалённый репозиторий
git push

️ Auto-verifica

Assicurati che ci.md non contiene più il testo "sneaky bug" dopo l'annullamento del commit di merge.

Correggi la lista dei passaggi CI e restituiscila a master

Abbiamo completamente annullato il commit di merge del ramo feature. La buona notizia è che ora non abbiamo più errori in master. La cattiva notizia è che è scomparsa la nostra preziosa lista di passaggi per l'integrazione continua. Quindi, idealmente, dobbiamo applicare la correzione ai commit da feature e riportarli in master insieme alla correzione.

Possiamo affrontare il compito in vari modi:

• annullare (revert) il commit che annulla la fusione feature con master;
• spostare i commit dalla precedente feature.

Diverse squadre di sviluppo usano approcci diversi in questo caso, noi sposteremo i commit utili in un ramo separato e creeremo una pull request separata per questo nuovo ramo.

️ Compito

1. Crea un ramo chiamato feature-fix e passa a esso.

2. Sposta tutti i commit dal ramo precedente feature al nuovo ramo. Risolvi i conflitti di fusione che si sono verificati durante lo spostamento.

   

3. Aggiungi un test di regressione in ci.test.js:

   it('does not contain the sneaky bug', () => {
   expect( /.*sneakys+bug.*/gi.test(fileContents)).toBe(false);
   });

4. Esegui i test localmente per assicurarti che non si completino con successo.
5. Rimuovi il testo " with a sneaky bug" in ci.md.
6. Aggiungi all'indice le modifiche ai test e le modifiche alla lista dei passaggi e commitale.
7. Pubblica il ramo nel repository remoto.

Dovresti risultare con qualcosa di simile

Team

# Создайте ветку под названием feature-fix и переключитесь на нее.
git checkout -b feature-fix

# Перенесите все коммиты из бывшей ветки feature в новую ветку. Разрешите конфликты слияния, которые возникли при переносе.
# используйте историю чтобы узнать хэши коммитов:
# - предшествующего коммиту с первой частью списка: C0
# - добавляющего последние элементы списка: C2
git log --oneline --graph
git cherry-pick C0..C2
# разрешите конфликты слияния
# - отредактируйте ci.md и/или ci.test.js
# - добавьте файлы в индекс
# - выполните "git cherry-pick --continue", можете не менять сообщение коммита

# Добавьте регрессионный тест в ci.test.js
# Запустите тесты локально, чтобы убедиться, что они не завершаются успешно.

# Удалите текст " with a sneaky bug" в ci.md.

# Добавьте в индекс изменения тестов и в списке шагов и закоммитьте их.
git add ci.md ci.test.js
git commit -m "Fix the bug in steps list"

# Опубликуйте ветку в удалённый репозиторий.
git push --set-upstream origin feature-fix

Crea una richiesta di pull.

Crea una pull request con il titolo Fixing the feature. Imposta feature-fix come "head branch", e master come "base branch".
Per favore, aspetta che i test vengano completati. Puoi vedere lo stato dei test nella parte inferiore della discussione PR.

Assicurati di aver impostato master nel tuo fork del repository come "base branch", non risponderò a richieste di modifica nel repository con i materiali del corso.

Approva la pull request "Fixing the feature"

Grazie per la correzione! Ti prego di approvare le modifiche in master dalla pull request.

️ Compito

1. Clicca su "Unisci richiesta di pull".
2. Clicca su "Conferma unione".
3. Clicca su "Delete branch", poiché non ci serve più.

Questo è ciò che dovresti avere in questo momento

Congratulazioni!

Hai completato tutte le azioni che le persone normalmente compiono nel processo di integrazione continua.

Se hai notato problemi con il corso o sai come migliorarlo, crea un'issue in repository con i materiali del corso. Questo corso ha anche una versione interattiva che utilizza GitHub Learning Lab come piattaforma.

Fonte: habr.com