Deployment feature for workflow/migration paths #292

Closed
blakmatrix opened this Issue Aug 5, 2012 · 8 comments

Projects

None yet

6 participants

@blakmatrix
Contributor

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.

{
  "test":
    {
      "name": "blakmatrix-geoip-test",
      "subdomain": "blakmatrix-geoip-test",
      "domains": [
        "dev.blakmatrix.net"
      ]
    },
  "staging":
    {
      "name": "blakmatrix-geoip-staging",
      "subdomain": "blakmatrix-geoip-staging",
      "domains": [
        "stage.blakmatrix.net"
      ]
    },
  "prod":
    {
      "name": "blakmatrix-geoip",
      "subdomain": "blakmatrix-geoip",
      "domains": [
        "blakmatrix.net",
        "www.blakmatrix.net"
      ],
      "scripts":{
        "postdeploy":"node scripts/notify_twitter.js"
      },
      "analyze": false
    }
}

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.

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).

@axefrog
axefrog commented Aug 6, 2012

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?

@axefrog
axefrog commented Aug 6, 2012

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.

@thomasfr

+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!?
Kind regards

@jfhbrook
Contributor

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.

@jfhbrook
Contributor

okay, after discussing this, here's my stance:

  1. We will not be implementing this in jitsu.
  2. You should implement this as a small node application (pkg-mixin package.json prod.json) or using tools like grunt.

The idea for managing package.json files on a environment/target basis is not a bad idea! Just not something jitsu should do.

@jfhbrook jfhbrook closed this Sep 24, 2012
@axefrog
axefrog commented Sep 25, 2012

Any particular reason nodejitsu has avoided git-based deployment?

@yoshuawuyts

@axefrog +1 Curious as to why that is as well.

@mmalecki
Contributor

@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.

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment