after a release I notice a promote to button when the release was successful.
You are able to specify an environment and whether you want packages skipped.
Example say I release xl-testdev and build succeeds and want to promote those packages to xl-test.
What does the promote button do under the covers? From the outside I see that the user interface links a project to steps that contain (nuget feed, package, machines to deploy package to).
The promote step would make sense if machines to deploy package to was not part of the step definition - should be in the environment definition per project.
I’m a little stuck on how i should handle deployment to staging environments as depicted in the attached file.
Good question. A “promote” is really just a deployment, the promote button isn’t doing anything special.
When you define a step, you choose the machines the step will be deployed to, but those machines belong to an environment.
For example:
Deploy package ABC.1.2.3 to:
Production
Machine 1
Machine 2
Staging
Machine 3
Machine 4
When you do a deploy to Staging, only machines 3 and 4 will receive the package.
When you promote that release to Production, machines 1 and 2 will receive the package. We would never deploy the package to machine 1 when deploying to Staging, because machine 1 is a production machine.
when creating environments one suggestion is to be able to link a machines to multiple environments. Currently i have to copy and paste to make it part of the environment document. Example we use a shared database sql server and each machine holds our web/win services only. I’m having to copy the sql server machine to all the staging environments.
since it is part of the image I’ll ask here - “3rd party databases”
we want to deploy a large 1.6GB package to rebaseline all staging environments at 1 time. Seems the default nuget.server uses a file based approach that will not work - unless i configure the pre unzipped package repository. What are you all using for large packages?
licensing - we have the same structure * 3. We could shove it into 1 instance of octopus server (enterprise) but given the existing dashboard design, it would be cleaner to separate octopus server per product (same product but we provide appliance that needs to be tested per client) . We need a package to let us install multiple instance of octopus server at a reasonable cost for our enterprise.
we want to deploy a large 1.6GB package to rebaseline all staging environments at 1 time
I assume the 1.6 GB file is a backup of the database you want to restore?
A package that size is going to cause huge problems with NuGet (for example, NuGet’s hash validation code loads the whole package into memory). If possible, it might be better to store the backup file on a file share somewhere, and to reference that from your restore package (so your restore package would probably just have a PowerShell script).
I know it breaks the idea of having a single package repository for all assets, but unfortunately it’s a limitation of the packaging technology. I’ve seen some forks done by people to make NuGet cope with larger packages, but for whatever reason these have never been merged to NuGet core.
We could shove it into 1 instance of octopus server (enterprise) but given the existing dashboard design, it would be cleaner to separate octopus server per product
We have a couple of Trello items to address that (1, 2, 3) in the future. In the mean time, feel free to use the same enterprise license on multiple installations, as long as they are being used by roughly the same group of people for the same area of the organisation (as in your case).
