Should Git be used to store continuous integration builds?

Question

In an environment where multiple builds (release candidate packages) can be created daily but only one a month gets promoted to production, I think storing every build in Git would be wasteful but there should be a short term location that the last few builds are published.

I'm currently publishing these to a shared directory. I have see IVY used for this sort of binary publishing in the past. Git seems like overkill as it would bloat due to it's model of never delete anything.

Is there an agreed, standardized way of managing/publishing these transient build artifacts?

Answer 1

I would not store the build artifacts in git but instead look at sharing the build artifacts from either a Continuous Integration (CI) server or a dedicated artifact repository such as artifactory or nexus. In general I find it best to avoid large binaries in all SCM's as you cant diff them or make incremental updates so you will find your git repo grows rapidly as it stores a complete version of the binary on every change.

Most continuous integration tools (such as Jenkins) will have the ability to archive the last X build artifacts or all build artifacts made within the last month. They also have plugins which help support and automate the process of promoting builds which you mat find helpful (i.e. Jenkins build promotion).

By using an artifact repository or the CI server to manage the build artifacts you can also usually access the artifacts via an API which comes in very useful when you want to automate deployment processes for example you can make calls like 'getLastSuccesfullBuild' and 'getLastPromotedBuild()' etc.