1. CONTINUOUS INTEGRATION
Sam Reghenzi
http://sammyrulez.com
@sammyrulez
venerdì 10 giugno 2011
2. COSA E’
Un sistema volto a verificare in un determinato istante la
consistenza di una code base.
venerdì 10 giugno 2011
3. Source code
Repository
Check out
Build server Make
Tests
Metriche
FLUSSO FONDAMENTALE
venerdì 10 giugno 2011
4. PERCHÈ
Integrare continuamente i cambiamenti al codice eviterà ritardi
più avanti nel ciclo del progetto
venerdì 10 giugno 2011
5. PRACTICES OF CONTINUOUS
INTEGRATION
Single Source Repository
Mantenere un singolo repository per il codice di un artefatto.
Se lo stesso artefatto è presente su repository differenti
dovrebbe essere oggetto di diversi processi di integrazione
venerdì 10 giugno 2011
6. PRACTICES OF CONTINUOUS
INTEGRATION
Build automatiche
La build del progetto non deve essere condizionata da
conoscenze specifiche , individuali o infrastrutturali
Bundler Migrations Seed
Gems Fixture
venerdì 10 giugno 2011
7. PRACTICES OF CONTINUOUS
INTEGRATION
Build che integrino i test e metriche
I test garantiscono a vari livelli la stabilità dinamica e la
correttezza del software oggetto della build.
Le metriche innalzano il livello di qualità intrinseca e di
standardizzazione del codice.
venerdì 10 giugno 2011
8. PRACTICES OF CONTINUOUS
INTEGRATION
Tutti committino almeno una volta al giorno
Senza una code base aggiornata il processo di integrazione è
inutile.
Tempi lunghi di produzione di codice stabile possono essere
indicatori di un problema di processo.
venerdì 10 giugno 2011
10. KEEP BUILD FAST!
Il valore del processo di CI è dare feedback rapidamente
venerdì 10 giugno 2011
11. REPOSITORY PULL
• Fornisce un feedback più immediato
• Stimola il commit atomico
• Limita il desiderio di utilizzare l’SCM come area scambio file
venerdì 10 giugno 2011
12. EXTREME FEEDBACK
Funziona meglio dell’email e smorza lo stress
venerdì 10 giugno 2011
14. E INVECE STRUMENTI!
• Nessuno ( cron + script + rake )
• ContinuousBuilder
• Cerberus
• CruiseControl
• CruiseControl.rb
venerdì 10 giugno 2011
15. INTEGRITY
Pros Cons
• Leggero • In fase transitoria di sviluppo
• Facile • Supporta solo git
da configurare
• Supporto • Pochi punti di estensione
per git
venerdì 10 giugno 2011
16. TRAVIS
Pros Cons
• In the cloud • In fase iniziale di sviluppo
• Specfico per ruby • Supporta solo git
• Supporto per git • Pochi punti di estensione
venerdì 10 giugno 2011
17. JENKINS
Pros Cons
• Provata stabilità • Non leggero come i
• Estensibile
precedenti
• Supporta qualunque
tecnologia
venerdì 10 giugno 2011
18. SETUP
• Download & Install
• Aggiungere i plug-in necessari ( e anche quelli divertenti !)
• Creare un JOB
• Post commit hooks ( opzionale )
• Aggiungere i rake task per le metriche
venerdì 10 giugno 2011
20. CI_REPORTER GEM
namespace :hudson do
task :spec => ["hudson:setup:rspec", 'db:migrate', 'rake:spec']
namespace :setup do
task :pre_ci do
ENV["CI_REPORTS"] = 'hudson/reports/spec/'
gem 'ci_reporter'
require 'ci/reporter/rake/rspec'
end
task :rspec => [:pre_ci, "ci:setup:rspec"]
end
end
venerdì 10 giugno 2011
21. CONTINUOUS DEPLOYMENT
Cosa non è
•Deployare in produzione ad ogni commit
•Usare la produzione invece dell’ambiente di test
Cosa è
•Avere un ambiente allineato con le build
•Deployare in produzione automaticamente alcune build
venerdì 10 giugno 2011
22. CONTINUOUS DEPLOYMENT
• Continous Integration
• SCM sano
• Semplice sistema di deploy
• Ambiente replica della produzione per test funzionali
• Monitoring (!!!)
venerdì 10 giugno 2011
25. GRAZIE A TUTTI
Riferimenti
•5 steps http://radar.oreilly.com/2009/03/continuous-deployment-5-eas.html
• Martin Fowler http://martinfowler.com/articles/continuousIntegration.html
•Rails & Jenkins http://reprocessed.org/blog/easy_rails_ci_with_hudson
venerdì 10 giugno 2011