¿Implementación de Good Git usando la estrategia de sucursales con Heroku?

Question

¿Cuál es una buena estrategia de implementación para usar con Git + Heroku (Ruby on Rails)?

Actualmente la forma en que trabajo con mi repositorio Git de origen: todas las características (o "historias") se comprueban primero como ramas, luego se fusionan con el maestro y se envían al origen.

Cualquier cosa que se envíe al origen/maestro desencadena un script que extrae el nuevo código de raíles al área de ensayo (servidor web simple de raíles).

Cuando llegue el momento de impulsar una nueva versión de producción a Heroku, ¿debería crear una nueva rama (llamada algo así como production_version_121) y llevarla de alguna manera a Heroku?

Idealmente, me gustaría elegir y elegir qué características de las versiones de desarrollo anteriores debería incluir en la rama de producción ... pruébelo, y presione a Heroku.

Por ejemplo, es posible que no desee que todo el último código pase a producción. Es posible que desee la función "a" en la que trabajé e incluir "c" fusionada en producción de alguna manera, sin incluir la función experimental "b" que necesita más depuración.

N.B. Voy a tratar de evitar Capistrano al principio y obtener algo que funcione manualmente por el momento.

¿Pensamientos? ¿Mejores prácticas?

Answer 1

En el proyecto Gemcutter simplemente tenemos una rama production.Cualquier cambio que queremos ver en el sitio de producción quedan fusionadas en esa rama, y ​​luego se despliegan con:

git push heroku production:master 

La rama staging sirve a un propósito similar para el sitio de ensayo (también en Heroku)

Answer 2

Hay una variedad de maneras de hacerlo, y realmente depende de su preferencia.

Te daré una posible estrategia: dado que ya tienes una configuración automática de etapas que utiliza master, te sugiero que crees una rama de 'producción'. Cuando desee promover una corrección/función a la producción, simplemente fusionaría la rama de tema en su rama de 'producción'.

git checkout production 
git pull . my-topic-branch 
(resolve any conflicts) 

Cuando esté listo para realmente empuje ese código en el servidor de producción, debe tag la rama usando un nombre único (probablemente con una marca de tiempo). Luego simplemente empuja la rama de producción a Heroku.

git checkout production 
git tag release-200910201249 

me gustaría sugerir la creación de un script o git alias para automatizar el etiquetado de las marcas de tiempo, ya que el uso de un esquema de nomenclatura coherente es importante. Utilizo algo como esto:

git config alias.dtag '!git tag release-`date "+%Y%m%d%H%M"`' 

que me permite no sólo tiene que escribir git dtag cuando quiero etiquetar un comunicado con una marca de tiempo.

Puede ver sus etiquetas usando git tag y verlas usando git show release-1234. Para obtener más información sobre las etiquetas, ejecute git help tag. También puede encontrar este Github guide en etiquetado útil. También recomendaría leer los flujos de trabajo de otras personas (aquí está a nice writeup) y escoger y elegir lo que funciona para usted.

Answer 3

Alguna vez desde que leí el A successful Git branching model de Vincent Driessen, me enganché. Toda mi compañía (8 de nosotros) ya se ha estandarizado en este modelo y algunos otros lugares con los que he consultado también comenzaron a usarlo.

La mayoría de las personas a las que les he mostrado dicen que ya estaban haciendo algo similar y les resulta muy fácil adaptarse.

En pocas palabras, usted tiene 2 ramas que son permanentes (maestro y desarrollar). La mayoría de las veces solo harás que las ramas se desarrollen y se fusionen para desarrollarse. Las cosas se ponen un poco más complejas cuando empiezas a hacer lanzamientos de producción y revisiones, pero después de leer la publicación un par de veces, se vuelve incrustada.

Incluso hay una herramienta de línea de comandos llamada git-flow para ayudarte.