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?

Adolf

Why would you store the artifact? Builds can be recreated. – Oxendine

(I mean in git, anyway. Don't most CI servers keep the builds around for a configurable amount of time anyway?) – Oxendine

Builds can be re-created but build environments sometimes cannot. Unles you keep your entire tool-chain under revision control there is no certainty that you can build the same binary after a large amount of time has elapsed. Additionally, it's impossible to build exactly the same binary (embedded timestamps result in different file checksums). This makes it difficult for 3rd parties to trust or certify your software unless they too build it from source. – Shipwright

Yes using the CI server is an option. I kind of see this as the same as using a directory. I guess we'd have the added benefit of cleaning up the transient builds automatically after a set interval. Mmmm. – Adolf

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.

Angadresma

+1 Repository managers like Nexus, Artifactory or Archiva, are designed to solve this problem. Check out their features. We using Nexus professional which enables us to "stage" our releases and create certification workflows, where DEV create the build artifacts, which are subsequently approved by Test and QA before hitting the production repository. – Shipwright