3 ms·
An example scenario might play out thusly: Fred checks in the production configuration credentials (lets say mysql configuration for this example) in a file cal
by philjackson 14y ago
An example scenario might play out thusly: Fred checks in the production configuration credentials (lets say mysql configuration for this example) in a file called passwords.php. Senior developer Bob Van Gogh checks out the project but needs to connect to his local mysql instance to develop. He edits the configuration file and hacks away on his feature. Somewhere along the way he accidentally commits passwords.php with his changes. Eventually his code is deployed and suddenly the app servers can't connect to the database. Bob's no good at football but he's a good developer and now thanks to that accident his reputation is tarnished beyond the football pitch too.
Configuration like that should be managed by something that isn't susceptible to these accidental changes.
As you mention it, security is an issue too. The fewer people who know the passwords to anything the better and the more you can keep the passwords from going over the wire the better.
- mostlystatic 14y agoCool, thanks for the explanation. I usually have the development config in the repo and the deployment script overwrites it on the server.
- prodigal_erik 14y agoThat's better than the converse (default is prod, yikes!) but there's a risk of a prod server using the dev config, which might appear to work unless your dev environment is firewalled off. I prefer having an invalid or unusable config checked in, so the system doesn't even come up until I deploy the config I intend to use over it.
- northernmonkey 14y agoI know Bob, he's a much better footballer than he is developer
- philjackson 14y agoIt's the cartwheels that set him apart.