4

Currently, I am trying to set up deployment procedures and GIT for a group of websites. Code and assets are between 15 and 20GB. The code and related text files are probably closer to 150MB.

When deploying code from the developer machine, to a server, or from a server to another server. What are the common solutions used for managing non-source code assets such as images and PDFs?

There will be a continuous integration server, for sure. However, I don't know how storage and versioning is reliably handled without setting up a separate version control system.

Robert Harvey
  • 198,589
  • 55
  • 464
  • 673
nobrandheroes
  • 211
  • 2
  • 8

1 Answers1

2

I think this varies from project to project. Generally the advise by Bart is a valid one. If these assets are directly connected to the source-code and managed by the developer (best example are images statically linked/embedded in a template) it's a good practice to have them inside the repo.

If this isn't the case, we have to ask some other questions. The key questions here are IMHO:

  • Do you have any benefit from this assets being managed by version control?
  • Are this assets managed by yourself or by someone or something external (application internal uploader)?
  • If the assets are managed inside of your application, doesn't that have some kind of version control for assets by itself?
  • Is there even a need to actively sync assets from one environment to another? Isn't it easier to have them separate on each environment and rsync them from live to staging/local when really needed? (This depends on how the assets are connected to your application.)
  • Are there any disadvantages from having the assets in version control (for example constantly having conflicts in the different environments local vs. stage vs. live)?

As you are stating a size of 15-20G in your question I would personally assume it doesn't really makes sense to keep these assets in version control at all. Keeping it inside the backup should be enough in almost any case I can imagine, as long as there are no special requirements in your project which we don't know of.

Also keep in mind that you will be forced to download the whole history (read: any file that ever existed) on the initial checkout of that repo. If we assume you could somehow manage to add the 15-20G to that repo now and you have a turnover of 500MB every month the repo will be 27-32G in two years, which will be a major pain for everyone who has to work with it and will in the end force you to get rid of a part of the repo history anyway. ;-)

s1lv3r
  • 171
  • 2
  • 5
  • 1
    In our particular case, the assets do need to be synced across the various stages of deployment. RSync had occurred to me, and it may be ideal, but I was hoping for something easier for our less server friendly devs. – nobrandheroes Dec 05 '14 at 16:02