I recently applied to have EasyNetQ, my awesome RabbitMQ API for .NET, build on the CodeBetter TeamCity build server (you can log on as ‘guest’ with no password). The very helpful Anne Epstein set it up for me and all is now is building, testing and packaging nicely.
The bit I really like is that TeamCity can automatically push the EasyNetQ NuGet package up to NuGet.org on each build. So now EasyNetQ has continuous delivery, when you install or update it using NuGet you are getting the very latest version fresh from GitHub.
My attention was also drawn to MyGet.org, a personal-nuget-in-the-cloud service. For the moment, with EasyNetQ still very much a beta project, I’m happy to have the latest master always be available, but I can envisage some time in the future where I’ll want to have a bit more confidence before pushing a release up to NuGet.org; MyGet would allow me to publish beta packages for testing and then promote them to NuGet when they’ve passed all the QA barriers.
I now consider continuous deployment / delivery to be essential for any software project; It’s just brilliant being able to point anyone who cares to a test server that always has the very latest trunk build. It’s all a part of keeping development process cycles as tight as possible and always having working software.
Mike - have you looked at publishing pre-release NuGet packages using semantic versioning? We've got this running on our TeamCity box at Spotlight - packages built from the trunk are versioned X.Y.zzzz, where zzzz is the Subversion revision number, but packages built from branches are versioned X.Y.zzzz-branch or -unstable, and so won't show up in the NuGet feed unless you explicitly opt-in to seeing prerelease packages.
ReplyDeleteThanks Dylan, some good advice there.
ReplyDelete