5

When your creating a project that has some sort of information that needs to be private (authentication details, etc), but you want to use some public repo like Github, are there anything that can be done to keep these things private?

All I can really think of is ignore the file that has this data in it, but then if you need to change anything, it needs changing everywhere that it's checked out, making the VCS pointless. Same issue with reverts etc.

Or is this something that cannot really be avoided easily when using a public repo?

TMH
  • 248
  • 1
  • 7
  • Ignoring config files is standard, even with private repositories. They should be simple enough that not versioning them isn't a big issue. Also different deployments (e.g. production, testing, development) will typically use different configurations, with production rarely sharing authentication details with the other environments. – CodesInChaos Sep 24 '15 at 09:08
  • I must say I've only had very limited experience with config files in projects. Most things I've done have been really small and not needed them. I didn't realise this was a standard to just ignore the file. Honestly, the project I'm working on that lead me to this question will only ever be worked on from one workstation, but I just wondered how other people deal with it. – TMH Sep 24 '15 at 09:15

1 Answers1

6

There are a couple of different ways to deal with this problem. It all depends on your personal preference.

Don't commit any configuration files

This is probably the easiest, although you have to make sure you never accidentally commit anything with configuration information in it. With git, once it has been committed and pushed out or forked it's practically impossible to remove it. If you ever leaked anything in a configuration file that was pushed, consider that information compromised.

Major disadvantage here is that you have to maintain some kind of documentation on the structure and entries you need in the configuration file. Deploying the application means creating a configuration file for your environment. A new version that adds a configuration option will need some kind of documentation on the deployment process for the new version to make sure this option is set.

Commit a sandbox-file

A lot of projects favor an approach where you can check out, build and run an application without the need to do any configuration. You can achieve this by providing a default configuration file. For your database, this file could just point to a localhost database-server with 'myproject_user' as username and 'myproject_password' as password for the 'myproject_db'. This has the advantage of providing a default configuration file with all options present AND is part of the code because it runs with the application, unlike your documentation.

Downside is that in this case people checking out your application have to set up their environment to match this, or still change the configuration settings. Does not fix the issue with having to remember to set configuration values on deployment either.

Provide a parameters.dist-file that is checked at deploy-time

Frameworks such as Symfony actually version configuration files by having a parameters.yml.dist-file. (see http://symfony.com/doc/current/best_practices/configuration.html). This is a template file that simply contains the structure of the config file, without any values, and during deployment compares the existing parameters.yml-file to the parameters.yml.dist-file that is deployed. Obsolete entries are dropped and new entries that need a value prompt to the person deploying the app for a value.

This is a solid approach for big applications and frameworks that will be used in other applications or by external parties, but might be overkill for smaller applications where deployment is often a simple copy/past or FTP upload and you can follow a deployment-document that outlines what entries you need to change.

JDT
  • 6,302
  • 17
  • 32
  • I think for my project the last point (about Symfony) is a bit out of scope (but I will look into how it works as it sounds interesting :)), but I really like the sound of the sandbox, and I think I'll use something like that. Thanks for the ideas! – TMH Sep 24 '15 at 09:35