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
_______________________________________________ Ruby mailing list [email protected] http://lista.rubyargentina.com.ar/listinfo.cgi/ruby-rubyargentina.com.ar
