This is most likely a stupid question but for the life of me i can’t find a way to tell a new server that was added to an environment to install everything that has been assigned to it based on its role etc. I have needed to add a new server a few times now and if you have 15-30 projects/applications assigned to the roles and environemnt that server belongs to you really just want to tell it to get the lastest version of the apps released to that environment without needing to go though and check each the projects and apps or telling each of them to redeploy.
I am sure i can be done but i can’t find it. Can someone point me in the right direction?
I have also found that you sometimes want to do this when you add new roles to existing servers or move them between environments.
Thanks for reaching out. What you can do here is trigger a deployment of the latest version you are trying to install, but instead of deploying to all the machines that meet the Environment/Role criteria, just deploy to that machine in particular. See attached screenshot for a visual reference to find this option.
You could also do the same from the command line by using Octo.exe with the
--specificmachines parameters. This is specially useful if you are spinning up new VMs and you want to deploy the latest to your tentacle as part of the provisioning process.
Hope that helps
So to confirm if i use
Octo.exe Deploy-Release --specificmachines xxx
It will push all the projects that should be on machine xxx if they are not deployed there already? So it would push the 10 to 15 out of the 50 projects that belong on that machine without me needing to manually go though each project, work out if it belongs on that machine and doing a deploy if it does?
It would be really useful to have a button to do this sort of them on the machine in the environments interface as well as a view of all projects and the versions on a particular machine or the software and versions that should be on the machine
Deploy-Release also has a
--Project parameter where you have to specify from which project you’d like to deploy to that tentacle. It wont deploy from all the projects where that tentacle is used (imagine the chaos if it did). Each project has its own release version, and it’ll be impossible for Octo.exe to know which release version to pick from each project. Your’e gonna have to run Octo.exe for each project, specifying which release you want to deploy from it.
We don’t do version monitoring per machine. We monitor the Release version on the environment, as it is supposed that all the machines on that environment have the same version.
That is my point injoin a new machine or change a machine on an environment and want to tell octopus to deploy everything to the machine based on its role etc to the version for that environment.
Another usecase for something like this would be the cloud where you may spin up machines for a role as load demains. It is a lot less error prone if you can tell the machine to install everything it is meant to have based on role and environment. If you list every project manually what is the point of setting deployments to environments and machines with particular roles. You then need to manually implement that same logic somewhere to then ask octopus to deploy project by project to update a newly added machine instead of just having a button for it. It seems like a common situation to me since this is the 3rd time i am dealing with it and we are likely to increase our projects from 40 to many hundred andngoing though each to see if we should put a copy on a machine based on its role when the machine is new is partly why we got octopus for release management. I understand for new deployments etc but this is to fine missing releases from machines in an environment and to deploy everything missing on them and only octopus have that info currently. I guess i could try to access the octopus database and duplicate your logic in custom to work out what should be on what box and then redeploy to just that box one by one via code but seems like it is something missing.
Also why is it chaos to deploy all the software that belongs on a box at once? Think replacement of hardware that died, DR, new server to spread load on to or a sever that has changed roles.
We love octopus as it saves us so much time generally but 3 things could be done better.
- The issue above of being a box up to date for want is in an environment/roles the box belongs to.
- Being able to nest project groups to multiple levels
- Being able to promote all projects in a group from one environment to another if there is a difference between the environments for that projects.
We fine grain our projects so we can better track versions of reports and other things because we sometimes need to just update some reports and not others. This leads to a lot of projects.
Sent from Ninehttp://www.9folders.com/
Apologies for the miscommunication. What I mentioned above about deploying to specific machines is a workaround that we propose to users that are trying to create a process very similar to what you are trying to accomplish. At our current version this is the best that can be done with Octopus, but please be aware that we are planning on supporting scenarios like this one on future versions (specifically on 3.1)
Our CTO Damian wrote this blog post a couple of months ago about our plans to support cloud-like practices such as the one you are doing. Please take a look at it if you have time
Has there been any movement on this feature? BTW, my company is not deploying to the cloud, but we do rebuild dev and uat environments fairly regularly. We’d like to be able to redeploy all applications to a machine or an environment at will.
Hi - This will be able once we introduce Multi-Tenancy in
3.4, as you’ll be able to “put up to date” any machine that you add to an environment/group of tenants.