Newsgroup: it.lavoro.informatica
Titolo: Continuous Integration: chi era costui?

Ciao a tutti,
Sto dando uno sguardo ad un articolo di Fowler sul CI:
http://martinfowler.com/articles/continuousIntegration.html
Qualcuno di voi ha esperienza a riguardo?
Qualche dritta?
Qualche consiglio?
Ciao e grazie,
Giulio
-- 
OnAir:
http://www.giuliopetrucci.it
http://www.fujikomonamour.com

 Qualche consiglio?
Da noi si integrano, nelle vecchie build ancora supportate, solo le
fix senza possibilità di work-around. Gli enhancement si integrano
solo a pagamento.
Non sempre è possibile integrare, quando le modifiche si basano su
altre modifiche non integrate/integrabili in precedenza.
L'integrazione continua non ha senso per noi, anzi sarebbe forse
deleteria per le vendite del "nuovo"...
--
Luc

 Qualche consiglio?
Inizia dando uno sguardo a CCNet o CruiseControl (http://
cruisecontrol.sourceforge.net/
).
Aggiungerei anche TeamCity (
http://www.jetbrains.com/teamcity/
), non
ci ho mai lavorato ma ha una feature che vorrei tanto avere su CCNet
(
http://www.jetbrains.com/teamcity/delayed_commit.html
).
--
ale
http://ale.riolo.co.uk

> Qualche consiglio?
Aggiungo: la tecnologia MSBuild e' ok, ma da TFSBuild (almeno il
componente di TFS 2005, quello del 2008 ancora non l'ho visto) mi ci
terrei lontano.
--
ale
http://ale.riolo.co.uk

 
-- 
Andrea Francia
http://andreafrancia.blogspot.com/2008/06/relazioni-molti-molti-con-jpa.html

 (
http://www.jetbrains.com/teamcity/delayed_commit.html
).
Ho dato uno sguardo. Onestamente - probabilmente perché sono un po' 
"lento" a capire certe cose - non capisco a prima vista quali vantaggi 
possano derivare dall'uso di un sistema del genere. A occhio mi viene in 
mente questo: solo gli unit-test restano a carico dello sviluppatore. Ma 
per far girare gli unit-test occore comunque fare il building del 
progetto. A questo punto che senso ha "centralizzare" tutto? Non 
otterrei gli stessi vantaggi avendo:
- integrazione tra il sistema di issue tracking (ed eventuale scheduling 
dei task, si insomma... un tool molto spartano per il project 
management) e SVN (o comunque il sistema per il controllo di versione);
- sviluppatori che fanno la build in locale, fanno girare gli unit-test 
e gli integration-test (come pure quelli di performance e di carico);
- se tutti i test sono ok fanno il commit;
- la macchina di build che si occupa di fare il checkout della versione, 
eventualmente rifare la build + unit-test + integration-test + altri 
test e se tutto va come deve andare prepara la versione per lo shipping 
(ed eventualmente tagga il codice in SVN)
giusto?


Ciao Andrea
Andrea Francia ha scritto:
[cut]
Grazie per le dritte.
Dai uno sguardo alla mia risposta ad Alessandro Riolo (visto che ti 
avrei risposto più o meno con gli stessi argomenti). ;-)
Ciao e grazie,
Giulio
-- 


 giusto?
Se descrivevi un sistema a controllo aperto, e' una pazzia pura. Se
descrivevi CI fatto in casa senza un tool apposito, e' ok, ci sono
tanti team di sviluppo che fanno CI da ben prima che venisse inventato
il termine o iniziassero ad apparire i primi tool appositi.
--
ale
http://ale.riolo.co.uk

 Se descrivevi CI fatto in casa senza un tool apposito, e' ok
L'idea iniziale era questa. ;-)
Ciao,
Giulio
-- 
OnAir: Nuovi Orizzonti Artificiali - "0.36 (frequenza stabile)"
http://www.giuliopetrucci.it
http://www.fujikomonamour.com

 (ed eventualmente tagga il codice in SVN)
