I'm currently in the middle of building two new step types for Octopus Deploy:
- Deploy via FTP
In this step we'll extract a NuGet package on the Octopus server, then "sync" it to an FTP/FTPS server. This will also make it possible to deploy Azure Websites as they support FTP. - Deploy an Azure cloud service package
In this step, we'll extract a NuGet package on the Octopus service which should contain an Azure cloud service package (.cspkg) (we'll extend Octo.exe or OctoPack to make it easy to re-pack a .cspkg as a .nupkg). We'll then upload the cspkg to blob storage, and then deploy it to Azure.
Normally, we run package steps on the Tentacle agent. However in this case, both of these step types are going to be run directly on the Octopus server instead of on Tentacles. This means that if you are just using Octopus to deploy over FTP or to Azure, you won't need to set up any Tentacle agents.
Both steps will support the usual XML updates and transforms that we currently do, plus the execution of the usual PowerShell scripts (which will run on the Octopus server). So you could, for example, use PowerShell to update the files prior to FTP or prior to being uploaded to Azure.
When configuring an FTP step, you'll set the host, username, password, and the other usual settings. You can also specify an FTP root directory. All of these can reference Octopus variables, so you could, for example, use a different host/root directory/username for your staging/production deployments.
For Azure cloud service packages, we're also going to provide two options to manage the instance count:
- Use the instance count settings in the CSCFG
- Keep the instance count settings in the currently deployed service when updating
So for example, if you originally deployed to production with two instances, then scaled it using the Azure management portal to 4, we can either use 2 (specified in the cscfg) or 4 (which we'll fetch from the management API) depending on the option you choose.
We'll also support variable substitution in the Azure cscfg file. For example:
<Role name="WorkerRole1">
<Instances count="1" />
<ConfigurationSettings>
<Setting name="MyConnectionString" value="blah blah" />
</ConfigurationSettings>
</Role>
We'll replace the "value" attribute of that setting if you have an Octopus variable named WorkerRole1/MyConnectionString. Note that the setting is prefixed with the name of the role to allow different settings for different roles.
When choosing the cloud service configuration file to use, we'll look for (in this order):
- ServiceConfiguration.environment.cscfg
- ServiceConfiguration.Cloud.cscfg
Since an X509 certificate is needed to connect to the Azure management API, we'll automatically use the Octopus server certificate. To give permission for Octopus to deploy to your Azure subscription, you'll just need to download the .cer file from Octopus and upload it to the Azure portal. We'll provide a link to your .cer and installation instructions on the page for editing the Azure step.
What do you think? As I said, I'm currently building these features, so if there are other scenarios relating to Azure or FTP I'd love to hear them so we can include them in this next release.
