12

When doing continuous deployment with Git, how do you handle ignored files in gitignore? Those files are ignored for privacy reasons (i.e. don't want them pushed out to other remote repositories, like GitHub), but with those ignored files not being pushed to the continuous deployment repository, they application would not run (as the ignored files are required for the software to function correctly).

How do people typically go about this? In this case, is Git not the best candidate for continuous deployment due to ignored files?

Improve this question
3
  • 2
    I'm voting to close this question as off-topic because it does not show a minimum, basic research effort.
    – Scant Roger
    Nov 24, 2015 at 20:58
  • 3
    I'm not seeing a lack of research effort. The OP seems to understand what gitignore does perfectly well. What I do see is an XY problem, but because both X and Y are explained in the question, Doc was able to write a decent answer that hopefully solves the OP's real problem.
    – Ixrec
    Nov 24, 2015 at 23:32
  • 1
    @ScantRoger: honestly, the question could be written better, but it is far from beeing so bad that it deserves a close vote.
    – Doc Brown
    Nov 25, 2015 at 6:20

2 Answers 2

Reset to default
14

If your software does not run without those files, you will have a problem with any kind of deployment, manual, automatic or continuous, with any kind of VCS, or even without any VCS. So either change your software so that it can run actually without those files (for example, it could assume some kind of "default parameters" if the files are missing), or you provide some version of those file suitable for deployment which are copied (as part of the deployment step) to the destination environment in case there is no "private" version of those files in place.

If you are talking about something like a file containing database credentials to logon to the server, which, for security reasons, you do not want to be in version control, then you will have to put that file into the deployment environment once, probably manually, by a person which has enough rights or knows the password. But that is intentional and should not stop you from deploying daily new versions of your software. Just make sure a credentials files in place is not overwritten when you deploy a new version.

Improve this answer
2
  • Agreed, if checking out from vcs is not enough to build and run, albeit in a reduced capacity, then your source tree is incomplete.
    – Newtopian
    Nov 24, 2015 at 19:38
  • @Newtopian: note that this can be indeed intentional and correct (see my example).
    – Doc Brown
    Nov 24, 2015 at 19:55
2

Another option is to store the sensitive information inside of your deployment tool. And the deployment tool configuration in a separate private source repository.

Leaving the sensitive data on the target machine works, but might bit-rot - someone changes it not following procedures, the machine brakes and no one remembers the correct settings, etc...

Saltstack for example has https://docs.saltstack.com/en/latest/topics/pillar/index.html

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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