Feature Request: Deploy to different targets (staging, production, etc.)

[arunoda]

Feature Request: Deploy to different targets (staging, production, etc.)

[arunoda]

How mup handles this by using multiple folders with seperate config files.
You can use same app path in multiple mup projects.

Hope that helps.

On Sunday, January 5, 2014, Sacha Greif wrote:

I think my biggest feature request would be the ability to add multiple
deploy targets in the JSON file.

I know you're probably already thinking about it, but I just wanted to put
in a vote :)

—
Reply to this email directly or view it on GitHubhttps://github.com/zodern/meteor-up/issues/14
.

Arunoda Susiripala

@arunoda http://twitter.com/arunoda
http://gplus.to/arunodahttps://github.com/arunoda
http://www.linkedin.com/in/arunoda

[SachaG]

Oh, so you mean multiple folders that only contain the mup.json file? I think that's fine for now, but ideally maybe a single-folder solution would be better?

[arunoda]

But it is better move separate configurations to stay diff folders. Since settings.json, env and other files are difference.

[SachaG]

That's a good point… In that case, I wonder if it would be possible to store all your different environment's Meteor settings in mup.json as well, and then when you deploy MeteorUp would pick the right one for the target environment and copy over the right settings.json file?

Anyway I'm just thinking out loud, the current solution works well too. Maybe just add a little more information about it in the docs?

[arunoda]

Yep. I agree. Need more on docs.
What is currently available for this is not enough.

Hope you can help me out :)

[stephentcannon]

Hmmm, one issue with the strategy of having a different directory is that you cannot run multiple mup deploy at same time.

So for example, today I tried to run 3 mup deploy's to 3 different target enviros. They all have different env settings for mongo, etc...

They conflict during the bundling process and of course one wins.

That could be solved via random build process in deploy.sh I think or a single deploy with multiple targets as the targets may have different env settings and settings.json

Seems wasteful to do 3 build bundles when all that is changing are environment settings.

[arunoda]

Good point, if you are deploying once for few different targets.
I not disagree with this, but we need to come up with a good way to do this.

I don't like messing up with mup.json file for adding more targets since it is the target definition. May be we can use multiple files.

[stephentcannon]

There are two aspects to the problem.

1. setup
2. deploy

It seems setup is somewhat covered in the sense that you can define what is getting setup and then an array of servers.

The problem becomes the deploy as although the source code of the app will always be the same location the target env settings and json.settings may be different.

An example is a SAAS application that all have same source code build but different mongodb instances. Not ever SAAS strategy puts all instance data in the same database. In fact, the 10gen articles sometimes recommend against it, especially if you think you may have to scale some clients faster than others, or they are big clients or they may want to take ownership of their data.

Same would be true for other env settings like email possibly.

Personally I gotta think about this for a couple of days. Always best to let ideas stew for a bit.

[stephentcannon]

@arunoda I actually encountered this today. I have 3 production installs. All 3 use the same application but different MongoHQ databases. Therefore all 3 have different env. As well, I went to implement your new project APM and I don't want them all reporting into a single application. So, I was going to use settings.json but same problem the MUP doesn't support different target enviros. MUP supports different servers but assumes they all have the same exact setup, env and settings.json. It seems wasteful to bundle for each server when the only thing that is different is the env and settings (and maybe sometimes the setup in some instances). So, now I have to run a mup deploy against 3 different target machines which does 3 bundles. Imagine if that was 50 servers how long that would take. Any ideas?

[arunoda]

I agree with your usecase, since when I designing mup there was no use case
like that.

We only need to deploy for a specific target at once.

Multiple server support is to deploy multiple servers with same config
(horizontal scaling)

So this is what I prefer.

• allow to define the settings.json directly inside mup.json. Not a
  seperate file.
• mup.json is the default
• but we can allow as many as mup.json(with diff name) files taken from the
  argument.
• in the mup side, we can check for file path and cache bundle between
  mup.json deploys.
• when displaying logs prefix the name of mup.json.

How is this?

On Monday, March 3, 2014, steeve cannon [email protected] wrote:

@arunoda https://github.com/arunoda I actually encountered this today.
I have 3 production installs. All 3 use the same application but different
MongoHQ databases. Therefore all 3 have different env. As well, I went to
implement your new project APM and I don't want them all reporting into a
single application. So, I was going to use settings.json but same problem
the MUP doesn't support different target enviros. MUP supports different
servers but assumes they all have the same exact setup, env and
settings.json. It seems wasteful to bundle for each server when the only
thing that is different is the env and settings (and maybe sometimes the
setup in some instances). So, now I have to run a mup deploy against 3
different target machines which does 3 bundles. Imagine if that was 50
servers how long that would take. Any ideas?

—
Reply to this email directly or view it on GitHubhttps://github.com/zodern/meteor-up/issues/14#issuecomment-36465689
.

Arunoda Susiripala

@arunoda http://twitter.com/arunoda
http://gplus.to/arunodahttps://github.com/arunoda
http://www.linkedin.com/in/arunoda

[stephentcannon]

I think I get it.

settings.json will be in mup.json file

I imagine that mup will dirscan and run each file it finds?

if the file points to an already file path/cache bundle it doesn't do the long process of bundling, etc...

AND mup json files can still support more than one server

This provides solution for horizontally scaling where the envs and settings are the same across machines AND supports multi-target deployment where the envs and settings are different.

BTW, I noticed you can run setup against an existing machine and the mongo database stays intact and existing app deploy like when upgrading or downgrading node. On another topic, which would be another issue, do you think this needs a Mongo version config like the node one?