Proposal for a `deploy` command

[indirect]

I think it might make sense to have a deploy command, with the aim of eventually replacing the install --deployment flag.

Rendered

[indirect]

After some further noodling on this, I'm not 100% sure but my current leaning is towards removing deployment as a setting, and ignoring frozen, and supporting deployment mode entirely and only via the deploy command. my experience in the past with confused users is that they want hand-run commands to work, and they want CI and automated deploys to blow up.

If the deploy command is the only time we apply the safeguard, you get all of the benefits of the ci/deploy guard, because it always uses that command, but you also get the "expected" outcome of devs still having their commands works when they run them by hand, either for debugging on a server or because they ran deploy once on their local dev. It was actually a huge problem where devs would use --deployment locally to see how it worked and then get stuck because it was unclear how to undo the config they didn't know they had set.

[segiddins]

It was actually a huge problem where devs would use --deployment locally to see how it worked and then get stuck because it was unclear how to undo the config they didn't know they had set.

But if you have to explicitly run a bundle config deployment true, they will have set it, and it's pretty easy how to reverse that (delete the setting or set it to false)

[indirect]

I'm talking about the deploy command here, though. If the deploy command sets the deployment config to true, it recreates this problem. Maybe we want to provide a deployment config that is exclusively opt in, and running the deploy command doesn't set the config to true?

[segiddins]

Sure, so the bundle deploy command would just do Bundler.settings.temporary(:deployment => true) ?

[indirect]

Yeah. With that as the blessed workflow, I'm pondering out loud if it then becomes possible to get rid of the permanent config setting entirely, since it has historically been a source of much confusion and support effort.

[segiddins]

Yeah. With that as the blessed workflow, I'm pondering out loud if it then becomes possible to get rid of the permanent config setting entirely, since it has historically been a source of much confusion and support effort.

I guess it would be? But I don't know that we'd want to, since it also serves as a guard when running Bundler.setup, and I think the confusion would largely be gone when it had to be set explicitly?

[indirect]

That makes sense. I wonder if anyone will want to use the setting if a deploy command is available...

I guess let's plan to soften the transition by offering a deployment config, but lead with the deploy command as the primary new mechanism and see what feedback we get. 👍🏻

[indirect]

Something like this seems to be what NPM settled on as well. This week they launched a dedicated command, npm ci, for installing directly from their lockfile. http://blog.npmjs.org/post/171556855892/introducing-npm-ci-for-faster-more-reliable

[indirect]

Final comment period starts here! Please give us your feedback by July 7.

[hmistry]

I haven't used bundler install --deployment command so I'm not sure of all the config details discussed here. However, from a user perspective, I strongly agree that all deployment functions should be moved to bundle deploy and if you need to differentiate production vs local, I suggest to have an optional param like bundle deploy --local to handle it. I agree there should be no extra steps to change config settings to run a local deploy or whatever.

One other thought I have is, it might be nice to have a --dry-run option where it runs through all the checks whether local or production. Internally it can be mapped to bundle check as you mentioned users might run that before deploy.

[simi]

Is there still any interest in this RFC?