search

RicoSuter / DNT

DNT (DotNetTools): Command line tools to manage .NET projects and solutions.
MIT License
414 stars 63 forks source link

bump-versions: GitVersion integration #43

Open jzabroski opened 5 years ago

jzabroski commented 5 years ago

Detect if GitVersion Nuget package is installed. If it is, bump-versions should create new git tag and commit the tag.

RicoSuter commented 5 years ago

Ref: https://github.com/GitTools/GitVersion/blob/master/README.md

jzabroski commented 5 years ago

@RicoSuter You can also read my Reddit thread where I did a brainstorming session on how I want to build a better mousetrap going forward: https://www.reddit.com/r/csharp/comments/bn4388/why_would_i_use_gitversion/

RicoSuter commented 5 years ago

Should it actually modify the csproj and take the new version, commit everything and create a tag based on the new version?

jzabroski commented 5 years ago

I think there could be two ways to call it:

  1. Modify the Version element in the csproj using the new version, commit everything and create a tag based on the new version (and push that tag)
  2. Let GitVersion handle the Version details viz a viz its pipeline.

Thoughts? I am open to ideas/opinions - this is all stuff I've been thinking deeply about lately and building a better mouse trap is subtly hard. For example, I'm not convinced Microsoft's own build process for .net core (dotnet/arcade on github) is sane or logical.

In terms of where I want to go with this (and see value add), I think in my future projects I want to use AppVeyor and its Yaml build templates and GitVersion for versioning. I can then use DNT bump-versions to help in major version upgrades - so then my release process because fairly simple and "push a button and go drink beer" simplicity is what I want in my tools. (My thought is then it becomes very easy to automate creating new projects and new build definitions, because I can then just copy+paste the build template, and if I need to refactor the build template or find excessive copy+paste, there are tools that are good at analyzing text files for similarities and automate a lot of that. Today, I use TeamCity and I can't easily do that since it's all in a SQL Server db).

But... I'm also open to hearing what you do.

RicoSuter commented 5 years ago

My big open question is whether the actual version should be in the csproj in the repository, just retrieved from the tag or highest tag or in the build pipeline?

jzabroski commented 5 years ago

When you bump version, you mutate the csproj, commit it, then tag the commit, the push the tag and commit. At this point, the csproj and GitVersion agree.

I suppose there can be a sanity check to make sure someone doesn't fat finger anything.

I reserve the right to change my mind after playing with it a bit :)

On Thu, May 23, 2019, 7:45 PM Rico Suter notifications@github.com wrote:

My big open question is wheter the actual version should be in the csproj in the repository, just retrieved from the tag or highest tag or in the build pipeline?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/RicoSuter/DNT/issues/43?email_source=notifications&email_token=AADNH7OQD5PXRCCBZOZGHG3PW4UBPA5CNFSM4HM57ZMKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWDY5HQ#issuecomment-495423134, or mute the thread https://github.com/notifications/unsubscribe-auth/AADNH7LX6FAH4OUHQEYIADDPW4UBPANCNFSM4HM57ZMA .

RicoSuter commented 5 years ago

But with this flow you dont need gitversion, right?

jzabroski commented 5 years ago

I'll do a code spike to prototype it.

On Fri, May 24, 2019 at 1:16 PM Rico Suter notifications@github.com wrote:

But with this flow you dont need gitversion, right?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/RicoSuter/DNT/issues/43?email_source=notifications&email_token=AADNH7KUZT5UXKWOBRKVLY3PXAPF7A5CNFSM4HM57ZMKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWGAN3Q#issuecomment-495716078, or mute the thread https://github.com/notifications/unsubscribe-auth/AADNH7NB7XTQ3XHMAZLTDU3PXAPF7ANCNFSM4HM57ZMA .

RicoSuter commented 5 years ago

This is my current build script: https://github.com/RicoSuter/NJsonSchema/blob/master/azure-pipelines.yml

But I think I'll remove the release branch and work with tags as you suggested.

jzabroski commented 5 years ago

