We are evaluating Octopus Deploy as our deployment tool. We are a product development company and therefore we would like to be able to develop our products in house and deploy it to the customer’s environment. Many of our customers might not like the idea of they having to buy the Octopus Server, or even we buying it for them and installing on their environments.
So, while going through the options, I came across this “Offline Package Drop Deployment Targets”. I would like to know more about it.
Ideally I would have liked to call your tech support, but I couldn’t find a phone number.
So, I have some questions regarding this – and the very basic and most important one is this - is it capable of doing each and everything a tentacle can do?
(1) Is it capable of handling load balancing environment?
(2) No additional component needs to be installed on the target machine – correct?
(3) What happens if something goes wrong in between the execution of the batch file?
Thanks for getting in touch! For product development companies deploying to their customers, you should only need your own licenses. The deployment target agents ‘Tentacles’ do not require any additional licenses. Your customers will only need to allow you to connect to their machines. Based off your comments about using the Offline package drop you would need to install the package contents on the end server and run the scripts, so I have assumed you have access to their servers. The amount of Tentacles would be your only license concern, and with Enterprise that limit is unlimited.
To answer your questions specifically however:
Calamari is the ‘brains’ behind the Tentacle, and that is part of the offline deployment package. It runs all the same commands. So it is capable of everything Tentacle does. It isn’t however capable of everything the Octopus Server does. The Octopus Server during a deployment does all of the orchestration. This includes things like output variables for steps, manual intervention, email sending, running scripts on the Octopus Server, running steps on multiple Tentacles for a single deployment, guided failure. All of this cannot be done within an Offline drop deployment package.
That would depend on the infrastructure and process. If you are referring to say the deployment target machine being removed from the load balancer for example. This could be achieved via powershell if that can be run on the target that contacts the load balancer. But if you were using the Octopus Server for example, you could contact the LB server itself or via the Octopus Server script. But not in the case of offline deployment target unless as I stated it can be done from the target machine using a script step.
Everything is part of the package. All NuGet (or other) packages, Calamari, variables and bash script. It contains everything you need without having to install anything on the end point (unless it is an SSH target, then you would need mono to run Calamari).
You would have to react to the error. You have less options than if you are using an Octopus Server -> Tentacle deployment.
We do offer sales style demonstration calls, but they are by appointment, as we are in Australia we need to schedule the times ahead as they generally fall out of our business hours. A reason we do not offer phone support, no one would be around to answer the calls during US business hours.
Please let me know if I can expand on any of this information.
We too are trialling Octopus 3.0. We’d like to use Offline Package Drop to install our application on customer sites and have a few questions
Is it possible to set variable values at install time (e.g. a customer may not be willing to share the passwords so they may wish to set these at install time or a server name might be slightly different on a customer site)?
Additionally, does the Offline Package Drop have to machine name?
Thanks for getting in touch! Depending on your needs there are some solutions to the password at deployment time problem.
Generally the easiest is to define some variables and give them placeholders such as
DBPass with a value of
%DBPASSHERE% that is not set as a sensitive variable will place this variable in the variables JSON that the customer can do a search and replace for
%DBPASSHERE% and replace it with their password. Of course this will rely on human process, but as it needs to be extracted and run, this can be part of the deployment steps.
Prompted variables do not work as they are defined on the deployment creation and merged into the variables JSON.
When it comes to defining the offline drop target, if you need specific customer variables or machine specific variables that you design each drop target should represent the environment it is being deployed to. You can use a single drop target for an environment if nothing is specifically unique or all customers are going to use a password or sensitive variable model like above. I am not 100% understanding your final question, is it missing a word? Do you want to know if it has to have a machine name or something else?
Let me know!