This doesn’t really belong under problems or questions - it is more of a feature request.
I have Octopus running nicely in my in-house server set up. However my production server is on a hosting provider with very strict firewalls.
At first I was excited to see the FTP deployment option, unfortunately my imagination got the better of me and there is a difference between what I imagined it was and what it really is. what you get is a deployment on machine A when then syncs via ftp to machine B. In my case, B is production and A is something on my side of the firewall.
That is fine for publishing web sites, but Octopus’ main value prop (at least for me) is the ability to shut down a running service, deploy a new one, then start the new service. Even with web sites, I like that it shuts down the existing site, deploys to a new folder, then effectively restarts IIS with the new folder. If something goes really wrong, I can switch back to the last release pretty easily.
Going back to the FTP deploy, here’s what I really hoped it was: You could still have a tentacle on Machine A, but instead of just doing an FTP sync (which doesn’t help with services), you would instead ftp the nuget package / release data to Machine B where a second tentacle would find the release and deploy it on that computer. Essentially instead of having a connect to the octopus server, it just watches a folder and when it sees a new release it deploys it.
This helps those of us who cannot just open up firewall ports at will because there is a network manager telling us we can’t. My production server will never be able to access Octopus or TeamCity (where the nuget pacakges are served) owing to the fact that there are two firewalls between the two environments, and there’s good reason for it. As a developer I have no control over either firewall.
We need to be able to make good use of standard open ports, but without hijacking them (i.e. you could make a tentacle listen on port 21 but then you no longer have an FTP server).
I think my imagination went this way because we have a service that does this exact thing, just not with deployment data, but rather as part of a feature of our product.
Thanks for a great product!