Agile versioning with Git
•Descargar como PPTX, PDF•
4 recomendaciones•1,365 vistas
MiniIAD201, Savona, 16/04/2016 Il breve racconto dell'esperienza maturata in questa piccola-grande pratica del lavoro di un programmatore: dietro ciò che sembra una mera prassi, si cela la chiave di volta dell'agilità. Attraverso un suo uso consapevole, è possibile migliorare sia come professionista (ad es. imparando a suddividere il lavoro in piccoli task al fine di confezionare commit piccoli e significativi, oppure usando branch locali per sperimentare e di conseguenza imparare), sia come membro di un team (ad es. usando le pull-request come modo per condividere il codice ed eventualmente promuovere le code review). Servono impegno e disciplina, come in tutte le cose importanti, ma alla fine si ottengono dei grossi risultati, sia in termini di crescita professionale che di consapevolezza rispetto ai princìpi delle metodologie agili. Nella presentazione verrà menzionato Git, ma tutto il discorso prescinde dallo specifico strumento; inoltre non è previsto l'uso o la conoscenza di codice o comandi complessi, ma l'intera discussione cercherà di far leva sulle possibilità che abbiamo di migliorare l'efficacia e la collaborazione all'interno di un team partendo da un uso più “filantropico” di questi potenti strumenti.
Recomendados
Más contenido relacionado
Destacado
Destacado (13)
Similar a Agile versioning with Git
Similar a Agile versioning with Git (20)
Más de Ferdinando Santacroce
Más de Ferdinando Santacroce (10)
Agile versioning with Git
- 2. me,myselfandI 1999: io, il mio computer, e le cose da fare (ed imparare a fare…) Versioning? Che roba è?! Qualche zip di backup basta e avanza… 2
- 3. Aprésmoi,lediluge! Tutto sotto controllo Nessun conflitto, nessun problema Il codice è mio e me lo gestisco io 3
- 4. IlmioprimoTeam Nuovi arrivi Si lavora bene in team! Tu fai le tue cose, io faccio le mie… Collaborazione? Sì Cooperazione? No (le due parole non sono esattamente sinonimi, poi ne riparliamo...) 4
- 5. Hodeciso,faròilprogrammatore Mi piace l’insegnamento La scuola (italiana) ed i suoi concorsi un po’ meno Un anno interlocutorio, con un paio di lavori poco significativi Poi il grande salto: vengo assunto da una vera software house! 5
- 6. Siiniziaafaresulserio Gestionale (COBOL) per farmacisti, up-and-running dal 1984 8000+ farmacie (50%+ del mercato!) 4/5x utilizzatori Se scazzi qualcosa non è così immediato rimediare... 6
- 7. ilCOBOL 7
- 8. DijkstraeIlCOBOL “The use of COBOL cripples the mind; its teaching should, therefore, be regarded as a criminal offense.” Edsger W. Dijkstra 8
- 9. “Amazing”GraceHopper ➔Programmed Mark I in 1944 ➔Invented 1st compiler ➔Realized one of the first machine indipendent programming language ➔Coined the term “bug” ➔Admiral of the US Navy Only joked for inventing COBOL... 9
- 10. I“veci”Cobolistielaprecisione Loro: cartella condivisa in rete Ognuno “tocca” a turno i file sorgente che deve, senza pestarsi i piedi Incredibilmente… FUNZIONA! :O 10
- 11. I“giovaniprogrammatorid’oggi” Io invece se posso combinare un casino, lo combino… Devo trovare qualcosa in grado di salvarmi da me stesso 11
- 12. Subversion Cosa usate voi per versionare il codice? Subversion! Ok, vada per Subversion 12
- 13. Subversion:dasolo Finché lo usi da solo, tutto ok Figo poter navigare la storia delle tue modifiche! Ok i tag per le release Il diff con la precedente versione ora è più pratico! 13
- 14. Unadiscaricadicodicesorgente Faccio cose, ed ogni tot scarico quanto prodotto sul server Il commit delle 18:00 Sto versionando? Mah, non mi sembra granché diverso da prima 14
- 15. SubversionelaNONcooperazione Progetti “condivisi”, ma ci si lavora uno alla volta No cooperazione Versione 2.0 del team a scuola: ognuno lavora sulle sue cose Perché? 15
- 17. Subversioneglieffetti dell’update Lavoro finito, devi committare Commit rifiutato, devi fare update... Una strage… Subversion non consente di separare l’azione di commit da quella di integrazione delle modifiche altrui 17
- 18. Subversionelapauradell’update Alla fine l’update diventa una cosa che ti spaventa, che hai paura a fare Quando “funziona” al primo colpo è quasi un evento! (anche se comunque la colpa non è tutta di Subversion… Leggasi spaghetti code) 18
- 19. Subversioneiproblemidirete Bello il repo centralizzato, ma se sono offline non posso committare E non posso fare il checkout delle modifiche degli altri E così la prossima volta che dovrò farlo sarà un casino… 19
- 20. Pernonparlaredeibranch(sonounacapra) Come gestire la risoluzione di bug? Fare branch e poi merge era un attimino complesso (per me) Diverse cartelle per diversi branch Risultato: lavorare su due funzionalità in parallelo è quasi impossibile 20
- 21. Subversion:yunowork?! Ad un certo punto ti sale una carogna che nemmeno Germano Mosconi, Nonno Fiorucci e Lugaresi da Cesenatico messi insieme… 21
- 22. LarivoluzioneAgile Primi contatti tramite i colleghi di Brescia (grazie!!) Primo Agile Day (2011, Roma) “Ragazzi, c’è un nuovo modo di approcciare lo sviluppo software!” “Bello! Ma adesso non c’è tempo, abbiamo tante cose da fare... ” 22
- 23. L’arrivodelmessia Finalmente l’azienda ci concede qualche giornata con un coach agile Adesso che l’ha detto lui, tutti ci credono… Meglio che niente, l’importante è cominciare! 23
- 24. Ruoli,lavagne,storieetask Spezzare il lavoro in piccole parti si può! I “veci” diventano P.O. Storie e task Standup meetings Retrospettive? Mmm... NB: “vecio” = alpino più anziano ed esperto 24
- 25. Lepratiche“estreme” Io continuo ad esplorare TDD! BDD! XP? Mmm... Clienti sempre presenti? No. Pair programming? Ma dighet del bù?! (tradotto: “ma dici davvero?!”) 25
- 26. Bello,peròpota... Bella ‘sta storia del lavoro suddiviso in piccoli step Però con Subversion non riesco a metterlo in pratica: se capita un bug devo fare copie di cartelle e revertare per poterlo risolvere (o tutt’al più fare delle patch...) I branch? Non li so usare, sono una capra! 26
- 27. SaràmicaquestoessereAgile? Agile cosa se poi non posso passare facilmente da un lavoro ad un altro?! Non riesco a fare prove ed esperimenti (e a salvare o a lasciare a metà un lavoro per poi riprenderlo) Sto Subversion ha rotto... 27
- 28. HosentitoparlarbenediGit... “Git è meraviglioso!” “Risolve tutti i problemi!” “Le donne lo adorano!” 28
- 29. Bello‘stoGit,machecasino... 200 comandi e decine di opzioni File che spariscono al cambio branch Come faccio il diff tra 2 branch? Non ci capisco una mazza! 29
- 30. NonècomeSubversion,accidenti... Ogni volta che modifichi un file devi fare git add, ma perché?! Perché mi obbliga a scrivere il messaggio di commit? Reset --hard e --soft… Cosa sono, comandi NSFW? E poi c’è amend, e checkout -- 30
- 31. Hopauraaaaaaaaaaaaaaaaaaa!!1! Dai, forza e coraggio, impegnati un pochino… Si ma se sbaglio? Ok, o la va o la spacca: migro tutti i repository al lavoro 31
- 32. NonècomeSubversion,perfortuna! Finalmente i branch, che figata! Nuova funzionalità? Feature branch! Bug? No problem, branch dal master! Voi fare una prova? Branch usa-e- getta per spike/esperimenti Era poi così difficile?! 32
- 33. C’hounflowchemancoEraclito... Ed ora un buon workflow Feature branches (Github flow) Git flow (bello, bello in maniera assurda!) “Se committi su master ti taglio il dito mignolo, una falange alla volta…” (cit.) 33
- 34. Nelpiccoloperòpossoancoramigliorare... Sì, ma… I miei commit sono ancora un po’ troppo cicciotti ed infrequenti… Si può fare di meglio, o no? 34
- 35. Quellastoriadelpomodoro…Provaci! Lavora time-boxed! (sì ma io odio quei dannati ticchettii...) Un A.T., un pomodoro (o 2, o 3) L’importante è provare a fare fettine sottili... 35
- 36. Ziobobtivede! One change, one commit S.R.P. vale anche per i commit! git add -p is your friend, just in case... 36
- 37. Commit-messagedrivendevelopment Scrivi il messaggio di commit prima di iniziare a scrivere codice, ti sfido! (grazie Arialdo Martini!) 37
- 38. Cosìlasmettidiscriverestr… E scrivi messaggi significativi! La lunghezza dei messaggi è inversamente proporzionale alla dimensione dei commit (Più c’è roba -> meno sai cosa scrivere -> meno scrivi) 38
- 39. Unesempio 39
- 40. Bravobambino,faiicompiti! Appuntati tutti i test che dovranno passare su un foglio Falli uno ad uno, integrando la lista man mano che ne scopri di nuovi (ma non devi implementarli per forza subito, anzi!) Commit early, commit often 40
- 41. C’ècommitecommit... Separa commit di “valore” da commit di “clean-up” Riassumendo, a good commit is: - Frequent - Small - Decoupled - Meaningful Ma soprattutto, non committare codice che non compila, maledetto! 41
- 42. Commitcompulsivo-ossessivo Un commit per ogni step del TDD, ti sfido! (poi puoi/devi fare uno squash e crearne uno di maggior significato prima di pushare) 42
- 43. Eureka!Ognicommitèunamicroiterazione! Tratta ogni commit come fosse una sorta di micro-sprint! Set the focus: verifica l’obiettivo, elenca i test, scrivi il messaggio di commit Act: lavora! :) Reflect, adjust, restart: rifletti su quanto fatto e pianifica il prossimo commit/pomodoro 43
- 44. Primadiiniziarecolprossimo,svuotalamente... “Svuota la mente” ad ogni commit Scrivi! Anche la nostra RAM è limitata… "Almost everything will work again if you unplug it for a few minutes, including you." Anne Lamott 44
- 46. Inconclusione… Git magari c’entra poco con tutto questo, ma ha avuto e sta avendo ancora per me dei side-effects estremamenti interessanti (ok, magari non proprio interessanti come quelli del sildenafil citrato...) 46
- 47. GitSideeffects: sharing Code Effort Knowledge → Collective Code Ownership → Feedback and “codeback” 47
- 48. GitSideeffects: Freedom Free to fail: you can do whatever you want in your branch, then throw it away Free to work everywhere Free to host your code wherever you want 48
- 49. Collaborating ANDCooperating Puoi lavorare al sicuro nel tuo recinto, ma in caso di necessità puoi condividere il tuo codice col mondo in pochi secondi Pull requests e Code reviews Team building 49
- 50. Collaborazione:insiemeperprodurrequalcosa Lavorare insieme con qualcuno Ma non necessariamente per lo stesso fine E nemmeno con lo stesso coinvolgimento “Io il mio lavoro l’ho fatto, arrivederci e tanti saluti” 50
- 51. Cooperazione:insiemeperlostessofine In etologia, termine utilizzato quando organismi della stessa specie condividono i benefici di un’azione svolta insieme. E’ finalizzata al conseguimento di un obiettivo comune. Esige che ciascuno dei ruoli selezioni solo ciò che è funzionale al raggiungimento di uno scopo condiviso. 51
- 52. Eusocialità L'eusocialità (dal greco eu, "buono", e "socialità") è il livello più alto di organizzazione sociale, che si realizza per alcune specie animali. Caratteristica di alcuni insetti, quali formiche, termiti e api; in essa la cooperazione, l’altruismo e la divisione del lavoro tra i membri della colonia si esprimono ai massimi livelli. L’uomo è eusociale? 52
- 53. Cosahocapito Un buon programmatore si vede (anche) da come tratta il proprio codice sorgente 53
Notas del editor
- Chiedi! Chi usa Git? Chi altro?
- Ecco come apparivo qualche anno fa “Come potete notare stavo leggendo specifiche, in perfetto stile waterfall” La mattina insegnante tecnico pratico di Informatica, e qualcosa di più Il pomeriggio avevo spazio, computer e tempo a disposizione per imparare a creare il sito della scuola Lavoravo da solo bellissimo periodo, un sacco di cose nuove da imparare autodidatta, pro e contro Versioning? Boh, manco sapevo cos’era Comunque avevo un processo di backup schedulato per copiare tutto ogni ora prima di modificare dei file mi copiavo la cartella per poter tornare eventualmente indietro
- Problemi 0: era tutto sotto il mio controllo ero il “webmaster”, ai tempi andava di moda chiamarli così... Nessun necessità di collaborazione, scambio files, etc e quindi nessun conflitto gli unici conflitti erano con me stesso, quando mi dimenticavo di fare backup dei file prima di modificarli...
- l’arrivo di altre persone nel “team” io mi occupavo del sito della scuola in ASP Claudio di cose in Flash Stefano di contenuti e grafica Tutti felici, tutti d’accordo
- Fatto di tutto: corsi FSE, patente AICA Dopo 7 anni di insegnamento, decido di cambiare e di dedicarmi al lavoro di programmatore
- azienda di software strutturata all’inizio avevano pensato di far lavorare anche me in COBOL! fortunatamente però nel CV avevo scritto anche .NET, e quindi mi hanno spostato su quel fronte
- prendersi gioco dei cobolisti è sempre divertente in effetti c’hanno lavorato anche loro sul Millennium Bug, nel GesFar a caratteri; niente di catastrofico, ma l’anno a 2 cifre ce l’avevano anche loro... la prima volta con Donant ed il COBOL oddio, cos’è sta roba?!
- COBOL: idea brillante, applicazione troppo ambiziosa! parte da un presupposto sbagliato: far capire ai manager la lingua dei programmatori Applicata male forse, ma l’idea era buona: BDD fa la stessa cosa! “COmmon Business-Oriented Language”, non è forse un BDD ante litteram?
- Grace Hopper Una dei fondatori dell’informatica moderna, e sicuramente una delle donne più influenti insieme a (cerca nome delle altre 2)
- cartella condivisa coi file sorgente “Chi sta toccando il barp0030?” “Chi è nelle tabelle?” “vecio”: alpino anziano e di grado superiore
- Studiofarma ha due sedi, una a BG ed una a BS a BS usavano Subversion proviamo un po’ ‘sto Subversion Mi son fatto il mio serverino a BG
- Finché fai le solite 4 cose tutto ok Bello poter navigare la storia, taggare le release, fare i diff
- Era solo una sorta di backup remoto, una discarica dove buttare il proprio codice Commit una volta la giorno, o anche 2-3...
- Collaborazione con il team di BS su un paio di progetti Alla fine era solo un posto comune dove prendere e mettere codice Molta poca collaborazione, anche qui ognuno lavorava alle sue cose
- si cooperava poco anche perché gli udpate, infrequenti, potevano generare dei bei casini anche senza fare branch, l’update del codice da /trunk può essere un affare complicato qualcun altro ha fatto un grosso refactor, tu fai l’update (obbligatorio) prima del commit e salta fuori un puttananio… http://blog.tfnico.com/2010/10/geek-and-poke-versus-subversion.html
- Operazione di commit e di push non separabili in Subversion
- A volte l’update è un casino perché il software che hai scritto è un casino Né Subversion, né Git, né nessun altro strumento risolve problemi di errate scelte di design architetturale della propria applicazione... Spaghetti code Per risolvere i bug mi copiavo la cartella del repository attuale da una parte, facevo revert, e lavoravo al bug
- I problemi del server centralizzato capitato poche volte a dire il vero, però è capitato
- difficoltà ad andare oltre le solite quattro operazioni mia inesperienza: io ero e sono ancora una capra… Altro dovuto al fatto che creandoti diverse cartelle per diversi branch ti sminchia percorsi ed altro
- Non finirò mai di ringraziare i colleghi che mi hanno aperto gli occhi Primo Agile Day, 2009 Un nuovo modo di approcciare lo sviluppo Vedere, misurare, migliorare Se ne parla, ma i colleghi cobolisti nicchiano
- una retrospettiva qualche (buon) consiglio e poi la stasi
- I colleghi cobolisti più vecchi sono diventati P.O. A fatica, ma si abbozzano delle storie La suddivisione di storie in task
- Nel frattempo io andavo avanti ad esplorare pratiche e metodi Ho cominciato a fare TDD, o almeno credevo… Test messi a posteriori, codice intestabile, soliti casini… Ma almeno avevo iniziato
- Tutti ne parlano, proviamolo! Ah, però, non è proprio immediato… Qualche prova lì, qualche prova là, ma finché non inizio ad usarlo per davvero al lavoro non lo capitò mai!
- fare i branch è molto semplice, è tutto il resto che è un casino... un sacco di comandi da imparare grafo aciclico?! decine di subcommands
- yeee!!! insomma, all’inizio la cosa che più mi piaceva erano i branch ero innamorato, e lo sono ancora! dei branch
- All’inzio andavo matto per i branch! GitFlow: sembra facile, ma non è difficile… :) Per una applicazione desktop come la mia, con numeri di release, beta version etc, è l’ideale Potrebbe andar bene anche per sviluppo mobile Forse un po’ overhead per applicazioni Web, ma branch “develop” può essere utile per test in ambaiente di staging Linux flow: lieutenant, blessed repository Git mantainer is Junio Hamano
- forse posso fare di meglio… mi sono accorto subito che commit piccolo è meglio: quando devi mergiare dei branch è più semplice collaborazione con colleghi ancora scarsa, ma ai primi approcci ti accorgi subito che piccolo è meglio...
- ho quindi cominciato a darmi delle regole! timeboxed ok, ma non sono ancora così bravo… Per ora i miei slot sono “a cipponi”, cerco comunque di stare nei 30-40 minuti da qui in poi elenco sfide attualmente in corso, non è che sono già così bravo...
- altre regole no, quel typo che hai visto non c’entra nulla con quello che stai facendo, non correggerlo!
- questa è la cosa più facile da applicare all’inizio! Ti permette di definire i limiti del tuo prossimo slot di coding con una certa precisione prenditi il tempo per farlo, verrà ripagato abbondantemente! Grazie Arialdo Martini
- nel
- Un buon messaggio di commit: 50 lettere per la prima riga poi le altre righe di descrizione (max 72 char per riga) eventuali bullet point su funzionalità, modifiche, aggiunte Non dire quello che hai fatto, quello si capisce dal codice! Descrivi il problema che hai risolto, la funzionalità che hai implementato, il cambiamento che hai apportato Aggiungi informazioni accessorie utili, tipo n° di ticket se usi un sistema di ticketing Usa verbi al presente; il soggetto che parla non sei tu, ma il commit
- un altra tecnica che ho utilizzato per aiutarmi a creare commit piccoli e significati
- commit di cleanup NON aggiungono valore al software ad es.: pura formattazione di documenti, indentazione, etc rimozione di commenti rimozione di dead code, file inutilizzati o comittati per errore
- qui è quasi da manicomio, ma può aiutarti a: esercitare la capacità di spezzare in piccoli commit mantenere il focus
- A pensarci bene.. Ogni commit è un micro sprint! Tratta ogni commit come un micro-sprint! Set the point: prenditi 1 minuto per verificare l’obiettivo e scrivere il messaggio di commit Imposta in maniera chiara l’obiettivo del tuo commit Appuntati i test che dovranno passare, o l’obiettivo che ti poni di raggiungere Act: lavoraci Next: ed alla fine prenditi 5 minuti per pensare, mini retrospettiva, prendi appunti e prepararti al prossimo commit/pomodoro Meglio obiettivi piccoli che non occupano tutto il pomodoro che obiettivi che ti fanno sforare! Soprattutto all’inizio
- Riflettete bene sull’ultimo punto della precedente slide: rifletti su quanto fatto e pianifica il prossimo commit/pomodoro Non dire “Ok, al prossimo pomodoro mi devo ricordare di fare quella cosa”, ma “svuota la mente” ad ogni commit La mente va lasciata libera per pensare, anche la nostra RAM è limitata… Scrivi i prossimi test che dovranno passare, quel che dovrai/vorrai fare nel prossimo slot di tempo
- in una parola… Serve DISCIPLINA!!
- Condividere lavoro usando branch remote Lavorare in parallelo a cose diverse Diffondere la conoscenza, favorire la collaborazione usando pull requests Confronto di idee, tecniche, punti di vista, modi di fare “codeback”: feedback su quanto fatto espresso tramite codice “di riasposta”
- Condividere lavoro usando branch remote Lavorare in parallelo a cose diverse Diffondere la conoscenza, favorire la collaborazione usando pull requests Confronto di idee, tecniche, punti di vista, modi di fare “codeback”: feedback su quanto fatto espresso tramite codice “di riasposta”
- Condividere lavoro usando branch remote Lavorare in parallelo a cose diverse Diffondere la conoscenza, favorire la collaborazione usando pull requests Confronto di idee, tecniche, punti di vista, modi di fare
- Condividere lavoro usando branch remote Lavorare in parallelo a cose diverse Diffondere la conoscenza, favorire la collaborazione usando pull requests Confronto di idee, tecniche, punti di vista, modi di fare
- qualcuno di voi ha mai lavorato in cantiere? O meglio, ha mai lavorato per davvero? :) ad es. in un cantiere con muratori, elettricisti, piastrellisti… E’ vero che alla fine si lavora tutti insieme per realizzare la costruzione ma ognuno con le sue libertà di azione ognuno con le sue priorità, modi di fare Mors tua, vita mea… “Io il mio lavoro l’ho fatto, mo so cazzi tua” un qualche accordo su obiettivi e valori comuni, il mettere insieme competenze individuali a vantaggio del gruppo.
- Interdipendenza positiva, Responsabilità individuale, Interazione faccia a faccia, La co-decisione: richiede di saper gestire la sincronizzazione delle azioni Il coordinamento: si esprime nell’integrazione dei contributi espressi. La collaborazione: trova la sua criticità nella progressiva convergenza delle opinioni, delle scelte e dei valori dei partecipanti. Ritrovarsi insieme è un inizio, restare insieme è un progresso, ma riuscire a lavorare insieme è un successo. (Henry Ford) La cooperazione si basa sulla profonda convinzione che nessuno riesca ad arrivare alla meta se non ci arrivano tutti (Virginia Burden)
- xxx