Giusto, ma qui hai descritto esattamente quello che la CI prescrive:
quindi dove sarebbe la differenza?
(Poi è ovvio che ogni committer dovrebbe eseguire i test anche in 
locale; ma questo non ti permette di fare a meno di uno strumento, 
necessariamente centralizzato, in grado di cioccare il committer 
negligente, tra le altre cose).
P.S.
Ti segnalo un altro paio di tool free per CI non Java né MS-based (ma 
comunque language-agnostic):
Buildbot:
http://buildbot.net
smolder:
http://sourceforge.net/projects/smolder
http://sourceforge.net/project/screenshots.php?group_id=161136
Ciao

 
http://sourceforge.net/project/screenshots.php?group_id=161136
Corro a dare uno sguardo!
Ciao e grazie,
Giulio
-- 
OnAir: Sergio Capecci - "Già Problema"
http://www.giuliopetrucci.it
http://www.fujikomonamour.com

 Ottimo, visto che il lavoro è 100% pure C!!!
Allora auguri! ;-)
(Comunque il C lo supportano tutti).
Rileggendomi, volevo precisare che, ancorché scritto in Java, anche 
CruiseControl segnalato da Riolo è language-agnostic.
E a dirla tutta ne esiste anche un port su Ruby:
http://cruisecontrolrb.thoughtworks.com/
Ciao!

 (Comunque il C lo supportano tutti).
...e ci mancherebbe!!!
Ciao,


 Ah, ma pure a Roma si dice "cioccare"?
(Nel senso di "tanare", scoprire, cogliere col sorcio in bocca) io 
credevo si dicesse _solo_ a Roma: si dice anche in Ascoli? :-)

 credevo si dicesse _solo_ a Roma: si dice anche in Ascoli? :-)
Ebbene si!
Mentre invece "tanare" è tipicamente capitolino.


 sviluppatore a rompere la build?
Qualche volta anche gli sviluppatori piu' disciplinati si dimenticano di 
far girare tutti i test prima di fare il commit.


 - poco flessibile
Hudson è tutt'altro che sovraingegnerizzato, è allo stesso tempo 
essenziale e completo. Proprio un bel prodotto.


 far girare tutti i test prima di fare il commit.
Da noi vengono puniti con il taglio delle mani... :-)
Scherzi a parte, basta che modifichi un po' lo scriptino per il build e 
gli fai lanciare anche gli unit-test e alla fine, anche se te ne scordi, 
i test partono lo stesso, no? ;-)
Ciao,
Giulio
-- 
OnAir:
http://www.giuliopetrucci.it
http://www.fujikomonamour.com

 i test partono lo stesso, no? ;-)
Potrebbe essere un idea.
Pero' non basta che lo script fa girare i test, dovrebbe fare anche 
l'update di tutto altrimenti potrebbe esserci il seguente caso che cmq 
rompe la build.
La struttura dei sorgenti č cosě:
	src/
		parteA/
		parteB/
Il programmatore modifica la parteA, intanto qualcun'altro modifica la 
parteB ma il programmatore non lo sa.
Il programmatore fa girare i test, funzionano tutti, anche i test della 
parteB funzionano. Ma non dovrebbero, qualcun'altro l'ha modificato ma 
lui non lo sa.
Il programmatore fa il commit e il sistema di controllo di versione 
glielo lascia fare perché il programmatore ha modificato src/parteA e 
quindi non č necessario che il VCS gli imponga di fare anche l'update 
della parteB.
Cosě alla fine il repository contiene:
  - src/parteA alla versione del nostro sviluppatore
  - src/parteB alla versione di qualcun'altro
Senza che nessuno abbia mai fatto il test con questa configurazione di 
versioni.


 versioni.
