2010/4/15 Juan Maria Martinez Arce <[email protected]> > 2010/4/15 Mariano Simone <[email protected]> > >> Hola a todos: >> >> Últimamente me encontré con un "problema" algo incómodo: En un mismo >> proyecto, había varios desarrolladores, trabajando incluso en sistemas >> operativos diferentes. Esto generaba que hubiese configuraciones a nivel >> "environment" que debían ser diferentes (ejemplo: el path al socket para >> MySQL en database.yml) >> >> Ante esta situación, no encontré otra manera más que hacer dos nuevos >> environments: desarrollador1-development y desarrollador2-development, >> duplicar los directorios adentro de config/environments, reemplazar todos >> los "if RAILS_ENV == "development"" por "if >> RAILS_ENV.contains?("development") y listo... >> >> Ahora la pregunta: ¿hay alguna forma más prolija de hacer esto? Lo que se >> me ocurría que "solucionaría" mi problema de tener que duplicar todo es que >> exista algún tipo de jerarquía de environments, con lo que cada environment >> de development podría heredar de uno común, pero no encontré nada que me >> permita hacer esto. >> >> Gracias a todos >> -- >> Mariano Simone >> http://www.0pointer.com.ar >> >> _______________________________________________ >> Ruby mailing list >> [email protected] >> http://lista.rubyargentina.com.ar/listinfo.cgi/ruby-rubyargentina.com.ar >> >> > Hola Mariano, > > La verdad que mantener un codebase prolijo cuando tenes mucha gente > metiendo mano en el proyecto es bastante complicado y en mas de una ocasión > se puede convertir en un verdadero dolor de cabeza. > > Tenés prácticas básicas como evitar enviar al repo archivos como el > database.yml o el schema.rb. En el caso de archivos de setup (por ejemplo, > cuando tenes un config/settings.yml o el mismo database.yml) lo que suele > recomendar es enviar al repo archivos sample (ej: settings.yml.sample o como > quieras llamarle) para que cada uno en su copia local lo modifique a gusto y > paladar. > > Pero la verdad con esas prácticas, vas a tener ocasiones en que tengas > otros problemas que van a estar relacionados con cómo trabajan con su repo. > Por suerte, tenes un par de articulos como para darte una mejor idea de > esto. Yo te recomiendo los siguientes articulos: > > http://www.insignia4u-blog.com/2010/03/03/todo-sobre-git-un-enfoque-agil/ > > http://reinh.com/blog/2009/03/02/a-git-workflow-for-agile-teams.html > > Espero que sirva. > > Saludos. > > -- > Juan Maria Martinez Arce > (in)signia > > O: +54 381 420 7387 > M: +54 381 155 505571 > > http://www.linkedin.com/in/jmartinezarce > http://www.workingwithrails.com/person/8707-juan-maria-martinez-arce >
Gracias a todos por las respuestas :D La solución de tener el archivo de configuración fuera del control de versiones soluciona una parte de mi duda... Sin embargo, hay otra que todavía no me cierra. Supongan que el sistema necesita cierta credential de otro sistema (por ejemplo, para loguearse a Twitter y twittear algo, o de una cuenta de jabber para mandar mensajes) y cada desarrollador usa una cuenta distinta para probar. ¿Dónde pondrían esa información? (siguiendo el patrón que me dijeron, pensaría en poner en initializers un sistema_externo.rb.example y que después cada uno haga la suya). En el caso del database.yml entiendo que su esquema no cambia nunca, pero en estos casos veo más probable que haya necesidad de cambiar la forma en que se inicializa algo, ¿cómo mantener al equipo al tanto de ese cambio? Gracias nuevamente -- Mariano Simone http://www.0pointer.com.ar
_______________________________________________ Ruby mailing list [email protected] http://lista.rubyargentina.com.ar/listinfo.cgi/ruby-rubyargentina.com.ar
