0

Regardless of the build/deploy process one is using, is there a way to show from which branch the latest deploy was launched with git?

I realise that deploying and git are unrelated, so I am not after a single command.

To illustrate what I mean, imagine you're jumping on a project you haven't worked on before and you're not sure which branch was deployed. Wouldn't it be sweet to find out just with a series of git commands?

U r s u s
  • 6,680
  • 12
  • 50
  • 88
  • You could at the very least tell us what your deployments look like. – PeeHaa Jun 10 '16 at 09:23
  • @PeeHaa I am after a general command, _Regardless of the build/deploy process one is using_ – U r s u s Jun 10 '16 at 09:28
  • 4
    Build and deploy processes are entirely unrelated to git, so no git won't tell you this. However a good build process is probably tagging your builds, so `git describe` can [tell you the latest tag in a given branch](http://stackoverflow.com/questions/1404796/how-to-get-the-latest-tag-name-in-current-branch-in-git). Maybe this is a good start? – cmbuckley Jun 10 '16 at 09:28
  • aha, thanks @cmbuckley that's helpful. Care to put that in an answer? – U r s u s Jun 10 '16 at 09:31

1 Answers1

1

This isn't possible if you want to truly assume nothing about the build process, as that means you can't assume that the build process makes any record of anything back into your version control system (e.g. you could have a deploy process that simply issues a git pull on a box somewhere).

If you make an assumption that your build process is building from a given branch (e.g. master), and tagging the branch every time it makes a build, then git describe master will tell you the latest tag in the master branch.

In this case, this may only tell you about the latest build, not the latest deployment. In this sense the tags are release candidates, and you'd have to make more assumptions in order to find the latest deployment.

We use the following strategy:

M─┐ [v2] [release] Merge branch 'feature-Y' into release
│ o [feature-Y] Commit F
│ o Commit E
│ o Commit D
M─┤ [v1] [master] Merge branch 'feature-X' into release
│ o [feature-X] Commit C
│ o Commit B
│ o Commit A
I─┘ Initial commit

This tells you a few things:

  • We only maintain one version of this application.
  • master points at the current production version. (So v1 is currently live.)
  • Commits are made in feature branches and merged into release when ready.
  • Here, the new feature-Y is our release candidate, which has been build and tagged as v2 by our build process.
  • This is deployed to a pre-production environment for testing.
  • Once testing is complete, the build is promoted to live.
  • Once everyone is happy that it's working in live, master is fast-forwarded to release (git push origin release:master) and now v2 is live.
  • Repeat!

If at any point the release candidate fails testing, the release branch is thrown away and rewound back to master (git push -f origin master:release), so feature-Y is no longer part of the mainline. However, v2 still exists in git for posterity.

cmbuckley
  • 40,217
  • 9
  • 77
  • 91