3

I've been thinking lately about how I handle config changes between multiple developers on a project.

Specifically here about a Laravel project in PHP, but I guess this applies largely to all frameworks/languages.

In general would you say it's a best practice to not commit your configuration? If so what's your practice for doing this with version control such as git?

Or do you set up each configuration as a different environment config? E.g. In Laravel there are environment configs, so each developer has a directory of just their own different settings, and this is what I'm currently using. Then in the code you can set how Laravel will detect which environment it's on. This works, I'm just wondering what other developers working on projects with other developers do.

migrated from stackoverflow.com Dec 13 '13 at 6:23

This question came from our site for professional and enthusiast programmers.

  • 2
    Have all your developers working on a common environment (vagrant and virtualbox is pretty good for this) so that the configuration is the same for them all – Mark Baker Nov 29 '13 at 12:02
  • Here each dev works on their local machine with their local db configs and pathing etc, they commit to svn then we have a staging test server which replicates the live environment which pulls the svn down every 60 seconds and uses a replica config of live. The only issue with this is that major config structure changes require you to change the config template both locally and live manually but I limit access to the master config templates to one individual so any screwups I know who did it. – Dave Nov 29 '13 at 12:09
  • @MarkBaker Thanks, i've seen Vagrant but not looked into it much before, i'll check it out now. – stilliard Nov 29 '13 at 15:20
  • @Dave Thanks, I like the added use of the stage server here pulling the latest code, i will probably setup something similar but maybe use a git hook to push it down from the central repo on new commits. – stilliard Nov 29 '13 at 15:23
  • @Andrew yeah a git push would work just fine. you may want to look into open shift origin tbh its the platform I'm considering swapping to for staging and live with push hooks for git. – Dave Nov 29 '13 at 15:46
4

You're doing it right

The benefit is that you are actually testing the mechanisms which will be used when deploying to other environments; test, staging, production, etc. Each developer will be automatically verifying that environment specific configuration is working.

I have tried the template approach and not checking in each developers configuration. This works but you will find from time to time something breaks for everyone.

2

Laravel has magnificent built-in support for this. You can set-up a different environment for every developer's computer. Check out the following page for a detailed explanation: http://laravel.com/docs/configuration#environment-configuration

You can find out what your hostname (in Laravel documentation refered to as "your-machine-name") is by running echo gethostname(); using an empty PHP file.

On our projects we have set-up environments like 'john', 'peter', 'etc'. This assumes that developers do not switch between computers.

  • Hi Ronald, this is currently how I'm doing this too, great to know this is how others using Laravel do this. – stilliard Nov 29 '13 at 15:25
  • You should most certainly not be using a different configuration for every dev. Developers should receive something like a machine image or Container that contains the runtime environment configured for development. There should be automated tools that take the source code devs write and place it in the container in an automated fashion that mimics automated deployment similar to integration, staging, and production environments. Otherwise you will eventually be bitten by the "it works on my machine" complaints as developers start hacking up their configs and playing Sys admin. – RibaldEddie Jan 10 '14 at 2:14
0

There is no simple answer to this one, the trick I used (when writing php)was that if the project was in development mode it would look for an external config file at a certain place outside the environment. Just as a good measure a standard copy of this file was inside the environment so that when getting the source files, you would get a standard dev deployment. Other configs could be placed in the file outside

That way if new configs where added everybody would know about them from the standard file and could alter their files as needed. Also no git issue or risk of bad commits.

I am sure that there are better ways to do this, but it worked back then with 20 devs working on the same projects.

  • Hi Icornea, thanks, i like that with your technique the configs are not commited into the central repo. I was thinking of doing something similar to this in another project, by adding a directory inside the config directory for overrides, (still in the main repo though, but git ignored) and then having the app detect files in here and use them to override settings in the main config. – stilliard Nov 29 '13 at 15:33
0

Set up a different sub-domain with its own folder for every developers own dev branch. Run that on your dev server which should replicate your prod environment as much as possible (OS etc).

Have your developers map a network drive (or use FTP, that's not ideal though) and use that to access their code base.

Now create a config sub-folder for each developer environment where you keep the few specific variables. Keep the rest in a general config file used by everyone. Load the specific config file depending on the sub-domain. Default to the production one if no sub-domain is set.

Likely you will need to write a few lines of code to map the right config.

  • Hi Patrick, i like the idea, i think minus the remote/ftp side to this, this is very similar to what i do currently, i keep a config directory with a sub directory in for each dev and inside that are the config files with just the specific changes for that dev, except that im assuming you keep your sub directories for each developers config outside of the central repo? As with my app its inside. For a workflow that requires developers to work via the server this is great though. – stilliard Nov 29 '13 at 15:39
  • No the config folders are inside the git repo. Otherwise if you need to add something in the future (that is different depending on the environment) you will have to go around and tell everyone to change his config. By having it in the repo you can change it in everyone's folder (still cumbersome but better than the alternative). Now that I think about it, it might be better to split the configs up even more so that things shared in the dev environments have a common config and then you have another config file for each developer. – Patrick Nov 29 '13 at 15:47
0

Use dist versions of your config files and add original config file names to .gitignore (e.g. config_prod.ini.dist is under version control and used as template for config_prod.ini which is in .gitignore)

  • No. Don't do this either if you can avoid it. Instead have a separate repository that contains configuration and use an automated tool to marry the code and its configuration at deployment time with your automated deployment tools. You are doing automated deployment, RIGHT? – RibaldEddie Jan 10 '14 at 2:26
0

Configuration of an application is a different responsibility than the application itself. Don't mix the two. The concept of an environment or environment variable is a variable that is be referred to with a single name but have different values depending on the environment, hence the name "environment variable". Your application should never, ever have to check which environment it's actually running in, it should always rely on the variables being set outside of it to have the correct value for a particular environment. In short, if your code has to actively check which environment it's on, you're doing it wrong.

Store environment configuration outside of the code source, in a separate repository. That way you won't be inclined to take shortcuts and mix the two.

  • I do like the idea of keeping the configuration separate, but how would you handle things such as connecting to a database where the local database name and password are different to those on the production server, or different per server? – stilliard Dec 13 '13 at 13:02
  • I'm very confused. Do you not know what a variable is? – RibaldEddie Dec 13 '13 at 17:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.