1

When merging development code into the production code, what is the preferred method for handling items that should not be in the production code branch? For example, I have configuration scripts that are configured for the test servers in the development branch, and I have the same scripts also configured for the production severs in the production branch. This causes conflicts when merging from dev to prod.

7

Solve the issue at deployment time.

As in, your production branch has all the dev configs and such. When you have a tool building and deploying your code, that re-configures your application to run in production. This avoids merge conflicts (your production configs aren't in the same file, the build tool overwrites it), and gives you a ton of control over where you actually keep those production configs.

Since many places want to keep the production configs safer than you keep the rest of their code - to help avoiding accidental breaks in production, to keep secrets safe, whatever. Solving this issue at deploy time helps, since it allows you to keep production configs in a more secure repo (maybe only leads have write-access to help prevent accidental breakage), or lets you keep secrets (keys) in an actual secure keystore, where the only allowed access is via the build tool.

|improve this answer|||||
  • You can always commit a distribution file, which is just a (renamed) configuration file with sensible defaults (usually for developers). That also helps secure your build scripts; if the distfile contains parameters your build tool doesn't supply, it should cause the build to fail. – Duroth Apr 2 '19 at 14:45

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