ruby on rails - deploy - ¿Implementación de Good Git usando la estrategia de sucursales con Heroku?
ruby heroku (3)
¿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.
Todo lo que se envía al origen / maestro desencadena un guión que extrae el nuevo código de rieles al área de ensayo (servidor web de rieles simples).
Cuando llegue el momento de enviar una nueva versión de producción a Heroku, ¿debería crear una nueva rama (llamada algo así como production_version_121) y presionarla de alguna manera para 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 ... probarla y enviarla a Heroku.
Por ejemplo, es posible que no desee que todo el último código sea enviado 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.
NB Voy a intentar evitar Capistrano al principio y obtener algo que funcione manualmente por el momento.
¿Pensamientos? ¿Mejores prácticas?
Desde que leí el exitoso modelo de derivación Git 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 enseñado dicen que ya estaban haciendo algo similar y les resulta muy fácil adaptarse.
En pocas palabras, tienes 2 ramas que son permanentes (dominar 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.
En el proyecto Gemcutter, simplemente tenemos una rama de production . Cualquier cambio que deseemos ver en el sitio de producción se fusionará en esa rama y luego se implementará con:
git push heroku production:master
La rama de staging sirve para un propósito similar para el sitio de ensayo (también en Heroku)
Hay una variedad de formas de hacerlo, y realmente depende de su preferencia.
Te daré una posible estrategia: dado que ya tienes una configuración de estadificación automática que usa 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 insertar ese código en su servidor de producción, debe tag la sucursal con 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
Sugiero crear un guion o git alias para automatizar el etiquetado de marcas de tiempo, ya que es importante usar un esquema de nombres consistente. Yo uso algo como esto:
git config alias.dtag ''!git tag release-`date "+%Y%m%d%H%M"`''
Eso me permite escribir simplemente git dtag cuando quiero etiquetar un lanzamiento con una marca de tiempo.
Puedes ver tus etiquetas usando la etiqueta git tag y verlas usando git show release-1234 . Para obtener más información sobre las etiquetas, ejecute la git help tag . También puede encontrar útil esta guía de Github sobre etiquetado. También recomendaría leer los flujos de trabajo de otras personas (aquí hay una buena reseña ) y escoger y elegir lo que funcione para usted.