Tag Archives: git

How to release a hotfix with pull-request inside VSTS in 3 steps

We all know the situation: the customer finds a critical bug in the latest release and he wants us to release a new version of our application with a fix. How do we handle this situation without breaking our team policies? How to release a specific fix to avoid regression problems?

First we need to fix that bug with the classical approach of feature-branches. We create a branch, fix the bug, create a pull-request and the team approves. These activities are set at the highest priority because a customer is in trouble and we must help.

Now we are in a situation where we have a specific commit that solves a specific problem with only the necessary lines of code modified.

commit-with-fix.png

Our target is to ship that specific commit that fixes that specific bug with a standard pull-request, without all the other work done in the development branch since the latest release. So we write down (in our clipboard for example) the id of the commit.

shaid

What can we do now to release?

1. New branch

We create a new branch.

git checkout -b my-hotifx

Now we fetch the latest updates from the remote repo.

git fetch origin

Then we set our branch my-hotfix to point to the latest commit of the remote release branch.

git reset --hard origin/release

branch-release.png

2. Cherry-pick

Now we cherry-pick the specific commit we want to apply to the release branch without commiting (–no-commit option). We choose the no-commit option to carefully inspect what is going on in our files. It’s here where we use the commit id we saved early.

git cherry-pick <commit-hash> --no-commit

We verify that everything is fine (where fine depends on your specific project). Now we can commit and push to VSTS.

git add .
git commit -m "Hotfix"
git push origin mybranch:mybranch

final-situation-1

3. Open pull-request

Our branch is now on the remote repo and we can open the pull-request with VSTS.

pull-request.png

From here the team can approve the PR and fire up our automated release process that activates our automated test and if everything is fine we deploy safely.

TL; DR

With this blog post we explored the critical situation to release a hotfix without breaking the rules or taking shortcuts to avoid our release pipeline. As engineers we must maintain a cold approach even in hot situation and rely on our best practices. Human errors are always possible in particular when we’re stressed and a customer is making our phones hot.

Agile@School – Inizio

Anche l’ITI F.Viola/Marchesini di Rovigo si è unito ufficialmente al progetto esperimento/laboratorio Agile@School basato sull’idea e il supporto di Alessandro Alpi.

Immagine

Il tutto è stato inserito nelle attività ufficiali di alternanza scuola-lavoro dei ragazzi delle due quinte dell’istituto rodigino.

Il laboratorio ha come obiettivo introdurre i ragazzi ai concetti Agile e di lavoro in team: si mettono le mani in pasta e si utilizzano strumenti all’avanguardia del mondo professionale per realizzare un’app con Xamarin.

Nelle tre ore di laboratorio abbiamo toccato svariate argomentazioni e devo fare i complimenti ai ragazzi per essere stati complici e attivi in questo inizio di percorso tutto da esplorare.

  • Abbiamo introdotto i primi concetti e terminologia del mondo Agile e delle sostanziali differenze di cosa vuol dire fare un software per hobby/studio e farlo professionalmente.
  • Abbiamo esplorato le funzionalità di base di VSTS (Visual Studio Team Services) creando varie tipologie di PBI e mettendole in relazione per far capire come si possono condividere informazioni tra i vari ruoli in un team: il punto di vista del developer, del referente di progetto (middle management) e di un livello ancora più alto. Abbiamo esplorato le board e i backlog.
  • Abbiamo simulato un flusso di lavoro con feature-branch con git e Team Explorer di Visual Studio.

Come primo incontro è stato molto ambizioso, ci sono stati dei momenti più coinvolgenti e altri meno: molto è sicuramente da imputare alla mia inesperienza come formatore ma farò il possibile per calibrare sempre meglio i contenuti e le mie capacità.

Mi ha sorpreso positivamente vedere come alcuni studenti avessero già mosso i primi passi su GitHub e conoscessero il funzionamento di branch e pull-request.

Un grazie particolare va ai professori del corso di informatica e sistemi che hanno sin da subito appoggiato e creduto in questo progetto. Grazie prof. Borsetto, prof. Melon e prof.ssa. Bellini.

Alla settimana prossima!

Inferno

L’inferno esiste.

Per noi programmatori ce ne sono di due tipi, anzi. Il dll-hell e il merge-hell.

Il primo l’ho raramente sperimentato mentre di recente sono rimasto scottato dal secondo. Un paio di branch avevano preso la tangente da qualche mese rispetto al master ed era giunto il momento di prendere il coraggio a piene mani e farlo tornare a casa con un bel merge. Si salvi chi può.

Cosa mai potrebbe andare storto, fa tutto git! Sì sì, certo… Preparatevi a:

  • Risolvere conflitti di pezzi di codice che non avete scritto voi;
  • Mantenere inalterate le funzionalità;
  • Gestire problemi sui file .resx in particolare per le stringhe e la localizzazione;
  • Inveire contro i comandi di git;
  • Una combinazione di tutte le precedenti.

Sono quelle cose che leggi e poi dici: “ah ma tanto a me non capita! Il mio è un progetto piccolo e poi cosa vuoi avrò toccato un paio di classi in quel branch.”. E invece!

P.S.: mi permetto di dare un piccolo consiglio. Fatelo in coppia. In questi casi il pair programming vince a mani basse per quanto mi riguarda!

Alla ricerca del commit perduto

Una delle certezze che si ha usando git è che quando qualcosa è stato salvato con un commit è scolpito nella pietra e quasi impossibile da perdere. Maneggiando con GitKraken ho fatto degli errori e ho fatto dei passaggi che mi hanno portato a perdere un branch. Era un branch di esperimenti con cose di poco conto ma ci tenevo a recuperare il lavoro svolto.

Col comando

git reflog

ho ottenuto la cronologia di tutte le ultime operazioni fatte con un risultato di questo tipo:

image

Ho individuato (in rosso) il commit di mio interesse: 8cfba14.

A questo punto il gioco è fatto:

git checkout 8cfba14

ho controllato il contenuto e ovviamente c’era tutto, ora basta fare un nuovo branch

git branch wallpaper 8cfba14

così da avere un comodo riferimento a quel commit come era prima dei miei errori.

Le interfacce grafiche costruite sopra git sono molto comode per la routine quotidiana e hanno spesso un look accattivante e generano un albero della cronologia molto chiaro. Tuttavia a volte non si capisce bene cosa facciano sotto il cofano e fanno cose inaspettate.image

La riga di comando permette un controllo totale, chirurgico. Penso che conoscere bene la riga di comando di git sia uno dei fondamenti da cui non possiamo prescindere perché significa essere in grado di salvaguardare/recuperare/manutenzionare le preziose ore di lavoro che ogni giorno dedichiamo alla nostra passione. È la nostra cassaforte con super poteri di viaggio nel tempo, funzioni di ricerca (lo sapevate git grep?) e molto altro. Vale la pena conoscerla a fondo.