1. Integración Continua
y Rails
David Calavera
11870.com

2. ego slide
• desarrollador en 11870.com
• open source: Hudson, Netbeans
• commiter de la Fundación Apache

3. sobre mi

5. sobre la charla

6. sobre que
NO
trata esta charla

7. nada que nos enganche
Texto
más a Rails

8. como configurar
un servidor de CI

9. sobre que trata
esta charla

10. usar menos herramientas

11. automatizar tareas

12. calidad del código

13. ¿qué es integración
continua?

14. “ practica de reunir el código
que estamos desarrollando
frecuentemente, para
verificarlo y evitar errores
”
David Calavera

15. “ Continuous Integration is a software development
practice where members of a team integrate their work
frequently, usually each person integrates at least daily
- leading to multiple integrations per day. Each
integration is verified by an automated build (including
test) to detect integration errors as quickly as possible.
Many teams find that this approach leads to significantly
”
reduced integration problems and allows a team to
develop cohesive software more rapidly.
Martin Fowler

16. ¿para qué sirve?

17. reducir riesgos

18. falta de cohesión

19. descubrir errores pronto
http://www.agitar.com/solutions/why_unit_testing.html

20. baja calidad del código

21. evitar repetir
procesos manuales

22. generar deploys
en cualquier momento

23. automatizar el build
• reducir el número de procesos manuales
• ¡¡Rails --tasks --silent | wc -l a ejecutar!!
incorpora 71 tareas
• rake
• ¡¡Capistrano añade 22 -tareas más!!
• expr `cap --tasks | wc -l` 7

24. ¡¡autodestrucción!!

25. reducir su duración
• usar una máquina dedicada para CI
• mejorar el rendimiento de nuestros tests
• separar los tests por categorías
• ejecutar el build por etapas

26. ejecutar los test en
paralelo
• sudo gem install deep_test
DeepTest::TestTask.new 'deep_test:functionals' do |t|
t.pattern = quot;test/functional/**/*_test.rbquot;
t.number_of_workers = 2
end

27. ejecutar los test en
paralelo
• también para RSpec
Spec::Rake::SpecTask.new 'deep_spec:functionals' do |t|
t.spec_files = FileList['spec/functional/**/*_spec.rb']
t.deep_test :number_of_workers => 2
end

28. ejecutar los test en
paralelo
• ¡con una base de datos para cada worker!
DeepTest::TestTask.new 'deep_test:functionals' do |t|
t.pattern = quot;test/functional/**/*_test.rbquot;
t.worker_listener = 'DeepTest::Database::MysqlSetupListener'
end

29. usar un servidor de CI
• preguntar por cambios en el repositorio
• realizar acciones en horarios determinados
• soportar diferentes herramientas
• mostrar builds históricos
• soportar diferentes tipos de informes
• soportar diferentes tipos de notificaciones

30. CruiseControl.rb

31. CruiseControl.rb
• muy POCO “user friendly”
• plugins perdidos por internet
• pero muy fáciles de desarrollar
• http://cruisecontrolrb.thoughtworks.com

32. Hudson

33. Hudson
• MUY “user friendly”
• plugins muy fácilmente localizables
• pero algo más complicado de desarrollar
• http://hudson.dev.java.net

34. Run Code Run
•

35. Run Code Run
• de momento solo proyectos open source
• de momento solo se integra con github
• soporte de CI para la última Rails Rumble
• http://runcoderun.com

36. mejorar la perspectiva

37. aumentar la confianza

38. ¿cuáles son las
reglas básicas?

39. commit frecuente

40. no subir
código roto

41. arreglar el build
inmediatamente

42. escribir test automáticos

43. hacer builds en local

44. evitar usar código roto

45. ¿qué pasos hay
que seguir para
montar un sistema
de CI?

46. 1. integración de la
base de datos

47. lo que hay que hacer
• automatizar los cambios de la base de datos
• crear la base de datos
• modificar la base de datos
• testing e inspección