(A little philosophical but...) One of the things that has been an epiphany for me recently is that, if I think like an engineer constructing an architecture, the TeamCity (and TFS...) way of defining source code is, for better or worse, a glorified Service Locator design pattern. AppVeyor's multi-branch support, on the other hand, is a Abstract Factory design pattern. Ask yourself which design pattern you would want for identifying what source code to build:

public interface IServiceLocator
{
  T Create<T>(object context);
}
public interface IFactory<T>
{
  T Create(object context);
}

What I really want is a single type defined ahead of time as "MyRepository" (IFactory<MyRepository>), and use the object context parameter to decide various build properties. My build template is then all things I can do with that T - imagine generic constraints, etc. In the Service Locator example, I'd have to write a custom build template for each source code repository, which is more or less what I do with TeamCity... (and the pain is not so obvious because TeamCity basically provides abstractions that cover up some of the pain points of doing and thinking this way).

RicoSuter commented 5 years ago

I think that is why we have build and release pipelines in Azure DevOps (formerly TFS) - build pipelines are here to build artifacts and depending on the source (e.g. a tag or a special branch) you can trigger a specific release pipeline which does the actual deployment.

I for example (ATM) have a single build pipeline to build the artifacts and two release pipelines (one for to publish to the preview feed and one to push to the nuget.org feed).

RicoSuter commented 5 years ago

Maybe my new flow would be:

jzabroski commented 5 years ago

I think I like this. I also like adding a new command instead of changing existing.

RicoSuter commented 5 years ago

I know that this command would be specific to this (my) flow and i’m not even sure whether it should be part of this tool because of that.

jzabroski commented 5 years ago

Every "flow" starts off as just one person. GitFlow was one person's blog post, it rose to Number 1 on Google for how to branch and merge Git repositories. Why can't this approach we discuss here rise to Number 1 on Google for how to version .NET Core repositories? I think you're vastly underestimating the target audience size.

RicoSuter commented 5 years ago

I wrote a blog post: https://blog.rsuter.com/azure-devops-my-versioning-flow-to-publish-dotnet-packages-from-github-repository/

What do you think? Is it clear?

jzabroski commented 5 years ago

I'll have to try following the guide to weigh in but am thankful for your correspondence

I'm on my honeymoon right now so hopefully I remember to give it a whirl when I get back

On Thu, Aug 15, 2019, 10:44 AM Rico Suter notifications@github.com wrote:

I wrote a blog post: https://blog.rsuter.com/azure-devops-way-to-version-and-publish-dotnet-packages-from-github-repository/

What do you think? Is it clear?

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/RicoSuter/DNT/issues/43?email_source=notifications&email_token=AADNH7MCRGC56GQIKLMCSHDQEW53JA5CNFSM4HM57ZMKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4M6JWI#issuecomment-521790681, or mute the thread https://github.com/notifications/unsubscribe-auth/AADNH7N7ICNVY7OXM5MT6CTQEW53JANCNFSM4HM57ZMA .

drorasaf commented 3 years ago

Your approach is missing how to handle minor and major changes in the CI/CD aspect.

jzabroski commented 3 years ago

@drorasaf example please

drorasaf commented 3 years ago

Standard workflow bumps the version of the library as a patch, however when there is a breaking change, it is up to the developer to change the version manually. this use case is not covered.

Covered Flow: Fix a bug CI/CD: bump version patch CI/CD: release

Not Covered Flow: Develop feature developer: bump version major. CI/CD: release

The flow suggested currently does not take into account if the developer has changed the version himself/herself

jzabroski commented 3 years ago

Well, the developer should call dnt bump-versions major, rather than hand editing the csproj. I am not clear why you would switch tools for managing the workflow. The flow only breaks because you're not following how gitversion works.

Am I correct or am I still missing some subtlety?

The whole point of this issue I raised was to have version bumping work like an "Gated SR-Latch" in digital circuits (similar to how a staircase can have a light switch at the bottom and top of the stairs). https://en.wikibooks.org/wiki/Digital_Circuits/Latches

drorasaf commented 3 years ago

in the described workflow, there is always another bump-version, which will cause that there will never be a 4.0.0 version, but the minimal one would become 4.0.1 I completely agree that the developer should call the operation with major, but I would also expect the CI/CD to not bump on top of that