Stored reference files in scm for builds
Brian DiCola (293●1●14●15)
| asked Oct 29 '13, 7:57 p.m.
retagged Dec 16 '13, 4:12 p.m. by David Lafreniere (4.8k●7)
I have seen this question come up a couple of times. A build script requires a reference to a set of libraries. They could be considered 3rd party or they are sometimes called simply "the reference files". A couple examples are JBoss EAP runtime or the WebSphere Message Broker runtime. In these cases the files are only maintained (updated) as per the vendor's patch or upgrade schedule. The developers on the project team don't generally edit these files except for the rare config change, which is usually environment specific or the application of licenses. The number of files is inevitably huge. The number of bytes on disk could be 0.5 GB to several GB. Most of the time these are binary files that no one would ever peak into.
So what should the team do? Where should they be kept. I've seen these 3 options suggested.
1) Deliver them to their own component within the stream of code that needs them for builds
2) Store them on the build server's local file system
3) Store them on the target server and pull them in with each build
I usually implement #1 or #2, but #1 usually fails to be useful in the all too critical role-back scenario.
In my mind, putting "CM" on top of these files does not necessarily mean having to deliver them to any SCM, as long as patches and upgrades are managed with work items such as change requests etc. But I've been in the minority in such debates. So I'll ask it here.
What is your approach to CM of reference files?
Much thanks in advance.
|
Accepted answer
use an artifact library (dependency) mgmt system, like Maven or Artifactory.
I am in favor of the Artifactory solution (this is where build outputs should go too), and you can put Maven over that if you need to. do NOT store the binaries in the source control system. they WILL cause you problems eventually. (we had them since the beginning, someone storing all of the Oracle db install into the scm, and it was dragged out for every build!..) Brian DiCola selected this answer as the correct answer
|
One other answer
Maven repository management has this scenario pretty well covered.
|
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.