Some people have asked a few questions about jitsu support for software workflows or migration paths (e.g. dev, testing, staging, production).
One solution that comes to mind is to possibly have a jitsu.conf file in the project directory that can override settings in the package.json file.
With the above file in the package directory one might be able to call jitsu deploy test to deploy to the test settings, if the target doesn't exist in jitsu.conf provide either a prompt if there are deploy targets, or a message that no deploy targets exist.
jitsu deploy test
A few concerns I have regard possible validation (possibly a script that gets executed that checks the current app to see if it is production worthy -- for git, this could be a check to see if we are on the master branch), and in large organizations there is usually security associated between the migration paths (e.g. testers don't have access to deploy to prod without the right credentials).
Really like the proposed implementation! Might be worth thinking about the version number as well. Would deploy attempt to update the conf file or the package file?
I should mention, I know this is marked as low priority, but this is a really common requirement for developers and currently is something that nodejitsu has no particularly elegant way of handling. Heroku makes it easy because it's based on git deployment, so you simply push your branch to the relevant app's git remote url. I dropped into #nodejitsu on IRC to ask about this last night and noticed that shortly after somebody else came in and asked the same question, which suggests to me that there may be numerous other people evaluating nodejitsu and hitting this as an issue. I'll be watching closely to see what happens.
+1 for having support for different staging targets.
As mentioned in the issue - it is vital that nodejitsu provides something of that kind.
I would propose to have the ability to switch staging On/Off for example in the nodejitsu dashboard per app.
After switching it to 'On' a predefined set of staging targets are generated. For example: 'dev', 'testing', 'production'.
Each stage gets prepended as a subdomain of your main subdomain (e.g: helloworld.thomasfr.jit.su) for instance: 'dev' gets dev.helloworld.thomasfr.jit.su. Each one of the stages can be deleted, renamed and modified and each one has its own subset of configurations like NODE_ENV=development etc. The main subdomain (helloworld.thomasfr.jit.su) is automatically and unchangeable the production staging target. So adding and removing any staging target has no effect of the production environment. When implementing staging targets as subdomains of your main app it is also easier to implement authorization as @blakmatrix said. Testers are not allowed to deploy to prod and unauthenticated users can not access test.helloworld.thomasfr.jit.su or dev.helloworld.thomasfr.jit.su. Maybe protect it with http Basic Auth over SSL!?
I understand the desire to make these sorts of things easier, but I'm not entirely convinced that this is the right approach.
I'm seeking other opinions internally, so I'll keep this guy open for now.
okay, after discussing this, here's my stance:
pkg-mixin package.json prod.json
The idea for managing package.json files on a environment/target basis is not a bad idea! Just not something jitsu should do.
Any particular reason nodejitsu has avoided git-based deployment?
@axefrog +1 Curious as to why that is as well.
@axefrog @yoshuawuyts Quite a few indeed.
First of all, we wanted to avoid friction. Sometimes you just want to push code to production and not to your repository. jitsu deploy is easier than git commit && git push.
git commit && git push
Second of all, running a scalable git server is hard. You need to handle public keys, store lots of data and such. Snapshots are just easier.
@indexzero might shed some more light on that, he architected the stuff from the beginning.