Aplicar cambio en cada lanzamiento

Actualmente tengo una aplicación que se comunica con un server web. De este server web, tengo 2 instancias. Una testing en mi máquina local, y una de producción en una máquina remota. Diga IP 192.168.0.100 para mi equipo local y http://mycompany.com/webapi para el remoto.

Estoy usando flujo de Git como se describe en esta página web (ver http://nvie.com/posts/a-successful-git-branching-model/ )

Ahora, tan pronto como creo una twig de publicación, quiero cambiar de mi server local al server remoto.

La IP se almacena en una variable estática final pública. Eso significa que volver a aplicar una confirmación que lo cambie de mi IP local a la URL remota funcionaría.

¿Cuál sería la forma correcta de hacerlo? Tenía crear un alijo y aplicarlo en cada lanzamiento en mente, pero para alguien perezoso como yo que parece demasiado trabajo manual y demasiadas posibilidades de que las cosas salgan mal (como olvidar el alijo)

Esa dirección IP es configuration, no código, por lo que no debe estar codificada en su aplicación.

Un enfoque común, popularizado por The 12-Factor App y Heroku , es establecer la dirección IP utilizando una variable de entorno:

La configuration de una aplicación es todo lo que puede variar entre las implementaciones (puesta en escena, producción, entornos de desarrollador, etc.). Esto incluye:

  • Controles de resources a la database, Memcached y otros services de respaldo
  • Cnetworkingenciales para services externos como Amazon S3 o Twitter
  • Valores por deployment tales como el nombre de host canónico para la implementación

Las aplicaciones a veces almacenan la configuration como constantes en el código. Esto es una violación de doce factores, que requiere una separación estricta de la configuration del código . La configuration varía sustancialmente en implementaciones, el código no.

La aplicación de doce factores almacena las variables de entorno (a menudo acortadas a env vars o env ). Los vectores son fáciles de cambiar entre deployments sin cambiar ningún código; a diferencia de los files de configuration, hay pocas posibilidades de que sean registrados en el repository de código accidentalmente; y a diferencia de los files de configuration personalizados u otros mecanismos de configuration como las properties del sistema Java, son un estándar independiente del lenguaje y del sistema operativo.

Otro enfoque común (que 12-Factor explícitamente rechaza) es versionar un file de configuration de muestra como config.ini.sample pero requiere que los usuarios copien esto en un file .gitignore y no .gitignore como config.ini que la aplicación realmente usa. Esto le permite cambiar la configuration por installation al modificar un file que a Git no le importa.

Es difícil darle una respuesta más específica sin información sobre el idioma y la stack que está utilizando. Algunos frameworks, por ejemplo, tienen esta idea cocida.