Si, la situazione che descrivi è assolutamente possibile. Tuttavia credo 
che vada contestualizzata nel team di sviluppo di cui faccio parte: ci 
sono 4-5 sviluppatori, ossia *pochi*! :-) Inoltre se uno sviluppatore ha 
modificato la parteB questa modifica viene automaticamente notificata 
allo sviluppatore che sta lavorando sulla parteA e questo fa l'update.
Ovvio che per team di grandi dimensioni è bene 
automatizzare/centralizzare questo processo, ma credo che per team di 
piccole dimensioni un po' di "disciplina" possa bastare.
Ciao e grazie per lo spunto,
Giulio
-- 
OnAir: Evanescence - "Bring me to Life" (oggi mi sento parecchio 
"adolescente"...)
http://www.giuliopetrucci.it
http://www.fujikomonamour.com

  - src/parteB alla versione di qualcun'altro
Questo è un problema tipico: la gestione delle interazioni tra le
diverse parti del progetto. Chiedo: i tools citati in precedenza
getsiscono in modo automatico queste situazioni? Inoltre: non si
rischia un deadlock, programmatore A sta continuamente a testare
l'integrazione con parte B, e viceversa?
Dove ho lavorato, si cercava sempre di assegnare ad ogni programmatore
o piccolo gruppo (3-4 max) la gestione di un'intera funzionalità,
indipendente dalle altre (per quanto possibile).

 getsiscono in modo automatico queste situazioni?
Dipende da cosa intendi per automatico. CCNet fara' girare gli unit
test (e/o qualsiasi altro tipo di test o funzione post build tu
desideri) dopo _ogni_ commit, e quindi se qualche unit test non passa
piu', tu avrai traccia della cosa (e chi e su che cosa ha fatto il
commit). TeamCity con il delayed commit non ti accettera' il commit.
Altri tool probabilmente avranno simile o anche altre politiche/
feature.
--
ale
http://ale.riolo.co.uk

 L'idea iniziale era questa. ;-)
IMVHO e' sbagliata. CCNet e' un tool talmente semplice ed elastico,
che e' un peccato non usarlo. Possibilmente altri tool pure.
Probabilmente e' perche' ho iniziato a fare CI ormai da anni, ma al
giorno d'oggi non saprei come fare senza, e sinceramente non
immaginavo ci fosse chi facesse senza al giorno d'oggi.
--
ale
http://ale.riolo.co.uk

 TeamCity con il delayed commit non ti accettera' il commit.
Una domanda: ma TeamCity lo possso utilizzare anche "fuori" da un IDE? 
Ad esempio se per svilupare uso Vim, posso utilizzarlo "a mano"?


 immaginavo ci fosse chi facesse senza al giorno d'oggi.
Eccomi qua! ;-)
Ciao,
Giulio
-- 
OnAir:
http://www.giuliopetrucci.it
http://www.fujikomonamour.com

 potersi considerare inesistenti. 
Bč, mi sembra un'esagerazione. I programmatori dovrebbero lavorare
sulla base di specifiche di interfacciamento, di integrazione, e
standard vari.
Altrimenti č inutile parlare di incapsulamento e tutte le altre belle
cose dell'OO, e non solo.

 Ad esempio se per svilupare uso Vim, posso utilizzarlo "a mano"?
Come da precedente risposta, non ho mai lavorato con TeamCity. Tempo
fa discutevo della mancanza della funzionalita' del delayed commit
(all'epoca non sapevo nemmeno avesse un nome ben preciso, spiegavo
semplicemente cosa c'era che avrei voluto di piu' da CCNet) con alcuni
colleghi, ed uno mi fece notare che c'era questo tool di JetBrain che
disponeva della stessa.
BTW, alla tua domanda dovrebbe rispondere questa:
http://www.jetbrains.com/idea/features/version_control.html
Secondo cui, i scm supportati sono:
*  Subversion
* Perforce
* CVS
* Borland StarTeam
* Microsoft Visual SourceSafe
* Team Foundation Server 2005
* Team Foundation Server 2008
* IBM Rational ClearCase (Base and UCM)
* StarTeam support improvements
--
ale
http://ale.riolo.co.uk

 cose dell'OO, e non solo.
