2009/10/9 Nelson Fernandez <[email protected]>: > > 2009/10/8 Carlos Kozuszko <[email protected]> >> >> Hola! >> >> 2009/10/8 Nelson Fernandez <[email protected]>: >> > Alguien está desarrollando y manteniendo releases con Git ? que workflow >> > utilizan ? >> >> Para qué necesitás exactamente un branch por release? Ese workflow me >> parece razonable unicamente cuando hacés releases de un producto y >> tenés que hacer mantenimiento sobre releases pasadas y luego >> backportear los cambios a los releases que corresponda. Lo que pasaría >> por ejemplo con la gema de rails (y muchísimos otros casos). >> >> En el caso de desarrollo web no es simplemente necesario un branch por >> release que está siendo accesible desde un server? >> >> Nosotros en nuestro esquema màs simple trabajamos con dos ramas >> unicamente: master y production >>
Eso, eso. En general a donde he trabajado el esquema que se usa es se programa en master, para features no triviales se hace un topic branch, se mergea a master, se tira en staging, se aprueba, se mergea a 'stable' (o 'production' o como quieras) y se hace deploy a production. Y cada vez que sea hace un deploy a production se hace un tag. Just in case, para tener una noción de qué se deployó cada vez. Igual, hay proyectos y proyectos. He trabajado en proyectos que tienen 3 environments (uno "antes" de staging, que los developers tenemos permiso de romper liberalmente, mientras que staging se trata de usar para cosas que más o menos calculamos que ya funcionan, porque a veces se hacen demos, y cosas así) En general, el único consejo que te voy a dar, es YAGNI. No hagas nada hasta que lo necesites. No te ates a un workflow o esquema de releases si no necesitás nada. Es un embole andar haciendo 84 merges para hacer un deploy :P (ah, y por cierto, medianamente relacionado: heroku! y por si no lo vieron http://github.com/mislav/git-deploy) > Si justamente estabamos trabajando en un esquema así. > >> >> En master va todo el código compartido y de donde se toma el código >> para hacer deployments al server de staging. Luego, cuando el >> feature/ticket/story relacionado con los commits sea aprobado, se pasa >> a production y se hace el deployment tomando esa rama al server de >> production. >> >> Así de simple :) >> >> Para hacerlo aún más práctico usamos cerise un plugin que hizo nuestro >> queridísimo Luis Lavena para pasar todos los asociados con un numero >> de ticket de una rama a otra haciendo git cherry-pick (en el README >> hay detalles). >> >> http://github.com/area17/cerise >> Si usás topic branches por feature/ticket, 'git checkout stable; git merge 700-foobar; git push origin stable' no es para nada complejo :) Especialmente porque ta, te quiero ver usando PivotalTracker "Ticket #2388123"—wait, lo escribi bien? :P > muy bueno !.. no lo conocía, puede servir.. tendríamos que estandarizar los > textos de los commits, pero es lo de menos > > >> >> Espero te sirva esta simplificación de workflow, aunque por ahi no se >> ajuste a tus necesidades. >> > > si, estoy buscando a ver si encuentro ejemplos de modelos de laburo, para > organizar más el tema interno también. > > gracias ! > > -- > :: nelson :: > [ artesano de software & software craftsman ] > http://netflux.com.ar > > > _______________________________________________ > Ruby mailing list > [email protected] > http://lista.rubyargentina.com.ar/listinfo.cgi/ruby-rubyargentina.com.ar > > _______________________________________________ Ruby mailing list [email protected] http://lista.rubyargentina.com.ar/listinfo.cgi/ruby-rubyargentina.com.ar
