Would you consider a “tentacle” for deployment to a Windows Azure environment? I know it has a lot of it’s own infrastructure and the tentacle would most likely live with the web site or near it since there’s nothing to install an agent on. The main feature would just be publishing to the staging environment, the rest would still be more in the Azure UI.
Yes, this is an essential feature to me! I’d love to have this in Octopus.
Hi Dan and Mike,
Thanks for the feedback, I’ve added the suggestion to the Octopus Trello under ideas/suggestions for v2:
Just curious, does Azure have any command line tools? If so it would actually be possible to do it now I think - you would just need to create a NuGet package containing your site, and implement a Deploy.ps1 that uses the Azure tools to upload and deploy the website. You could then install a Tentacle on the Octopus server, and configure your deployments to point there.
I’d love some more details on how you think Octopus could work with Azure and the kinds of scenarios you’d like to achieve with it.
Sounds like it’s pretty easily scriptable. I will have to get this going and try it out.
I have started work on this finally and it really needs some work to do it well. If I have multiple Azure environments to deploy I have to use multiple local machines to handle it.That seems a little onerous to me.
Allowing multiple tentacles or letting a tentacle support multiple environments or something is badly needed.
Basically the setup that I want to create is this:
- deploys to a test deployment/production instance on Azure
- deploys to the live deployment/staging instance on Azure
I want to be able to get my TeamCity auto-deploying to the Test environment. I can smoke test it, then push it to the Live environment. After another quick smoke test I can swap VIPs on the live deployment and it will be fully live then.
I’m curious how you could change the ServiceConfiguration post-build. That’s the one piece that I struggled with so I could automate the rollout of a single build to different environments in Azure.
What do you need to change in your ServiceConfiguration?
Thinking about this some more and you’re definitely right. Being able to modify the service definition and configuration per environment would be exceptional.
Right now I’m just doing a lot of dynamic stuff in my code and staying away from using my settings files.
From looking at this, it seems like *.config files are already processed fine. We’d just need it to also apply the same logic to *.csdef and *.cscfg files. Then we’d have Azure config file support handled.
After that we just need a way to have multiple environments per tentacle or multiple tentacles per machine.