simple-odata-client / Simple.OData.Client

MIT License
329 stars 192 forks source link

Introduce Azure DevOps pipeline #729

Open phatcher opened 4 years ago

phatcher commented 4 years ago

As per @NetTecture suggestions, I'm going to create a Simple.OData.Client Azure organisation with associated build pipeline and an associated artifacts repository which would allow us to produce nightly builds and/or builds from feature branches. We can then decide which of these should be pushed to nuget e.g. betas might be but nightly builds/features branches might not.

I also propose that we adopt SemVer going forward via GitVersion, this will make managing package versioning much more intentional and make it easier to support feature/beta versions of the package.

So the open questions are...

  1. What should the branching strategy be going forward
  2. How exactly should we do versioning
  3. What packages should be published to the public nuget feed

Comments/thoughts?

phatcher commented 4 years ago

For reference, this is part of/in response to #713 and #654

NetTecture commented 4 years ago

Ah, i suggest keeping things simple.

Then

This gives an archive of which version was released and should allow gitversion to do it's work. I do not really see us patching older versions, or?

Nuget:

release/ and preview/

get pushed to nuget. Nightly do not, we keep them separate (on azure) and publish the necessary nuget configuration so people can use them. This allows one to use either the nightly version, or the released or previewed versions easily with very little config work.

Azure should be public- we get a lot of licensing if it is public (10 agents iirc). And we can use it to run the unit tests there.

Looking forward to see how you set this up - I am fighting on this full automation at the moment.

object commented 4 years ago

Great initiative, guys!

phatcher commented 4 years ago

I've set up the org/project, will work on a pipeline this weekend - https://dev.azure.com/simpleodataclient/Simple.OData.Client