Allow CLI environment to be optional / add default environment

[timkelty]

Making this issue here to brainstorm the best way to handle this.

Here's what I'm currently thinking:

• Allow setting a "default" environment statically in shipit.initConfig.
  • Environment set in the CLI command would override.
  • This would allow for workflows where certain branches deploy to certain environments by default (e.g. master → production, development → development). The user could set the environment in shipit.initConfig to a function that parsed your current git branch and returned the matching environement. Of course, they could always override it by passing an environment in the CLI
• If no environment set in either CLI or shipit.initConfig, trigger an inquirer choices prompt.

[gregberge]

@timkelty I am not OK with the magic that choose the environment from the current branch, I think it can be dangerous. I don't see the gain of not passing the environment in the CLI, you specify explicitly where you want to deploy, each time.

Also it's difficult to make it optional because it's the first arguments and others are tasks.

About branches, it's already possible to specify a custom branch by environment in the config.

If no branch is setted (null or undefined) I am OK to trigger an inquirer to choice the branch to deploy (it's relative to shipit-deploy).

[timkelty]

@neoziro I'm not proposing the branch to environment magic would actually be part of Shipit. Just that you'd be able to specify a default environment in your config, like you can with branches.

That would allow someone to pass their own method to that config property to do any magic they wished.

But I get that it is difficult because of the arguments - hence there not being a PR :)

[timkelty]

Perhaps a consideration for 2.0 could be to pass the environment as an option flag and the other args are the tasks? e.g. shipit deploy -e staging, shipit deploy --environment staging

[gregberge]

@timkelty I prefer to keep the environment as a requirement, I don't see the benefit of having a default environment.

[timkelty]

Ok, sounds good.

[halfdan]

@neoziro The benefit is that with a sane default (e.g. staging) running multiple commands becomes easier. People may deploy to staging many times before doing a single production deploy. This is what most other tools do by default (i.e. rake, ember).

Maybe we can re-evaluate this for v2.0.0?

/cc @timkelty's

[gregberge]

@halfdan I am not for a default environment, I think is more explicit to do shipit run staging deploy than to do shipit run deploy.

[timkelty]

Anyone interested in this type of functionality, see https://github.com/timkelty/shipit-captain

/cc @halfdan