L'incapsulamento e le altre belle proprieta' dell'OO hanno poco a che
fare con quanto sopra: un qualsiasi sistema complesso e' generalmente
impossibile da stabilizzare senza un controllo ad anello chiuso (e tra
l'altro, solo all'interno di ben determinate condizioni al contorno).
Una volta che tu accetti che lo sviluppo di un'applicazione e' un
sistema complesso (dinamico, MIMO, probabilmente non lineare e non
stazionario), allora devi accettare che la retroazione e' condizione
necessaria e _non sufficiente_ per la sua stabilizzazione.
Spannometricamente, piu' spesso e piu' velocemente la retroazione
avviene, prima e' probabile che il sistema si stabilizzi.
Quando mi parli di incapsulamento in questo contesto, e' come se mi
stessi dicendo che un grattacielo sta su perche' le molecole dei
mattoni non trabordano a velocita' apprezzabile ad occhio nudo dalle
faccie dei mattoni stessi, quando parli di standard, e' come se tu mi
stessi dicendo che il grattacielo sta su perche' qualche ingegnere
civile o geometra afferma di avere seguito le norme vigenti, e via di
questo passo.
In realta' il grattacielo non casca perche' e' un sistema complesso
stabile all'interno di determinati parametri fisici.
--
ale
http://ale.riolo.co.uk

 questo passo.
No, il grattacielo sta su (o l'auto cammina) anche (non solo) perchè
qualcuno ha standardizzato certi parametri, ad esempio le filettature
di dadi e bulloni. O magari semplicemente le unità di misura con cui si
fanno i calcoli strutturali :-)

 allo sviluppatore che sta lavorando sulla parteA e questo fa l'update.
Nel mio team siamo in due.
Ci abbiamo messo un attimo a configurare il CI.
Ci siamo messi d'accordo che bisogna far girare i test prima di fare il 
commit.
Non abbiamo modificato gli script di build per rinforzare questa regola.
Ci troviammo bene.


 indipendente dalle altre (per quanto possibile).
E' una buona idea.


 immaginavo ci fosse chi facesse senza al giorno d'oggi.
Se pensi che ci sono pure quelli che fanno a meno degli unit test...


 Eccomi qua! ;-)
Io ho cominciato da usarlo solo da un anno.


 Una domanda: ma TeamCity lo possso utilizzare anche "fuori" da un IDE?
Giusto per aggiungere che TeamCity, per piccoli team (fino 20 utenti,
20 configurazioni di build e 3 build agent), e' free.
http://www.jetbrains.com/teamcity/buy/buy.jsp#professional
 (tra
l'altro, qui c'e' scritto che "You can run as many instances of
Professional Edition Server as needed").
--
ale
http://ale.riolo.co.uk

 Bè... perché non farlo? ;-)
Altra ragione: da una veloce sguardo agli argomenti e a 1-2 pagine,
questo su scribd sembra ben fatto:
http://www.scribd.com/doc/420459/continuousintegrationimprovingsoftwarequalityandreducingrisk
--
ale
http://ale.riolo.co.uk

 * StarTeam support improvements
Giusto per curiosità, non faccio codice da anni ma cvonosco bene il
prodotto, che tu sappia PVCS della Serena Software è supportato? Te lo
chiedo perchè in vari operatori e sviluppatori Telco è un ambiente
usatissimo e diffuso...


Sul sito del prodotto ci sarà scritto, no?


 Sul sito del prodotto ci sarà scritto, no?
Non direttamente, per la verità,  ma qualcosa ho trovato
http://plugins.intellij.net/plugin/?id=1530