draftbit / exp-deploy-cli Goto Github PK

tests are a great way to make sure i don't let silly bugs slip through 😄

Given a release, give the user an interactive prompt to be able to instantly rollback to an old release and then deploy it. Rollbacks will be based on git tags / releases

In the readme it states:

"if you'd like to store environment variables, create a config object next to expo within app.json:"

but in the code seems no support for that and also expo does not mention that neither.

So, does this really work?

spawnAsync only shows you the results when they're finished. We should show the normal exp deploy process

config:set will set the environment var across all three files
config:get will show you ALL the env vars set under config

config:get --production will only show production
config:get --staging will only show staging

config:set --production will only set production
config:set --staging will only set staging

Releases command that will read exp-releases.json and show you all of the releases you've deployed. This will most likely be based on a git tag / release.

After installing expo-deploy cli and building config/exp-production.json, /config/exp-development.json, running command "exp-deploy --env production" will prompt same in terminal as command "exp-deploy --help".

Running command "exp-deploy --env staging" will show: "app.json and/or config don't exist. Are you sure you're in the right directory? Did you run [exp-deploy config] first?"
Note: I am running this command from root direcotry where is app.json and config/

Every time a user runs exp-deploy with an environment, create a new git tag. This can be based on npm version patch or some other philosophy

There's a really good chance that your app.json, ./config/exp-production.json, './config/exp-development.jsonwill go out of sync.sync` will diff the three files and ask you interactively what to update

Save release history into a exp-releases.json file or something similar so users can rollback to a specific version.

it expects a node version >= 8. Is this really needed?