I often struggle with the idea of deploying applications in productive, dev and test environments (not unit testing, I mean like a sandbox) when it comes to databases.

And no, source control is not an option. Three main reasons: 1) I don't necessarily want developers to look at sensitive information (like passwords, credit cards, etc.), 2) databases get big, too big for a DVCS like git or Mercurial, 3) I want to keep traceability between code and database dumps.

Lately I have been using Artifactory, and I have found it quite useful in several workflows. Artifactory is an artifact/dependency repository, which is different from a version control repository in that it is meant for managing large files/assets, and can be used with dependency management tools.

It crossed my mind that —instead of hoarding database backups in a file server where I cannot quite track such files in a way that they are supposed to go together (i.e. configuration management)— I could very well use Artifactory (or any other build artifact / dependency management set of tools) and simplify deployment automation while avoiding the quagmire of setting up a backup management solution.

So, is this concept/use case ill-conceived?, or is this actually done in practice? (because I could not find this being done anywhere)

  • 1
    I'm not sure what your problem is, exactly. What is it that you want these backups for? What do you do with them? – JDT Feb 29 '16 at 12:23
  • Are you suggesting using Artifactory in a way it was not intended? – JeffO Feb 29 '16 at 18:13
  • Is the use case more about handling the data contained in the database as a dependency of the consuming code, or the schema used by the database for supporting the consuming code? – Castaglia Apr 5 '16 at 18:44

Your Answer

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

Browse other questions tagged or ask your own question.