CODEWITHSUNDEEP
gitserver
vinntec
vinntec

Reputation: 495

Protecting git deployment-specific files

this is a very general question about git - think of a server application for the example below.

The context: Suppose you have a few branches in your repo, among which 'staging' and 'deploy'. To develop the application, you use a private machine with a specific development configuration file. Your app is about to be deployed on a public machine. However the public machine requires a different configuration file (e.g. it has to access a specific database or so).

The problem: If I commit my config file in 'staging', do some changes, and then merge into 'deploy', it will overwrite my deployment config file, and this would be incorrect. If I don't track my configuration files, I could lose them at any point.

The question: How can I protect both files in both branches, so that neither is lost at any point? How can I assign these files to the branches they are owned by? Is there a way to do this all transparently, so that I can just use git's usual mechanisms without having to think about these files?

Thanks!

Upvotes: 2

Views: 405

Answers (1)

nwinkler
nwinkler

Reputation: 54507

Branches are not the right way for this in my experience. Try to separate development and deployment into separate repositories. Your application repo should not contain the configuration files used for a production deployment. A default configuration that can be used for a local deployment is usually fine to have.

Anything else should be kept outside of the source code repo for the following reasons:

  • Branching/merging concerns that you mentioned above.
  • You don't know which servers your application will be deployed to in all cases. In many organizations, the deployment and operation of the runtime/production environment will be handled by a different team - they know best which servers your app will run on, and you don't need to have this information in your source code repo.

If you still want to keep track of configurations (which is a good idea in general), either

  • Create a separate configuration repo and use the naming approach described in the comment above (file-uat.config, file-production.config) - you could also use directories in the same repo, so one directory holding all of the uat files, one all of the production files, etc. Or
  • Create a separate repo per deployment environment, e.g. myapp-config-uat, myapp-config-production.

Either of these approaches should work well with a scripting solution that will automate cloning/updating the configuration files into the environments in question.

Upvotes: 3

Related Questions