We are close to testing a blue-green deployment, to a subset of web farm servers (servers 5 and 6, out of 6 servers the main project uses).
The main application currently has servers 5 and 6 pulled from the load-balancer, as part of the blue/green testing.
When we start to deploy with the separate blue-green project, I expect this will maintain it’s own, separate set of release versions and accurately show us which release versions are in Dev, QA, and Prod. Correct? Even though some of the Nuget packages in the blue-green release will already be on the target servers via a prior deployment of the main, non-blue-green project.
From what I’ve seen, I think this will work fine, and if Octopus sees a version of a package already on the server, it will just do nothing unless we select to Force redeployment of packages already on the tentacles.
I believe Octopus manages release versions, independently of whether some packages and tentacles are shared or not across projects.
A team I’m on inquired about this, and I wanted to ask for sure.
If you have a completely separate Project set up in Octopus, with separate deployment locations, then the only thing that gets shared is that the Tentacle has a package cache. So we don’t need to transfer the package twice if it is already been deployed in the other Project and is sitting in the cache. As you say, versioning and everything else is completely independent.
The thing to watch out for is things that are inadvertently shared between the Projects:
If you are using the Custom Installation Directory feature to deploy to C:\MyApp from both Projects then each time you deploy a project we’ll write it to that folder, we don’t know the other Project is already there.
If you are using the same IIS website between the two projects, each time you deploy one of them, we’ll point the website to that deployed project.
We have a completely separate project setup, however the Tentacles (servers 5 and 6 let’s say) are also used by another project as well, and the same deployment locations are used.
We want this to be the case, and we’ll manage and time the coding and builds/deploys and testing as appropriate.
I largely wanted to be sure a separate project using these 5 and 6 servers would maintain its own separate release versions and would not get “confused” because the endpoints and folders are shared with another project.
