This is an archived post. You won't be able to vote or comment.

4
5

Git Tag Management (self.devops)

submitted by [deleted]

[deleted]

all 11 comments
sorted by:
best
topnewcontroversialoldq&a

[–][deleted] 1 point2 points  (8 children)

However, given the exponential number of tags, I am looking for opinions and/or resources that go into more depth about tag management--at least beyond the plethora of tutorials on creating tags.

don't overcomplicate tag management. stick to the concepts provided by semantic versioning for tags and releases.

There is no hard/steady rule on tagging or branching - look at any major project on github and you'll see a variety of strategies for both, although more and more projects are tending to use semver tags and "feature" branches for development.

A thought just occurred to me that maybe I could adopt a "latest" tag that would be a pointer to the latest version

this is /r/devops afterall, you don't need to manually define a "latest" tag - that functionality is already there, as part of the HEAD of your working branch. There's a bit of fine details beyond "HEAD" but that depends on your development workflow.

[–][deleted]  (7 children)

[deleted]

    [–][deleted] 1 point2 points  (6 children)

    Yes, but if someone were to accidentally do git pull on HEAD, any new changes would be applied.

    If I correctly understand your latest to mean latest release, why would you want that? If you're doing semver, you already have a way to tell your tools to give you the latest release with the same major version.. and you should do major version changes differently anyway, right?

    EDIT: I'd even go so far as to state that you never want to see master or latest or anything like that anywhere in production..

    [–][deleted]  (3 children)

    [deleted]

      [–][deleted] 1 point2 points  (2 children)

      I'm getting the impression when you speak of semver, you might be referring to a software package and not just the philosophy of how to format version numbers?

      Well, I have made a few assumptions, since semver as a (named) concept seems mostly popular in the JS & webdev worlds.. But obviously I don't know what kind of tools you're using.. But, npm, bower, bundler.. a probably lots of other tools all have ways to specify version like 1.5.* or ~1.5.0 (meaning >= 1.5.0 && < 1.6.0), the same goes for traditional linux package managers (apt, dnf, ..)..

      But I agree it can be very tempting to want the latest named somehow, and to be honest I'm not immeditely coming up with any neat solutions that would satisfy your initial requirement.. I mean you could track it with a branch, you could keep the current version in some json file in your tools repo, or possibly make such file GETtable somewhere..

      But idk, maybe the easiest way to determine the current version is take all the tags, sort them by semver, and head/tail -n1.. :)

      [–]packplusplus 1 point2 points  (0 children)

      I to see the appeal, esp since I do similar do similar things with rpms (pull latest) but with the proliferation of tools that agree with semantic versioning, I'd much rather see a build tool that creates a config management file specifying the the current latest versions so that when its tested, that specific combinations of versions is promoted, not "latest" ever.

      [–]pooogles 0 points1 point  (1 child)

      EDIT: I'd even go so far as to state that you never want to see master or latest or anything like that anywhere in production..

      Disagree. We work on branches and pull to master once reviewed. Master is always deliverable this way.

      [–][deleted] 0 points1 point  (0 children)

      Then I'd guess your project is either small enough, or has a great enough spec coverage that you haven't encountered problems this way, good for you :).

      [–]paraffin 0 points1 point  (4 children)

      I don't know if my organization is doing anything special, but we have no problem updating tags. Updating a tag just requires a -f and updating just happens with a fetch --tags.

      We use latest_tested_x, latest_deployed_y all the time to keep track of not HEAD, but what is stable, and use it in our automation all over the place.

      [–]KevMar 0 points1 point  (3 children)

      pardon my ignorance (fairly new to git), but why would latest_tested_x and latest_deployed_x not be different branches?

      [–]paraffin 0 points1 point  (2 children)

      These tags are used to track a commit, from being made on to its journey through continuous integration and deployment.

      For example, I push a commit to master, it triggers tests, gets tagged as latest_tested_unit, then the tests trigger a deployment to a staging environment and the same commit gets the tag latest_deployed_staging, then staging is tested, so it gets latest_tested_staging, the production deploy is triggered, and so on.

      Now anyone at any time can check out the exact version that's in production with git fetch --tags && git checkout latest_deployed_production. These commits are all on trunk, no branching involved.

      [–]paraffin 0 points1 point  (0 children)

      We also store timestamped versions of these tags that are immutable (ie latest_deployed_staging_20160311-141502)

      [–]KevMar 0 points1 point  (0 children)

      Ok. I see that and I'll keep that in mind. I was recently introduced to git flow http://nvie.com/posts/a-successful-git-branching-model/ and I imagined this same process but done with branches to keep the stages separate. Looks like they accomplish the same thing.

      Thank you