search

RadicalFx / housekeeping

This repository is intended to keep track and manage all what is not code-related. Requirements and Pre-Requirements discussions should be handled here too.
https://waffle.io/radicalfx/housekeeping
0 stars 1 forks source link

Introduce GitVersion to simplify the release process #35

Closed mauroservienti closed 8 years ago

mauroservienti commented 8 years ago

Currently, IMO, the release process is a bit too complicated. The user need to manually bump the version number, not expected. Then we need to remember to release in production bumping again the version number in another place on a different branch. Once a thing is merged into develop we have no standard way to keep track that it needs to be released. Other than this we have master and develop that tend to complicate things.

What if:

micdenny commented 8 years ago

I like the idea to move in one branch only, so when we tag pre-release it goes on myget, instead if we tag a stable one goes to nuget. If we need to hotfix the last stable and we already have pushed changes? We create a branch from the last stable tag, apply the fix, push from that branch to nuget then merge back on master?

mauroservienti commented 8 years ago

I like the idea to move in one branch only, so when we tag pre-release it goes on myget, instead if we tag a stable one goes to nuget.

And I think we can automate this process, it GitVersion creates an unstable release we can deploy to MyGet otherwise to Nuget.

If we need to hotfix the last stable and we already have pushed changes? We create a branch from the last stable tag, apply the fix, push from that branch to nuget then merge back on master?

Exactly, we branch from the tag we want to fix and release, finally we rebase on top of the HEAD

mauroservienti commented 8 years ago

I'll spike this approach using one of the containers repo.

micdenny commented 8 years ago

:+1:

mauroservienti commented 8 years ago

@micdenny I'm trying to setup the thing on the radical.windows.presentation.castlewindsor repo, there is a test-github-flow branch. The thing is that the build is failing due to the fact that MSBuild complains that some references seems to be missing, by they are indeed there.

Any idea?

Build log: https://ci.appveyor.com/project/radical-bot/radical-windows-presentation-castlewindsor

micdenny commented 8 years ago

sometimes I saw similar problems but was related to the new nuget v3 restoring process that fails, this seems to be a different problem, I saw really strange things like:

The target "_ConvertPdbFiles" listed in a BeforeTargets attribute at "C:\Program Files (x86)\MSBuild\12.0\Microsoft.Common.targets\ImportAfter\Xamarin.Common.targets (34,37)" does not exist in the project, and will be ignored

xamarin?! ehm, what?! ahhhhhhhhh :smile:

is that something related to gitversion?

mauroservienti commented 8 years ago

never seen that, and they don't exist locally in the build log. I suspect that it's AppVeyor that is adding the targets since now they support building Xamarin projects as well.

micdenny commented 8 years ago

I see... I don't have ideas at the moment, try to rebuild a couple of times to see if it's a nuget restoring issue

mauroservienti commented 8 years ago

We are actually using V2 Nuget feeds, should I try to move to V3?

MSBuild auto-detection: using msbuild version '14.0' from 'C:\Program Files (x86)\MSBuild\14.0\bin'.
Feeds used:
  C:\Users\appveyor\AppData\Local\NuGet\Cache
  https://www.nuget.org/api/v2/
  https://www.myget.org/F/radical-unstable/api/v

try to rebuild a couple of times to see if it's a nuget restoring issue

yes, no rush

micdenny commented 8 years ago

we could try, but when I saw the error I don't remember if the problem was related on using nuget.exe v3, or because I was pointing v3 feed instead of v2

mauroservienti commented 8 years ago

Vediamo che succede, non ne vengo fuori http://help.appveyor.com/discussions/problems/4231-could-not-locate-the-assembly-during-build

mauroservienti commented 8 years ago

The above will also allow to easily move from master/develop to a single master branch.

Not really true. I dive into the issue and asked around for help. Basically GitHub Flow works really well for a product but not for a framework where we may found ourselves in need of patching an old release, in this case GitFlow is the way to go, using support- and release- branches.

mauroservienti commented 8 years ago

Once done we can also drop the Radical.Build repo

mauroservienti commented 8 years ago

Removed the portion of the title related to GitFlow since we now we cannot.

micdenny commented 8 years ago

@mauroservienti and I discussed the workflow using GitVersion and this is a recap:

There are names of branch that have a particular meaning and that are theoretically reserved to make it clear to GitVersion what we're doing, these are: hotfix- support- release- every other PR started from a branch with a name other than those reserved is considered a feature.

If we need to develop a feature this is the flow:

GitVersion increments minor version automatically, in our case that we never used GitVersion the previous version is deducted looking at a number of things, including for example the TAG.

To manage a bug fix: because GitVersion is meant for GitFlow, which makes us comfortable because GitFlow is thought for frameworks / toolkits. Let's say we have the XYZ package that is on Nuget inversion 1.3.0, 1.4.0, and 1.5.3 and from our point of view are all supported. We find a bug, and the bug is in all those versions above. We create from develop three branch (that could live forever):

In each of the three branch we apply the fix.

At this point in support branch we have the fix, but we also want to publish the fix in develop branch, maybe the bug is still present even there.

Release: every time we publish something we open a release branch, the name is important, GitVersion view history and based on where it comes from this release branch,develop or support- determines what needs to increment. Obviously the release branch can be called release/1.9 and GitVersion use for version 1.9.

Finally, there is a concept called hotfix branch, it works the same as support, the macro difference is that a hotfix- branch arises from the master and not to develop, is used to represent an urgency, to GitVersion is not so important.

mauroservienti commented 8 years ago

I have added to all the repo a GitVersionConfig file, such as the following:

branches:
   develop:
      tag: beta

why beta and not the default unstable, the main reason is lexical sort on nuget. For this reason I was thing, thought another issue later, to update all the GitVersionConfig so that develop is considered as alfa, this would allows us in the future to release alfa, beta and rc versions before the RTM.

@micdenny thoughts?

micdenny commented 8 years ago

that's ok, but alfa or alpha? :smile:

mauroservienti commented 8 years ago

shit, alpha :smile:

mauroservienti commented 8 years ago

Here are some info on the default GitVersion configuration: http://gusztavvargadr.github.io/2015/10/30/2-gitversion-to-the-rescue/

mauroservienti commented 8 years ago

all packages are now on Myget