What are best practices for deployment to production?

[yuzeh]

Apologies if this question doesn't belong in the right place. Somewhat related to the discussion going on in #102.

I'm trying to deploy parse-dashboard in production, and would love to know what best practices are, and also how other people are doing this.

More specific questions:

• Should it be deployed as a standalone application, or is there a vision to make it mountable on another node webserver?
• Should we always deploy the latest possible version? Will there be hazards for not being kept up to date? (Update npm package/registry #102 kind of discusses this)
• Should the client-side assets (JavaScript, CSS) be built on every deploy from source, or will they be provided (pre-built either in the Git repo or on a CDN somewhere)?
• Should the most common deployments for parse-dashboard not require modification of the source code?

My current (nonfunctional) deploy process is as follows:

• I maintain a private fork of this repo, which I've modified to
  1. add a health check endpoint, and
  2. edit npm start to build the client side assets and put them in the right place before starting the server.
• Deploy with Elastic Beanstalk, which involves: zipping up the project directory (of my private fork), uploading to a EC2 instance, unzipping, and running npm start.

[drew-gross]

Since the dashboard is still in the early stages, we don't have a clear set of guidelines or desired features for deploying to production. The only absolute requirement is that you make the dashboard accessible over HTTPS only, and require a username and password. This is to prevent the master key from leaking.

Being mountable is one approach, but it's also pretty node specific. This might be fine, since the Open Source server is also node specific. That said, once compiled the dashboard can be distributed as a handful of static files + one config file. It would be very easy to put the dashboard assets in a public folder in any webserver, then dynamically generate the config file from the other auth already existing on that webserver.

In general there should never be a reason not to be on master. Not being up to date will result in you missing out on the newest features, and also missing out on security fixes. We haven't had to make any security fixes on the new dashboard yet (either before or after releasing it on GitHub) but it is possible that might happen.

Most likely we will put the dashboard on npm soon, and the npm package will contain only the built files. That would also be where you deploy from. Before we can do that, we'll need to make some small tweaks to our build process (mostly just change the location of certain outputs, and change what is included in the package) and I'd also like the dashboard to be able to notify the user if there is a newer version available, to avoid the situation some projects like Jenkins are in, where the newest version has tons of cool features, but people never find out about them, and don't bother to upgrade. If you'd like to help out with either of those things, that would be very valuable.

I would hope that most deployments do not need to modify any source code.

[yuzeh]

I think it makes sense that the "deliverable" (e.g. what is put in NPM or another package manager) be the compiled assets. People doing deploys off a package.json file (Elastic Beanstalk, Heroku) will have a relatively simple deploy script, and also won't have to worry about compiling the source. It would also give freedom to people who want to run the dashboard on the same server as other services.

Adding reminders client-side sounds like an excellent way to encourage everyone to upgrade. Unfortunately, my browser-side JavaScript is probably not good enough to contribute :\

👍

[drew-gross]

I actually just added code to display the client side reminders and I'm preparing an npm package today.

[yuzeh]

Awesome! I don't have anything else to discuss -- feel free to close this issue.