CQRS and coordination

[Chris Eldredge]

When a new package is pushed to a package feed such as nuget.org, the

HTTP request completes before the repository becomes consistent with the new state.

This is generally fine as clients don't typically need to coordinate activities

immediately after pushing a package and it generally resolves within a minute or two.

On the other hand, some specialized uses of NuGet do require such coordination.

One example is Continuous Integration scripts that integrate with OctopusDeploy.

The steps would be:

1. Create nupkg(s)

2. Push packages to a NuGet server (maybe the one built into OctopusDeploy)

3. Use the OctopusDeploy API to create a new release candidate with the new nupkg version(s)

Step 3 cannot happen until OctopusDeploy is able to see new packages in the feed.

Historically this has not been a problem because typical NuGet feed implementations

used by OctopusDeploy have strong guarantees that a package will be visible by the

time the push operation completes.

Since the V3 API seems to be adopting CQRS as an architectural pattern, I'd like to

ask if any thought has been put into use cases such as these? How should a build script

poll a NuGet V3 feed to know that a recently uploaded package is now ready for consumption?

Thanks,

Chris

[Jeff Handley]

Our general guidance is that build systems shouldn’t be publishing to eventually-consistent repositories for immediate consumption.  Instead, build systems should publish to immediately-consistent repositories during the build, and then publish to eventually-consistent repositories at the completion of the build.

 

The folder-full-of-nupkgs repository is generally a good option for CI builds that are self-consuming.

--
You received this message because you are subscribed to the Google Groups "NuGet Ecosystem" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nuget-ecosyst...@googlegroups.com.
To post to this group, send email to nuget-e...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Alex Papadimoulis]

Moreover, this isn't (well, shouldn't be!) a problem for team NuGet to solve... "manage gallery of open-source/pubic libraries" vs "in-house dependency management". There is absolutely no need for one of these libs published to nuget.org to be immediately available.

I'm sure our team will come up with a solution if there's a need for the in-house crowd.