El proxy Git que empuja a múltiples controles remotos

Estoy buscando un software que espero que alguien haya creado. Voy a describir este software aquí esperando que alguien haya escuchado algo así y pueda orientarme en la dirección correcta.

Estoy desarrollando una aplicación web que se implementa en Heroku. Debido a las limitaciones de Heroku, me encuentro en la desafortunada situación de tener cuatro (4) repositorys Git remotos para el mismo repository.

¿Por qué cuatro?

Tenemos múltiples "aplicaciones" en Heroku. Uno para la producción y un par de "aplicaciones" de escenificación. Estos son todos para la misma aplicación, pero en Heroku son "aplicaciones" separadas, por lo que podríamos probar la puesta en escena antes de llevarlos a la producción.

Cada aplicación en Heroku obtiene su propio repository de Git, y automáticamente implementa la twig master cada vez que se envía una nueva confirmación a esa twig master . Esta política de Heroku es el quid de nuestro problema. Porque esto significa que tenemos 3 repositorys diferentes en Heroku, además de nuestro repository de GitHub.

¿Por qué es un problema tener 4 controles remotos diferentes de Git? Porque significa que cuando desarrolla y crea nuevas confirmaciones, tiene que (1) presionar solo un control remoto o (2) enviar a todos los controles remotos.

Hacer (1) significa pensar a qué control remoto desea presionar. Odio tener que pensar en esto. Cuando desarrollo, no me importan los controles remotos, me comprometo y presiono y vuelvo al trabajo. Si quiero implementar una twig en el server de staging_1 1, por ejemplo, fusionaría esa twig en la twig de staging_1 y la presionaré. No me gusta elegir a qué control remoto presionar.

Otra desventaja de (1) es que los controles remotos no están sincronizados.

Lo que quiero es (2) Quiero que cada acción de empuje empuje a todos nuestros cuatro repositorys.

Pero hay 2 problemas con eso:

Problema 1: las "aplicaciones" de escenificación en Heroku implementan lo que está en master . No quiero que hagan eso. Quiero asignar la twig staging_1 en mi repository a la twig master en el repository Git del server de transferencia.

Problema 2: Hacer que mi computadora avance a los 4 reposes llevará mucho time. Incluso 1 acción push de Heroku lleva mucho time. Puede tomar 40 segundos a veces.


Solución propuesta

Esto es lo que quiero. Quiero tener un server especializado de Git que actúe como un proxy. Cada vez que presiono desde mi computadora local en este server Git, insertá esas mismas twigs en nuestros 4 repositorys en paralelo . De esa manera, desde la perspectiva de mi computadora local, el push parecerá instantáneo, mientras que este server proxy tratará automáticamente los repositorys de Heroku en segundo plano.

Si la inserción de cualquiera de los 4 controles remotos falla por algún motivo, quiero que este proxy me informe de alguna manera, así sabré que algo está roto y podría solucionarlo.

Otra cosa que este proxy tendrá que hacer es el mapeo master . Cada vez que empujaba la twig de staging_1 hacia ella, la staging_1 como staging_1 en todos los controles remotos, pero para el control remoto que pertenece al server de staging_1 también empuja esa twig como master , por lo que Heroku sabrá desplegarla.

(Es bastante triste que Heroku esté diseñado de una manera que me hace necesitar un proxy como este, pero eso es lo que tengo que tratar).

Eso es todo. Esa es la solución que quiero. ¿Alguien sabe de un progtwig así?

Crea un nuevo repository, al que puedes presionar cuando quieras que se propague el empuje, y escribe un gancho post-recepción para propagar los cambios cuando ingresas a este repository.

Esto me parece un poco loco. Tengo varias aplicaciones en Heroku que ejecutan entornos diferentes. Tengo un Repo Github y luego los controles remotos Heroku para los diferentes entornos. También tiendo a mantener una twig de Git que coincide con uno de los mandos a distancia Heroku.

Las implementaciones se realizan (como dice John) con:

 git push heroku_remote local_branch:master 

He documentado este enfoque básico aquí:

http://neilmiddleton.com/deploying-topic-branches-to-heroku/

Sin embargo, tiene la necesidad de automation completa de lo que puedo decir. Puede usar un service como TDDium para hacer este tipo de cosas para usted, mirando una twig de Git y luego presionando a una sucursal remota (como un control remoto de Heroku) cuando pase su suite de testings.

http://neilmiddleton.com/continuous-deployment-with-heroku/

Estoy bastante seguro de que el enfoque TDDium le dará lo que necesita, con la capa adicional de CI.