What strategy is recommended for an asp.net deployment when working with NuGet. I’m using something like the following 1.0.0.(build number). If I set up a release called “1.0.0” in Octopus but I only get to choose 1 version from NuGet whereas I’d like to iterate many times on 1.0.0.x, deploying often. I did notice that Octopus now has a Refresh button but it isn’t updating to the latest build number from NuGet.
Hi Adam,
On my projects, when my build server produces version 1.0.0.1 of the package, I go into Octopus and create a release for 1.0.0.1. When my build server creates 1.0.0.2 of the package, I create a new release called 1.0.0.2. To make that easier I plan to add some command line tools/web services you can call to create a release and deploy it to a dev environment, but for production deployments you usually want to promote each release manually between environments (e.g., you might be deploying 1.0.0.2 to staging while deploying 1.0.0.1 to production because all user testing passed).
Hope that helps,
Paul
Yes, that strategy is appropriate for production but creating a new “release” could be thought of as added overhead in a fast paced development environment. As a comparison, I currently use TeamCity itself to deploy the latest web code from the trunk of my project to my development server. I am able to make the assumption that a “release” is in fact the latest code from source control. Although its very primitive right now, I expect my private NuGet repository to closely model what I do in source control which is to develop off the trunk, branch/tag before a release to production, and always deploy the latest code off of the trunk/branch/tag.
Don’t get me wrong, I dig this project quite a bit and have wanted to build it myself many times 
Hi Adam,
I agree with you. Another idea that was bouncing around was to automatically create and deploy packages when a new NuGet package is available. Because NuGet feeds can be polled for updates, Octopus could subscribe to be notified when a new package is available, and automatically create a release and deploy it to a Dev environment. This would probably just be an option in the project settings. Would that be useful to you?
Paul
It would in some environments and not in others. e.g. my QA staff would be annoyed at me if I deployed to them on every commit but developers expect that to some extent in a Dev environment. I do like the idea of having that option and have seen CI servers set up to accomplish it similarly.