48. Migraciones
• muchas mejoras desde Rails 2.1
create db/migrate/20081112232842_modify_user.rb
class ModifyUser < ActiveRecord::Migration
def self.up
change_table :user do |user|
t.rename :surname, :last_name
t.remove :age
...
end
end
end

49. 2. Testing continuo

50. test unitarios
• enfocados en un objeto
• comprobar installes totalmente unitario
que
•
sudo gem unit_record
ActiveRecord::Base.disconnect!
• usar mocks en lugar de fixtures

51. test unitarios
• ¡¡hay que hacerlos para cualquier clase!!
•sudo gem install unit_controller
def setup
@controller = UserController.new
@controller.do_not_render_vew
end

52. test funcionales
• usa factories en lugar de fixtures
•
sudo gem install thoughtbot-factory_girl
Factory.define :user do |u|
u.first_name 'Joe'
u.last_name 'Doe'
u.email {|att| quot;#{att.first_name}@example.comquot;.downcase }
end

53. test funcionales
• ¡¡hay que hacerlos modelotodas lasde datos
para clases!!
• interacción entre el y la base
• interacción entre el modelo y el controlador
• interacción entre el controlador y la vista

54. 3. Inspección continua

55. reducir la complejidad
• Flog
def flog(output, *directories)
`find #{directories.join(quot; quot;)} -name *.rb|xargs flog
> #{RAILS_ROOT}/tmp/flog/#{output}.txt`
end
desc quot;Flog models, controller, helpers and libquot;
task :flog do
flog quot;allquot;, *%w[app/models app/controllers app/helpers lib]
end

56. eliminar código
duplicado o sin usar
• Dust
def unused_lvar
a = 1
1 + 2
end
d = Dust::LocalVariableDuster.new(Object, :unused_lvar)
d.dust!
d.warnings

57. eliminar código
duplicado o sin usar
• PMD-CPD
def cpd(*directories)
`java net.sourceforge.pmd.cpd.CPD --minimum-tokens 100 -files
#{directories.map(quot; --files quot;)} --language ruby`
end
task :cpd do
cpd *%w[app/models app/controllers app/helpers lib]
end

58. comprobar cobertura
• Rcov
desc 'Test coverage report'
task :coverage do
rm_f quot;coveragequot;
rm_f quot;coverage.dataquot;
rcov = quot;rcov --rails --aggregate coverage.data -Ilibquot;
`#{rcov} --no-html test/unit/*_test.rb`
`#{rcov} --no-html test/functional/*_test.rb`
`#{rcov} --html test/integration/*_test.rb`
`open coverage/index.html` if PLATFORM['darwin']
end

59. all in one
• Metrics_fu para cruisecontrol.rb
• Saikuro
• Flog
• Rcov
• Rails stats
• RubyMetrics para hudson
• Rcov
• Rails stats

60. revisión de código

61. 4. Deploy continuo

62. deploy continuo
• etiquetar el repositorio
• producir un entorno limpio
• etiquetar cada build
• tener la capacidad de volver atrás

63. 5. Feedback continuo

64. feedback continuo
• la información correcta
• a la persona indicada
• en el momento esperado
• de la forma correcta

68. ¿alguna pregunta?

69. Fotos
• http://flickr.com/photos/chicanerii/507573394
• http://flickr.com/photos/3epmedia/1160364177
• http://flickr.com/photos/cathycracks/183170786
• http://flickr.com/photos/smitty/2245445147/
• http://flickr.com/photos/fcw/384316867/
• http://www.flickr.com/photos/auxesis/2965947278/
• http://www.flickr.com/photos/penguin_man44/1203331011/
• http://flickr.com/photos/rekha6/2902282813/
• http://flickr.com/photos/teepee1/1508261796/
• http://flickr.com/photos/teepee1/2614839885/
• http://flickr.com/photos/_saturnine/2294717858/
• http://flickr.com/photos/ezra/459279198/
• http://flickr.com/photos/x180/1397019888
• http://flickr.com/photos/soulcheck/384769773/
• http://flickr.com/photos/znachor/255143511/
• http://flickr.com/photos/julianbleecker/156303245/