3

I am doing a Laravel 4 project, and there is an option on mail.pjp, where you can pretend to send an email, but you actually are logging it locally into a file. This is useful for development.

The problem I have is with version control. If I check in, this option as "true", then I risk that when I update the production server, it might disable emails if I am not careful.

On the other hand, if I check in the file in git as "true", it might happen what happened today, that I lost a good couple of hours trying to understand why the mail was not working because I forgot I had to change this option for my development environment.

What way could I handle these "production vs development" configuration issues with git?

Enrique Moreno Tent
  • 24,127
  • 34
  • 104
  • 189
  • 2 questions: does your configuration file change over time? What's your deployment process? – Benjamin Toueg Jun 25 '14 at 14:51
  • Well, if my configuration file will change on the future, is something that I can not foresee at this point. My deployment process is quite basic. I just it `git pull origin master` on the server. – Enrique Moreno Tent Jun 25 '14 at 15:28
  • Possible duplicate [Git: application configuration and different environments](http://stackoverflow.com/q/3214016/456814). –  Jun 25 '14 at 17:22
  • Possible duplicate of [How to use git to manage one codebase but have different environments](http://stackoverflow.com/q/2964120/456814). –  Jun 25 '14 at 17:25
  • Possible duplicate of [How can I track system-specific config files in a repo/project?](http://stackoverflow.com/q/2154948/456814). –  Jun 25 '14 at 17:25
  • Possibly helpful: [How do I open source my Rails' apps without giving away the app's secret keys and credentials](http://stackoverflow.com/q/3207575/456814). –  Jun 25 '14 at 17:26
  • One way Ruby on Rails applications deal with this is to store environment specific configurations in an unversioned file for each environment, and load them into environment varibles using [Foreman](http://ddollar.github.io/foreman/). –  Jun 25 '14 at 17:28

2 Answers2

2

Have a branch for each configuration.

For instance, you could have a production branch and a dev branch.

On the production branch, just make one commit to change the configuration file, then use the dev branch the same way you used your master branch.

The deployment process becomes

On dev:

  • git checkout production
  • git merge dev
  • git push origin production

On production:

  • git pull origin production

Or split your configuration file

And maybe add some runtime test to pick the good one at the right time.

Benjamin Toueg
  • 10,511
  • 7
  • 48
  • 79
1

I have a similar problem and use the following solution which might be a bit heavy but works well to separate 'private' data from a public project.

The idea is to not put your configuration file under your normal git repository but in an a private one. Ideally you would like the private repo to be a submodule of the public one, but you have to do it the other way (to hide the private repo from the public one).

For this, I create a private repo which contains my configuration file. then I create a submodule containing the public one and add a link to the configuration file.

The directory structure looks like :

private + (private git repo)
        |
        +- config.conf
        |
        +- public + (public git repo)
                  |
                  + config -> ../config.conf
                  |
                  + src

Then I have a devel and a production branch on the private repo with the two version of the configuration file. But I never really touch those directory.

When a new developper arrives he just forks the devel branch and the works inside the public as if there is no umbrella project. Just pull push as normal.

When you need to deploy just go on the production machine and update the public submodule. If you need to update the production configuration file, just update it on the production machine and push it. Alternatively you can switch locally to the production branch, make the necessary changes and push them to the production server.

Hope it's clear.

mb14
  • 22,276
  • 7
  • 60
  • 102