Si parla dei principi del continuous integration secondo Martin Fowler. Si parte da un problema comune, che è quello di lavorare in tanti sugli stessi sorgenti e si vedono i principi che possono permetterci di lavorare nel modo più sereno possibile.
Presentazione "quickie" sull'integrazione fra Maven ed Eclipse offerta dal plugin m2eclipse di Sonatype tenuta al JUG Milano Meeting #29 del 3 luglio 2008: http://www.jugmilano.it/vqwiki/jsp/Wiki?Meeting3Luglio2008&highlight=m2eclipse
Parleremo di come configurare e utilizzare Docker in un progetto Laravel per uno sviluppatore che si inserisce in un nuovo Team per la prima volta. Prendedermo come esempio alcuni progetti già pre-costituiti come Laravel Homestead e Laradock fino ad arrivare ad a costruire un ambiente docker più strutturato con Laravel, Redis, Memcached, Laravel Echo Server per avere un ambiente facilmente deployable sul cloud.
Dall'idea al deploy un lungo viaggio che passa per git flow e semverMauro Servienti
Parliamo tanto di DevOps e ci concentriamo sui tool senza soffermarci a pensare che DevOps è principalmente una metodologia. Lo scopo è rendere l'intera filiera il più fluida e lineare possibile, rimuovendo impedimenti e cercando di prevenire e anticipare problemi.
Possiamo costruire tutto il processo di sviluppo, partendo dai vagiti iniziali del backlog per finire che il deploy fisico in ottica DevOps? Il processo ha impatto sulle scelte tecniche? Pratiche come SemVer e GitFlow hanno invece un impatto sul backlog?
Analizzeremo l'intero processo di sviluppo di Particular Software, dalla gestione del backlog al deploy automatico in produzione, con lo scopo di evidenziare come pratiche che sembrano disconnesse abbiano invece impatto su tutta la filiera.
Crash course on the zope.buildout (italian language). Talk done at Pycon4 (2010).
The code: http://dl.dropbox.com/u/2369909/05_a_project_code_script.tgz
Presentazione "quickie" sull'integrazione fra Maven ed Eclipse offerta dal plugin m2eclipse di Sonatype tenuta al JUG Milano Meeting #29 del 3 luglio 2008: http://www.jugmilano.it/vqwiki/jsp/Wiki?Meeting3Luglio2008&highlight=m2eclipse
Parleremo di come configurare e utilizzare Docker in un progetto Laravel per uno sviluppatore che si inserisce in un nuovo Team per la prima volta. Prendedermo come esempio alcuni progetti già pre-costituiti come Laravel Homestead e Laradock fino ad arrivare ad a costruire un ambiente docker più strutturato con Laravel, Redis, Memcached, Laravel Echo Server per avere un ambiente facilmente deployable sul cloud.
Dall'idea al deploy un lungo viaggio che passa per git flow e semverMauro Servienti
Parliamo tanto di DevOps e ci concentriamo sui tool senza soffermarci a pensare che DevOps è principalmente una metodologia. Lo scopo è rendere l'intera filiera il più fluida e lineare possibile, rimuovendo impedimenti e cercando di prevenire e anticipare problemi.
Possiamo costruire tutto il processo di sviluppo, partendo dai vagiti iniziali del backlog per finire che il deploy fisico in ottica DevOps? Il processo ha impatto sulle scelte tecniche? Pratiche come SemVer e GitFlow hanno invece un impatto sul backlog?
Analizzeremo l'intero processo di sviluppo di Particular Software, dalla gestione del backlog al deploy automatico in produzione, con lo scopo di evidenziare come pratiche che sembrano disconnesse abbiano invece impatto su tutta la filiera.
Crash course on the zope.buildout (italian language). Talk done at Pycon4 (2010).
The code: http://dl.dropbox.com/u/2369909/05_a_project_code_script.tgz
Paolo Finardi e Fabio Fusili presentano il progetto "Linux va a scuola" del Bergamo Linux Users Group durante il Linux Day 2016.
Il progetto ha lo scopo di supportare le scuole che vogliono migrare i laboratori informatici dal software proprietario al software libero diventando parte attiva nella diffusione della cultura della condivisione.
Nella presentazione sono descritti gli obiettivi, i motivi per cui questa scelta è importante e l'evoluzione che il progetto sta avendo. Sono state, inoltre, elencate le funzionalità pratiche che contraddistinguono la soluzione che implementiamo nei laboratori delle scuole.
Installazione Qt/Qt Quick per target AndroidPaolo Sereno
Questo breve tutorial rappresenta una mini guida per iniziare a programmare con Qt e Qt Quick su target Android. In particolare esso vuole essere un “memo” da usare durante i meetup e workshop sull’argomento organizzati dalla web community Qt-Italia.org.
Questo talk presenterà l'architettura di QPA (ex Lighthouse Project) e come questo consente agli sviluppatori di portare facilmente Qt su sistemi diversi.
Appunti delle lezioni di Jànos Korner. Autori: Marco Valerio Barbera, Alessandro Cammarano,
Andrea Cerone, Andrea Moro, Arbri Shqepa,
Dora Spenza e Bruno Vavala
Si parla di IcedTea, della macchina virtuale Java completamente libera e degli altri strumenti. Vengono spiegate le differenze tra l’approccio con interprete, compilatore e macchina virtuale. Si racconta di quali macchine virtuali ci sono per quali linguaggi. Vengono descritte le peculiarità di IcedTea e si prendono in esame le differenze tra HotSpot Zero Assembly con la macchina virtuale di Oracle, HotSpot. Si parla di quali linguaggi possano essere compilati per macchina virtuale Java.
Come la comunicazione tra moduli è evoluta per portarci a quello che oggi è la Service Oriented Architecture. Quali approcci hanno funzionato e quali no. Un esempio di architettura SOA. Come si implementano i web services di tipo REST con Jersey.
This document discusses Jenkins-CI, an open source tool for continuous integration and continuous delivery. It provides an overview of Jenkins-CI capabilities including building and testing software projects continuously, integrating changes, and continuously delivering software. The document also demonstrates Jenkins-CI in action with a live demo and discusses configuring Jenkins jobs, managing Jenkins, and requirements for deployment beyond Jenkins-CI like standardization, workflow, monitoring, and high availability.
The document discusses how Jenkins helps improve the software development process at Yale. It outlines challenges without Jenkins, such as slow and error-prone builds, difficult testing and code coverage, and lack of change control for deployments. With Jenkins, builds are automated and consistent, testing and code coverage are automated, changes are tracked, and deployments are easier. Jenkins supports continuous integration, containerized artifacts, and managed deployments to improve agility, catch bugs early, and standardize environments. The document also discusses how Jenkins supports non-Java languages and future plans.
Continuous Delivery with Jenkins and Wildfly (2014)Tracy Kennedy
A presentation on a continuous delivery pipeline that leverages Jenkins Enterprise, Jenkins Operations Center, Nexus, HAProxy, and Wildfly. Pipeline components run in Docker containers along with SkyDock/SkyDNS for service discovery and NSEnter for command-line access to containers.
Continuous integration involves developers committing code changes daily which are then automatically built and tested. Continuous delivery takes this further by automatically deploying code changes that pass testing to production environments. The document outlines how Jenkins can be used to implement continuous integration and continuous delivery through automating builds, testing, and deployments to keep the process fast, repeatable and ensure quality.
This document summarizes a Jenkins pipeline for testing and deploying Chef cookbooks. The pipeline is configured to automatically scan a GitHub organization for any repositories containing a Jenkinsfile. It will then create and manage multibranch pipeline jobs for each repository and branch. The pipelines leverage a shared Jenkins global library which contains pipeline logic to test and deploy the Chef cookbooks. This allows for standardized and reusable pipeline logic across all Chef cookbook repositories.
Ottava puntata del MuleSoft Meetup di Milano. Parliamo insieme a Paolo Petronzi di metodologie di testing e automazione con MUnit e poi con Luca Bonaldo, il nostro Mulesoft Mentor in Italia, dell'integrazione con Salesforce.
https://meetups.mulesoft.com/events/details/mulesoft-milano-presents-mulesoft-milano-meetup-8/
Paolo Finardi e Fabio Fusili presentano il progetto "Linux va a scuola" del Bergamo Linux Users Group durante il Linux Day 2016.
Il progetto ha lo scopo di supportare le scuole che vogliono migrare i laboratori informatici dal software proprietario al software libero diventando parte attiva nella diffusione della cultura della condivisione.
Nella presentazione sono descritti gli obiettivi, i motivi per cui questa scelta è importante e l'evoluzione che il progetto sta avendo. Sono state, inoltre, elencate le funzionalità pratiche che contraddistinguono la soluzione che implementiamo nei laboratori delle scuole.
Installazione Qt/Qt Quick per target AndroidPaolo Sereno
Questo breve tutorial rappresenta una mini guida per iniziare a programmare con Qt e Qt Quick su target Android. In particolare esso vuole essere un “memo” da usare durante i meetup e workshop sull’argomento organizzati dalla web community Qt-Italia.org.
Questo talk presenterà l'architettura di QPA (ex Lighthouse Project) e come questo consente agli sviluppatori di portare facilmente Qt su sistemi diversi.
Appunti delle lezioni di Jànos Korner. Autori: Marco Valerio Barbera, Alessandro Cammarano,
Andrea Cerone, Andrea Moro, Arbri Shqepa,
Dora Spenza e Bruno Vavala
Si parla di IcedTea, della macchina virtuale Java completamente libera e degli altri strumenti. Vengono spiegate le differenze tra l’approccio con interprete, compilatore e macchina virtuale. Si racconta di quali macchine virtuali ci sono per quali linguaggi. Vengono descritte le peculiarità di IcedTea e si prendono in esame le differenze tra HotSpot Zero Assembly con la macchina virtuale di Oracle, HotSpot. Si parla di quali linguaggi possano essere compilati per macchina virtuale Java.
Come la comunicazione tra moduli è evoluta per portarci a quello che oggi è la Service Oriented Architecture. Quali approcci hanno funzionato e quali no. Un esempio di architettura SOA. Come si implementano i web services di tipo REST con Jersey.
This document discusses Jenkins-CI, an open source tool for continuous integration and continuous delivery. It provides an overview of Jenkins-CI capabilities including building and testing software projects continuously, integrating changes, and continuously delivering software. The document also demonstrates Jenkins-CI in action with a live demo and discusses configuring Jenkins jobs, managing Jenkins, and requirements for deployment beyond Jenkins-CI like standardization, workflow, monitoring, and high availability.
The document discusses how Jenkins helps improve the software development process at Yale. It outlines challenges without Jenkins, such as slow and error-prone builds, difficult testing and code coverage, and lack of change control for deployments. With Jenkins, builds are automated and consistent, testing and code coverage are automated, changes are tracked, and deployments are easier. Jenkins supports continuous integration, containerized artifacts, and managed deployments to improve agility, catch bugs early, and standardize environments. The document also discusses how Jenkins supports non-Java languages and future plans.
Continuous Delivery with Jenkins and Wildfly (2014)Tracy Kennedy
A presentation on a continuous delivery pipeline that leverages Jenkins Enterprise, Jenkins Operations Center, Nexus, HAProxy, and Wildfly. Pipeline components run in Docker containers along with SkyDock/SkyDNS for service discovery and NSEnter for command-line access to containers.
Continuous integration involves developers committing code changes daily which are then automatically built and tested. Continuous delivery takes this further by automatically deploying code changes that pass testing to production environments. The document outlines how Jenkins can be used to implement continuous integration and continuous delivery through automating builds, testing, and deployments to keep the process fast, repeatable and ensure quality.
This document summarizes a Jenkins pipeline for testing and deploying Chef cookbooks. The pipeline is configured to automatically scan a GitHub organization for any repositories containing a Jenkinsfile. It will then create and manage multibranch pipeline jobs for each repository and branch. The pipelines leverage a shared Jenkins global library which contains pipeline logic to test and deploy the Chef cookbooks. This allows for standardized and reusable pipeline logic across all Chef cookbook repositories.
Ottava puntata del MuleSoft Meetup di Milano. Parliamo insieme a Paolo Petronzi di metodologie di testing e automazione con MUnit e poi con Luca Bonaldo, il nostro Mulesoft Mentor in Italia, dell'integrazione con Salesforce.
https://meetups.mulesoft.com/events/details/mulesoft-milano-presents-mulesoft-milano-meetup-8/
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?
La nuova versione di Magento è, rispetto alla precedente, ancor più orientata all’utilizzo di sistemi di automazione già da tempo affermati nell’industria informatica (continuous integration e continuous delivery).
Questo intervento si propone di esplorare alcuni di questi aspetti partendo dalla nuova gestione dei comandi shell proposta dal framework. Con Magento 2 e gli attuali sistemi cloud si può quasi delineare una nuova figura accanto al Backend Developer, il “Devops” developer. Ovvero chi, facendo leva sugli strumenti ora nativi, si occupa di tutti quei processi che “dietro le quinte” garantiscono l’affidabilità del sistema, la ripetibilità e l’automazione dei processi e, in definitiva, la qualità del prodotto.
Riccardo Tempesta - Strumenti di automazione in Magento 2Meet Magento Italy
La nuova versione di Magento è, rispetto alla precedente, ancor più orientata all’utilizzo di sistemi di automazione già da tempo affermati nell’industria informatica (continuous integration e continuous delivery).
Questo intervento si propone di esplorare alcuni di questi aspetti partendo dalla nuova gestione dei comandi shell proposta dal framework. Con Magento 2 e gli attuali sistemi cloud si può quasi delineare una nuova figura accanto al Backend Developer, il “Devops” developer. Ovvero chi, facendo leva sugli strumenti ora nativi, si occupa di tutti quei processi che “dietro le quinte” garantiscono l’affidabilità del sistema, la ripetibilità e l’automazione dei processi e, in definitiva, la qualità del prodotto.
Una user story non è completa finché non è nelle mani di chi la deve usare. Solo da lì inizia a produrre valore, sia esso economico o sia feedback. Che si tratti di master, preview o production, con l’automazione delle build si possono evitare operazioni ripetitive, complesse, risparmiare tempo, ottenere interessanti metriche sul codice, tutto al fine di arrivare a poter rilasciare ogni poche ore (o, se volete, ogni volta che la build è verde!). Farlo in modo frequente è possibile anche con Symfony2. Mettiamo in pratica con un esempio una delle 12 pratiche di Extreme Programming: continuous delivery e integration tra git, bash, Jenkins e strumenti deploy.
Slide del decimo Meetup di Milano, che si è tenuto il 26 Gennaio dalle ore 10:30 alle ore 12:00 in formato virtuale.
Abbiamo parlato insieme a Davide Bonaciti di come ha realizzato un caso d'uso di automazione e CI/CD. Stefano Bernardini, Serena Galassi e Lorenzo Ornella, invece, ci parleranno di DataGraph e ci mostreranno una demo di implementazione per realizzare un'asta del fantacalcio 2.0.
Selenium e testing web - di Alessio BenedettiGiuneco S.r.l
Selenium framework: Selenium è un framework open-source per l'automazione e il testing di applicazioni web che permette di controllare in remoto le istanze del browser ed emulare l'interazione di un utente.
Durante l'ottavo Meetup di Milano, tenutosi il 19 Maggio dalle ore 10:30, si è potuto approfondire con Paolo Petronzi tutte le metodologie di testing e automazione con MUnit, invce con Luca Bonaldo, il nostro Mulesoft Mentor in Italia, c'è stato un focus sull'integrazione con Salesforce.
2. Inferno dell'integrazione
●
Scarico il codice sorgente
●
Faccio le mie modifiche
●
Eseguo i test
●
Decido di fare commit
●
Peccato che qualcuno ha fatto
commit sulle stesse classi
●
Cerco di gestire tutti i conflitti
●
Non posso! Sono troppi! :-O
●
Ri-scarico il codice e
ricomincio da capo :-(
Fonte: computerfixperts.com
2 / 14
3. Come si fa ad evitarlo?
●
Mantieni un repository del codice sorgente
●
Automatizza il build
●
Rendi il build auto-testante
●
Tutti eseguono una commit alla baseline
tutti i giorni
●
Ogni commit fa partire una build
●
Fai in modo che la build sia veloce
●
●
●
●
Esegui i test in un clone dell'ambiente di
produzione
Prendere le ultime versioni dei pacchetti
deve essere facile
Ognuno può vedere quello che sta
succedendo
Automatizza il dispiegamento
Putin scopre l'integrazione continua
Fonte: www.gazprom.com
3 / 14
4. Mantieni un repository del codice
sorgente
●
●
●
●
Basta usare un software per
il controllo della versione
Scegliere tra lock or merge o
sistema distribuito
Stanno prendendo piede i
sistemi di controllo di
versione distribuito come Git
e Mercurial
Sono ancora molto usati
quelli a lock ottimistico come
Subversion e CVS
Fonte: git-scm.com
4 / 14
5. Automatizza il build
●
●
●
●
●
Per build intendiamo il processo che
porta dal codice sorgente all'artefatto
che può girare sul server o
direttamente sul computer client
Per buildare basterebbe solo Eclipse,
anche se la configurazione in questo
caso sarebbe molto complicata da
gestire
Opzione più diffusa è Maven, che
permette anche di gestire le
dipendenze da librerie open source
Progetti legacy: Ant
Altre opzioni possibili sono Gradle,
Ivy e Buildr
Fonte: www.hdrinc.com
5 / 14
6. Rendi il build auto-testante
●
●
●
●
Abbiamo sia i test unitari che i
test di integrazione
Solitamente i test unitari sono
parecchio più veloci dei test di
integrazione
Se si è deciso di usare Maven
come sistema di build, basterà
mettere i test unitari nella
sottocartella /src/test/java
Per i test di integrazione ci sono
varie librerie, tra cui Selenium,
SoapUI, Jmeter, Arquillian
6 / 14
7. Tutti committano sulla baseline tutti i
giorni
●
●
●
È importante per limitare
i conflitti e quindi l'inferno
dell'integrazione
Difficile convincere gli
sviluppatori a fare
commit tutti i giorni
Ancora più difficile
convincerli a testare il
codice prima di
committarlo
Fonte: quentinwatson.co.uk
7 / 14
8. Ogni commit fa partire una build
●
●
●
●
Far partire unicamente i test
unitari, postporre i test di
integrazione a quando è possibile,
comunque almeno una volta al
giorno
Ogni singolo commit potrebbe
creare errori o fare fallire i test
È importante che un eventuale
commit che porta nuovi bug venga
individuato immediatamente e vi
sia posto rimedio
Questo principio si basa sul
principio “fail fast”
Fonte: benandcatherine.org
8 / 14
9. Fai in modo che la build sia veloce
●
●
●
●
●
●
Se ogni commit fa partire una
build, la build deve essere la più
veloce possibile
Suddividere build in due fasi
Prima fase: compilazione e test
unitari
Seconda fase: test di
integrazione
La seconda fase gira quando
possibile
Usare basi dati in memoria come
HSQLDB
Fonte: missingbite.com
9 / 14
10. Esegui i test in un clone
dell'ambiente di produzione
●
Anche la più piccola delle
differenze tra l'ambiente di test
e quello di produzione può
rendere estremamente difficile
riprodurre un bug
●
Stesso sistema operativo
●
Stessa base dati
●
Stessa JVM
●
●
Stesso application / web
server
Stessi browser
Fonte: softicons.com
10 / 14
11. Prendere le ultime versioni dei
pacchetti deve essere facile
●
●
●
Per le persone è più facile vedere
ed eseguire le versioni
intermedie del software e dire
che cosa è che non va
Fai in modo che ci sia un posto in
cui tutte le persone possano
prendere l'eseguibile e testarlo
Sopratutto le persone che
devono far girare delle demo dei
prodotti per far vedere a
potenziali clienti il funzionamento
del software hanno bisogno di
sapere dove trovare i pacchetti
Fonte: bodecibody.blogspot.it
11 / 14
12. Ognuno deve poter vedere quello
che sta succedendo
●
●
●
●
Lo stato del progetto deve essere
visibile e trasparente a tutte le parti
coinvolte
Questo permette di stabilire
scadenze realistiche e allocare
tempo per la risoluzione dei
problemi attuali
Inoltre, problemi di usabilità
possono essere individuati più
velocemente se è possibile vedere
e testare facilmente l'applicativo
È possibile stabilire un rapporto di
fiducia con tutte le parti coinvolte
nel processo di sviluppo
Fonte: jimbrooks.org
12 / 14
13. Automatizza il dispiegamento
●
●
●
●
Per dispiegamento si intende il
trasferimento degli artefatti sull'ambiente
di destinazione e l'esecuzione di script di
allineamento
Per fare continous integration bisogna
avere diversi ambienti che devono
essere allineati più volte al giorno
Per fare questo è buona norma avere dei
meccanismi che permettano il rilascio dei
risultati delle build sui vari ambienti,
compreso quello di produzione
Dopo il build è possibile trasferire il
risultato del build in una cartella di un
ambiente e far girare degli script di
allineamento
Fonte: photo-dictionary.com
13 / 14
14. Jenkins
●
●
●
●
●
●
●
Web application che gira in un servlet
container
Permette di lanciare delle build e dei
dispiegamenti
Permette di vedere i risultati dei test
Non ha bisogno di basi dati per
funzionare: salva le configurazioni in file
XML
Si integra con gli strumenti di controllo
delle versioni e con gli strumenti di
automazione dei build
È in grado di scaricare autonomamente
Maven e Ant
Estensibile tramite plugin
14 / 14