Of course, we tag the MANIFEST of all jars with the git commit. We actually go a bit farther and print out all dependency git SHA1s during the build process, so you only have to refer to the jenkins build log to do a bisect and not dig through jars.
I describe how we did that here: http://liveramp.com/engineering/identifying-maven-snapshot-artifacts-by-git-revision/ On Thu, May 5, 2016 at 6:32 PM, Barrie Treloar <[email protected]> wrote: > On 6 May 2016 at 09:48, Ben Podgursky <[email protected]> wrote: > > > I see these discussions often, and I wanted to jump in and mention how we > > handle continuous deploys, because I feel that it avoids many of the > > downsides mentioned here, albeit with some (IMO) minor costs: > > > > - all of our internal dependencies are SNAPSHOT. we do not do releases, > > ever, or ever depend on a fixed version > > > > - we attach to the package phase of our builds an assembly which packages > > the artifact and all of the dependencies it tested against into a tar.gz > > > > - we deploy the tar.gz to our artifact server with a snapshot version > (ex, > > MY_PROJECT-1.0-deploy.tar.gz) > > > > - when deploying we simply take the last snapshot deploy artifact and > unzip > > it in production (+ some config files etc). > > > > so while you use SNAPSHOT versions, you are guaranteed that you are > > deploying against tested dependencies. and you never have to commit > > updated dependency versions, do releases, etc. the only real cost is a > bit > > of artifact server disk space… but disk space is incredibly cheap. > > > You left out tagging the source code in the built jars. > > How are you supposed to pull up the code in production? > Or git bisect, or diff between versions to track down when a defect was > introduced? >
