Update documentation around deployment options

[awatson1978]

Hello.
Thank you for all the hard work in shipping meteor-azure! Much appreciated!

So.... Azure has updated/removed the Deployment Options menu item, and replaced it with a Deployment Center item (which has a lot of options). The meteor-azure documentation now seems out of date, and it's quite unclear how to deploy. Could we get a quick update to the documentation? Or a gist maybe?
Thanks!
Abby

[ramijarrar]

Thanks for this - been crazy busy this year but I'll try and get around to it on the weekend. Will also need to document all the v2.1.0 features (multi region deployments, 64 bit architecture, environment specific meteor settings, etc.) to get that out of RC.

FYI - we've also been doing some research on compatibility with self-hosted Kudu on Azure VMs (to bring costs down and take advantage of Reserved Instances). Hoping to have more on that in the next few months.

[ramijarrar]

In the interim, just follow the "Getting Started" steps as documented and when you get to the "Deployment Credentials" section:

1. Open Deployment Center and select "FTP" then open "Dashboard"

2. Configure the "User Credentials" and use in place of "Deployment Credentials":

Everything else should be the same - but let me know if you have any further questions/issues.

[awatson1978]

Oh, perfect. Thank you so much. It's all obvious 20/20 in hindsight, but I was getting lost in the Local Git configuration. This definitely helps.

Aaaaand... we're getting super promising logs from meteor-azure --debug. So, I think that solves our problem. Thank you!!!

[ramijarrar]

Glad to hear it's working for you. Will keep this issue open to track updating the docs.

[awatson1978]

Thanks for reopening. Honestly, I've been at this all day, and still haven't gotten the thing deployed. :/

[ramijarrar]

Any particular step you are stuck on?

[awatson1978]

It's a mix of having crap visibility into the server logs (not your fault; but also not a fan of Kudu and curl), being behind the web.config firewall, long upload times, and just not being able to diagnose errors.

One specific thing I'm confused about though are the User Credentials. I'm seeing a prefix where there didn't use to be. {siteName} + '/' + {userName}. You redacted it in the screenshot above, but I don't think there used to be a siteName prefix. And when I put it into the settings.json file, there is a syntax error.

{
    "meteor-azure": [{
        "siteName": "my-site",
        "resourceGroup": "my-app",
        "subscriptionId": "e56a...",
        "tenantId": "a014...",
        "deploymentCreds": {
            "username": "my-site/abigail@symptomatic.io",
            "password": "mypassword"
        },
        "envVariables": {
            "ROOT_URL": "https://my-app.azurewebsites.net",
            "MONGO_URL": "mongodb://..."
        }
    }]
}

[ramijarrar]

A few things that may help -

1. Don't use the site name in the deployment creds (it's exactly the same as before, make sure you are setting User not App creds)

2. You can setup automated login so you don't have to keep authenticating between deployments (process hasn't changed, see https://meteor-azure.readthedocs.io/en/latest/configuration.html#setup-automatic-cli-login)

3. Where are you going to view the logs? We usually only use Kudu to see deployment errors (these are now also visible with debug mode in the CLI) everything else is forwarded to papertrail.

Let me know if that helps or you have further issues.

One other thing to mention is that build times are much faster if you can eliminate legacy atmosphere packages with NPM deps as this often leads to deep nesting. We were able to cut down from 15 to 8 minutes in one of our larger apps just by auditing these.

[ramijarrar]

Also not sure if this is relevant to you, but the same bundle can be deployed in parallel across with settings files (e.g if you need to target different environments with different config):

meteor-azure --settings 'foo/bar.json,baz.json' --architecture 64

We implemented this in #60 but have not got around to documenting it yet.

[awatson1978]

Ooof. That was it. We're deployed and online again.

--architecture 64 was a breaking change for us. Definitely need to update the command line options in the documentation.

[awatson1978]

Should also document that the Meteor.settings.meteor-azure setting is now an array. Was relatively easy to fix since there were command-line prompts to fix.

[ramijarrar]

Should also document that the Meteor.settings.meteor-azure setting is now an array. Was relatively easy to fix since there were command-line prompts to fix.

Yes - but we still accept an object for backwards-compatibility (to deploy to one site).

[njbuch]

+1 for this, I got stuck as well. Will try these tips and revert with feedback in case it goes wrong... Looks awesome!