config in package.json?

[ryanseys]

First of all, cool project! With this kind of tool, it could drastically tear down the barrier of entry for pushing apps to Google Cloud. :sunglasses:

Being out of the loop of node for a while, I'm wondering whether having the config in your package.json is a good idea or recommended practice now? A separate config file will likely give you more flexibility but not sure whether deploy-specific configuration belongs in the package.json. Perhaps you're just using it right now for ease of proof of concept, but in the future might be worthwhile to extract into it's own config file, especially if I want an easy way to deploy to separate systems e.g. gcloud-deploy --config staging.json and gcloud-deploy --config prod.json

[stephenplusplus]

First of all, cool project! With this kind of tool, it could drastically tear down the barrier of entry for pushing apps to Google Cloud.

Thank you! This is what I've wanted for some time. Other cloud platforms make it pretty painless with only Node, so I don't think Google needs to be any more difficult.

Perhaps you're just using it right now for ease of proof of concept

Mostly, and I've been questioning whether it's a good approach or not, so thanks for bringing this up! I think stuffing things in package.json can be reckless, but also can be more convenient for the user.

Supporting different configurations makes sense. Right now, a VM is created for every deploy, but realistically, I'd like to offer total customization of the created instance and be able to re-use them. As these options become supported, config files might make sense.

I also wonder if just allowing configuration programmatically can solve these issues as well:

// deploy.dev.js
require('gcloud-deploy')(__dirname, {
  vm: {
    os: 'ubuntu-14',
    https: false,
    // ... (everything gcloud.compute().createVM() supports)
  }
})

// deploy.prod.js
require('gcloud-deploy')(__dirname, {
  vm: {
    name: 'my-prod-server'
  }
})

Thanks again :)

[ryanseys]

From a dev-ops perspective it makes sense to separate the code that needs to be deployed from the deploy process so that's my gripe on having the deploy config in the package.json. It also means that I must update my package.json in source control whenever I update my deploy process. Programmatic configuration like you described at the end is a tricky balance because suddenly you're re-writing deploy code for every app you have. It would be nice to be able to re-use configuration files and have sane defaults that could even allow me to deploy without any configuration (besides auth).

[ryanseys]

Just jotting down thoughts. Would something like this work with zero config files?

$ npm install -g gcloud-deploy # install it
$ gcloud-deploy login # grabs login info from existing gcloud cli config
$ gcloud-deploy whoami # prints out project-id for a sanity check
$ cd my-app/
$ gcloud-deploy . # deploys my current folder to ubuntu micro vm

[stephenplusplus]

For the person who has several private projects to deploy, they might just be okay with the default config, and prefer plopping a few properties down in {package.json}.gcloud as opposed to worrying about config files. This is kind of where I fall into, and I think a lot of people; makers of quick, debug/test apps where you want to "see what happens" when you try to run it outside of localhost. Supporting the "quick and easy way" might be a more important first milestone to achieve before the methodically-scalable way.

But, the non-trivial use cases are important, too, who would likely be echoing what you're saying. They probably wouldn't want auth stuff and deployment metadata being checked into their app's source control. Maybe they automate deployments after some in-house CI, and that machine can hold some gcloud-deploy configuration files and worry about auth.

I think supporting multiple solutions for different use cases will need to happen; so, package.json stuff, but also config files and programmatic. I should look into how people are using Heroku & similar providers to see what workflow they follow.

RE: The CLI ideas, those look great to me, though I would try not to use the gcloud sdk as much as possible. I think being Node-only is important for this project.

[ryanseys]

Cool. Yeah Heroku came to mind here. It's really nice because they use a git interface to deploy. So deploy is as easy as git push heroku master once you give them your public key and set up an "app" on their end which gives you a git remote to push to. Something like this might be better:

$ gcloud-deploy add-key ./key.json # copy key to own ~/.gcloud-deploy/ config folder.

Then you're all set up with that project and gives the ability to have multiple projects. You would then either explicitly declare which project-id you want to use for a project, or if you just had one, it could use the default.