¿Cómo puedo abrir mi código en git y mantener el deployment de scripts con los files de configuration adecuados?

Tengo una aplicación desarrollada en github. Quiero abrirlo. Actualmente usamos un script capistrano para implementar en nuestros serveres de producción y producción.

Estoy intentando descubrir cómo podemos poner nuestros files de configuration en un repository separado, y aún usar capistrano para ejecutar implementaciones de un solo toque. El objective es que podamos abrir nuestro repository para que cualquiera lo use.

Tienes algunas opciones.

  • Usar variables de entorno: puede establecer variables de entorno en las máquinas locales y de producción. En su aplicación, leerá estos valores haciendo: <%= ENV['my_var'] %> . Al hacer esto, puede enviar su aplicación a un repository público sin preocuparse de exponer información confidencial como passwords y keys. Por ejemplo, establezca un entorno var db_password para almacenar la contraseña de su database y en su database.yml podría leerlo haciendo: password: <%= ENV['db_password'] %>

  • Puede usar gems link dotenv ( https://github.com/bkeepers/dotenv ) o figaro ( https://github.com/laserlemon/figaro ): al usar estas gems no necesitará establecer variables de entorno manualmente en sus máquinas, las definirá en un file .env. Podrás leerlos de la misma manera usando <%= ENV['my_var'] %> . Deberá ignorar sus files .env en su .gitignore y decirle a capistrano que cree las variables de entorno en su server de producción leyendo desde su file .env.

  • Otra alternativa sería crear diferentes files de configuration para el desarrollo y la producción e ignorarlos en su .gitignore. Puede almacenar sus files de configuration de producción en un repository diferente y tenerlos actualizados en su máquina en el momento de su implementación. Solo tendrá que copyr los files de configuration de su máquina local al server de producción ( https://coderwall.com/p/wgs6gw/copy-local-files-to-remote-server-using-capistrano-3 ) después de actualizar el repository de la aplicación en su server de producción.

La última alternativa es la que uso más (en mi caso uso ansible en lugar de capistrano).

Si quiere ver un ejemplo, tengo una aplicación y una tarea de implementación que se están ejecutando en producción y que puede realizar:

Espero haber sido claro y entendiste la idea.