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.
1
-
Almost the same problem from a different angle: softwareengineering.stackexchange.com/questions/386842/…– Doc BrownApr 2, 2019 at 18:35
Add a comment
|
1 Answer
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.
-
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.– DurothApr 2, 2019 at 14:45