Gianni Bombelli
Gung-ho Software Craftsman, Experienced Learner & Technical Coach @ freelance
Gung-ho Software Craftsman, Experienced Learner & Technical Coach @ freelance
Milan, Italy
Actions
Hi guys, It's Gianni here and I have a lot of interests: photography, trekking, reading manga and fantasy novels, software craftsmanship, motorsport, beer, tabletop and role playing games.
Among many interests there is a special one, which allows me to "earn the money necessary to live" and that is for IT and software development!
Software Craftsmanship for me, is continuous learning, sharing my experience with others and above all dedicating time with enthusiasm and passion to one of my interests.
Ciao ragazzi, sono Gianni e ho un sacco di interessi: fotografia, trekking, leggere manga e romanzi fantasy, software craftsmanship, motorsport, birra, giochi da tavolo e di ruolo.
Fra tanti interessi ne esiste uno speciale, che mi permette di "guadagnare i soldi necessari per vivere" ed è quello per l'informatica e lo sviluppo software!
Software Craftsmanship per me è apprendimento continuo, condividere la mia esperienza con gli altri e soprattutto dedicare del tempo con entusiasmo e passione a uno dei miei interessi.
Area of Expertise
Topics
Refactor all'ultimo commit! en
Questa è una sfida all'ultimo commit!
Parafrasando un celebre motociclista e giornalista italiano: "Refactor in testa ben chiaro, test in esecuzione anche di giorno, e barra verde, sempre!"
Prendiamo un kata ben noto e implementato nella sua forma più banale, applichiamo mosse di refactor fino a dargli una forma finale prestabilita. In questa sfida non conta la destinazione, ma la via percorsa per raggiungerla!
Il software deve essere sempre funzionante e il punteggio dipende dalla qualità e semplicità dei commit eseguiti.
Vuoi saperne di più? Vieni anche tu al Agile O'Day 2023 :-)
The DevOps Ways en it
Ten years ago I had a build pipeline, and a centralized log collector, and thought I was DevOps.
In truth, I was very far away.
Today I know that DevOps is a buzzword, a fashion, and it is often abused.
DevOps is a culture, a behavior, a methodology that leads to change in the way we work. When we talk about DevOps we focus on the techniques... CI/CD pipeline, IaC, everything as a service, automation, centralized logging, and so on. But before delving into the practices it is necessary to understand the soul of the DevOps movement.
The cliché that to be DevOps it is necessary to practice certain techniques should be destroyed by shifting the attention to the essential thing: to be DevOps it is necessary to think in a different way.
Turnkey Continuous Delivery it
Con l'aiuto di Ansible, Vagrant, Docker, Gitlab e Jenkins metteremo in piedi una soluzione completamente funzionante con cui iniziare il nostro viaggio sulla via del Continuous.
Lungo la nostra via incontreremo alcuni concetti tipici della cultura DevOps e ci renderemo conto che sono proprio questi la chiave per il successo più che gli strumenti utilizzati. Fra questi ricordiamo "Infrastructure as code", "Immutable server", "Automated provisioning", "Infrastructure (automated) testing" .
Quando si parla di Continuous Integration e Delivery, l'idea comune è che gli strumenti necessari per praticarla sono complessi e richiedono parecchio studio e tempo per creare l'infrastruttura di base... ma la sfida vera non è dominare gli strumenti, bensì cambiare noi stessi e il nostro modo di lavorare e di approcciare questo argomento.
La presentazione e tutto il materiale usato durante il workshop sarà disponibile su GitHub.
Test-Driven Infrastructure with Ansible it
Spesso si parla di "Pipeline as Code" e "Infrastructure as Code"...
ma cosa significa? come faccio? prendo i file che scrivo per fare il deploy e la configurazione della mia infrastruttura e li metto in un repository?
No dai... non può essere solo questo... deve esserci dietro qualcosa che mi sfugge! Uso un tool chiamato "Ansible" per fare i deploy, configurare l'infrastruttura, scrivere dei template (usando jinja2), definire un inventario di varibili (con formato yaml) e scrivere dei "playbook" dichiarativi con un DSL.
Ecco cosa mi sfuggiva... sto scrivendo software usando un DSL!
Ora so cosa fare :-)
Usare un branching model, scrivere test (unit, integration, acceptance test, etc.), magari fare TDD, usare un linter, fare analisi statica del codice.
Infine possiamo fare una pipeline di build e delivery esattamente come se fosse del normale codice da mettere in produzione!
The DevOps Ways en it
Dieci anni fa avevo una pipeline di build, un log collector centralizzato e pensavo di essere DevOps.
In verità ero molto lontano!
Oggi so che DevOps è una buzzword, una moda e il termine è spesso abusato.
DevOps è una cultura, un comportamento, una metodologia che porta a cambiare il modo in cui lavoriamo. Quando parliamo di DevOps ci concentriamo sulle tecniche... pipeline di CI/CD, IaC, qualsiasi cosa come servizio, automazione, log centralizzati e così via. Ma prima di approfondire le pratiche è necessario comprendere lo spirito, l'anima del movimento DevOps.
Il cliché secondo cui per essere DevOps è necessario praticare alcune tecniche dovrebbe essere "distrutto" spostando l'attenzione sulla cosa essenziale: per essere DevOps è necessario pensare (e agire) in un modo differente!
d4r^7 it
Ambiente di Continuous Delivery che gira in container docker, produce container docker sfruttando altri container docker, testa container docker usando altri container docker e rilascia container docker in container docker.
Questo è un racconto di come abbiamo imparato a usare i container e sfruttato le loro caratteristiche per creare le nostre build pipeline e l’infrastruttura stessa di build e test. Sarà un viaggio tra le sfide affrontate e illustrando le pratiche, buone e cattive, che abbiamo adottato. Da (le ceneri di) un build server confusionario, poco flessibile e con capacità limitate abbiamo realizzato un sistema ordinato, flessibile e scalabile… tutto questo sfruttando docker fino all’eccesso (e oltre)!
Il sentiero che stiamo percorrendo è lungo e a tratti impervio e, anche se siamo arrivati al deploy in produzione, abbiamo ancora parecchia strada da percorrere. Gli sforzi fatti ci hanno ripagato con grandi soddisfazioni e vale la pena condividere questa esperienza!
Molto spesso mi accorgo che i problemi e le sfide che affrontiamo sono comuni e condivisi da molti team e aziende. Vorrei semplicemente condividere la nostra esperienza e come abbiamo affrontato queste sfide, nella speranza che possa essere uno spunto di riflessione per i partecipanti e di aiuto con qualche buona idea.
and if we put the legacy monolith inside docker? en
Often we talk about how to take a monolith and divide it into micro-services or mini-services, but why not put it inside a container as is?
We did it and it was a longer and more challenging job than expected, but we have come to the end.
The satisfaction is so great... some long-standing problems are solved or reduced.
Challenges have also been difficult with some new problems to be addressed and solved.
Siamo tutti DevOps... ma sappiamo cosa stiamo facendo? it
Tutti i giorni vedo team interi di DevOps e team di Developers che sono diventati team di Devops! Che bello! Nel mio fantastico mondo sono tutti DevOps o giocatori di Dungeons and Dragons (solo i migliori sono entrambe le cose).
Però mi sorge un dubbio: ma sappiamo cosa stiamo facendo?
Facciamo un passo indietro… torniamo alle origini per capire a pieno il senso del termine DevOps e andare oltre la moda del momento! Sappiate che la mia posizione nei confronti delle mode è molto semplice... ignorarle con stile.
Facciamo anche un passo in avanti... ma quale? Andiamo a vendere ghiaccioli al polo sud!?
Total Testing in DevOps it
Si parla tanto di DevOps e alle conferenze gli argomenti più gettonati sono build pipeline, continuous integration/delivery/deploy, deploy automation e monitoring.
Ci stiamo dimenticando qualcosa... i test! dove sono i test? perché non si parla quasi mai di test? in questo fantastico mondo DevOps come si inseriscono i test?
I test sono solo un passo della pipeline di build? se la pensassi così il titolo del mio intervento sarebbe stato "Continuous Testing in DevOps", non credete?
Faccio prima il refactor o i test? it
Questo paradosso è molto antico e viene citato da alcuni filosofi dell'antica Grecia, tra cui Aristotele e Plutarco. La sua formulazione più nota è attribuita ad Ambrogio Teodosio Macrobio, studioso Romano del IV secolo, e recita "Ovumne prius extiterit an gallina?".
Nel lavoro dello sviluppatore spesso abbiamo a che fare con "codice legacy" e ci troviamo di fronte proprio al paradosso dell'uovo e della gallina!
La prima regola del refactoring è avere dei test che ci proteggono da cambiamenti indesiderati di comportamento. Spesso il codice non è facilmente testabile e per riuscire a scrivere dei test unitari dobbiamo prima modificare parte del codice non coperto da test.
Come possiamo uscire da questo rischioso ciclo?
I "Characterization test", detti anche "Golden Master test", sono molto utilizzati a questo scopo, ma non sono test unitari. Essi possono essere la nostra "rete di sicurezza", ma non ci aiutano tantissimo nella comprensione del codice. In questo workshop vedremo altri modi per testare legacy code e fare contestualmente refactor in sicurezza, scrivendo test unitari e scendendo nei dettagli delle logiche del codice legacy.
Italian Agile Days 2023 Sessionize Event
Working Software 2023 Sessionize Event
Italian Agile Days 2022 Sessionize Event
DevOpsHeroes 2019 Sessionize Event
Agile Venture Firenze 2019 Sessionize Event
Working Software Sessionize Event
DevOpsHeroes 2018 Sessionize Event
Please note that Sessionize is not responsible for the accuracy or validity of the data provided by speakers. If you suspect this profile to be fake or spam, please let us know.
Jump to top