Question - Git flow commands for the "release packages" approach to Octopus Deploy?

[sstorie]

I'm sorry if this is a real newbie question, but I'm just getting into GitFlow and trying to use GitVersion to manage builds with TeamCity and deployments through OctopusDeploy. I've got the TeamCity config working, and I'm producing files and NuGet packages with the appropriate versions. But I'm confused on how exactly to execute the process described here:

https://gitversion.readthedocs.org/en/latest/more-info/build-server-setup/octopus-deploy/

In this process, does the term "release" mean one of the refs/head/release/* branches? Or would you manually push the latest master build into the Octopus pipeline and have it flow through? Once you push, is there something outside of gitflow you need to run to tag commits correctly in this approach?

In my case I just have a staging and production environment, and the chance of having multiple pending releases is pretty small. I was thinking I could use a single release branch to push -beta000X packages to my test environment, and then have the master builds get pushed to the production environment as release packages (i.e., they're not -beta000X). I'm just not very clear on what the sequence of commands would be to tag things appropriately.

[sstorie]

I think I may have figured this out through some trial and error, but I would appreciate any comments if this is still a bit misguided.

In my case I was creating a new release: 1.2.0. Using git flow this was simple to do:

git flow release start 1.2.0

Then I pushed this into my test environment using Octopus, where it had a Semver of 1.2.0-beta.1+0 and a Nuget version of 1.2.0-beta0001. So I made a series of changes which caused the meta data value to increase 1.2.0-beta.1+1, 1.2.0-beta.1+2, etc...but the Nuget version remained the same (as indicated by the docs).

What I found was required to push these updates to the test environment was to tag this release branch using the current semver like so:

git tag 1.2.0-beta.2

This provided GitVersion with the info it needed to roll into the next beta version - 1.2.0-beta.2, and a new nuget version of 1.2.0-beta0002. Going forward then I can continue to tag with new beta versions as needed to push fixes to the test environment until it's ready to be released.

Is this the right way to approach this?

[JakeGinnivan]

Yep exactly, when you push the nuget package into the feed which octopus deploy is listening to you need to tag your git repo. This will cause the next build to increment.

I meant to reply to this earlier today but had a busy day with work.

[JakeGinnivan]

And to directly answer your first question. release means taking one of the built CI packages, then making it available to the release pipeline.

This means you have multiple candidate builds, but only one which gets released into the release pipeline

[sstorie]

Ok, thanks. I really appreciate the comments and helping me get this clear in my mind.

[JakeGinnivan]

If the docs can be more clear let me know, or submit a pull request :)

Sent from my Windows Phone

---

From: sstoriemailto:notifications@github.com
Sent: ‎18/‎08/‎2015 6:42 PM
To: GitTools/GitVersionmailto:GitVersion@noreply.github.com
Cc: Jake Ginnivanmailto:jake@ginnivan.net
Subject: Re: [GitVersion] Question - Git flow commands for the "release packages" approach to Octopus Deploy? (#583)

Ok, thanks. I really appreciate the comments and helping me get this clear in my mind.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/583#issuecomment-132165882.

[sstorie]

Ok, let me refine my steps into something more coherent and I'll submit a PR.

[sstorie]

PR created - #585

Thanks again for the help! Let me know if any changes to the PR are needed, or if I incorrectly captured the process. I repeated it a few times myself to ensure I understand it, but am still learning here.

[JakeGinnivan]

Thanks a heap @sstorie

Changes look great