prod and build scripts question

[rralian]

First off, I really dig this project, thanks for doing it!I love meteor, webpack, and react. My biggest issue with meteor was the way everything is shared as a global. So I was excited to see this project!

I could use a little more direction about the prod and build scripts. So I have a project based on this skeleton. I've asked one of our sysadmins to install this on a server and have it rebuild whenever we merge to master. And I said this can be built simply with npm install && ./prod.

Then he noticed the ./build script and asked about that. And now I'm not exactly sure how this should be run in production. If the app is normally run with ./prod in production, then why do we need a separate ./build script? I'm misunderstanding one of these. Could I get a little hand-holding?

Also, is it possible to update the app in production without downtime? Anything special we need to know to do so?

[AdamBrodzinski]

Sure, so it depends on how you're deploying your app. The webpack part works with any of your current deployments.

If I can get some time soon I want to write a step by step guide for doing this but here's a rough start....

For Meteor deploy:

./prod and let it build, then kill the script with ctrl c. This will create a client and sever bundles and copy it over to the meteor_core folder. Next you can run ./met meteor deploy foo.meteor.com and it will deploy like normal. Note, if you have meteor settings you'll have to enter those in two.

For Modulus it's the same as above but you just use the modulus deploy command. They also require meteor settings to be in an ENV variable which can be echo'd out.

For MUP installs it will be the same as above roughly but I think you need to configure the mup folder to point to meteor_core (let me know if this applies).

However it sounds like you're doing an in house deployment so you would basically deploy like normal but you would do the ./prod first to make sure it's built in production mode. You could prob. copy the prod script to a deploy file and then remove the --watch part so that it only runs once... then from there you can use your CI system to take over.

However if you need to deploy the tarball (same as meteor build) then you can run ./build. If you're going that route and do need a turn key tarball... meteorizer works well for this (from what I tried a while ago).

Also, is it possible to update the app in production without downtime? Anything special we need to know to do so?

This is completely dependent on your deploy setup. It is seamless if you're using modulus. However if you're deploying your own server you need to use forever and other stuff to get it to do that. I would recommend MUP (or MUP X for docker) if you do deploy on your own hardware.... takes a lot of work out of hot-deploys.

Does this help? If I now your exact deploy target/setup that would help clarify things also.

🍻

[jedwards1211]

Huh, I didn't realize people would want to deploy with stuff they got from ./prod. We could make a separate script for that.

[AdamBrodzinski]

@jedwards1211 sounds good! On the copied script I think all we need to do is take off --watch and the part where Meteor boots up.

I've used the ./prod then kill then cd meteor_core then CLI DEPLOY method for meteor.com and modulus with success. Those CLI apps then basically make their own tarball and upload. I presume demeteorizer is the same.... I think they end up doing some other stuff ontop of what meteor build does but I forget at the moment.

Actually i'm wondering how many people are deploying the tarball that is produced? Perhaps ./build should just build the files into meteor_core and ./build --tarball would build a tarball into dist? I think the majority of people use a PaaS CLI tool or MUP deploy over SSH into a box.

Are you able to just deploy the tarball onto EC2 or Digital Ocean? Or do you need to open it up and tweak things? I halfway remember that meteor build needs extra stuff tweaked but am not sure (using demeteorizer. I think it had to do with how it built NPM modules or something.

[rralian]

Huh, I didn't realize people would want to deploy with stuff they got from ./prod. We could make a separate script for that.

@jedwards1211 Well it could just be that I misunderstood the intent of ./prod then. Is that just to get a locally running instance that matches production? If it's not meant for production deployment, could you add a little more content in the readme to explain why/when you would use it? Would be very helpful for us folks that are more front-endy and less dev-opsy.

[jedwards1211]

@rralian right, I can add a note about that. Ironically I've always been a front-end person too :)

[jedwards1211]

@AdamBrodzinski actually I haven't ever deployed a Meteor app to a real-life production server yet...I definitely don't test my apps in production 😄 Feel free to add whatever support you want for that. Also I'm trying to decide how I want to deal with releases so that if we accidentally break anything on master it won't blow up for everyone. One option is to just use the usual GH release mechanism and tell people to go download it from the release page instead of just git cloning. It would be nice if people could retain the ability to merge our updates into their project...but I think that would tend to be complicated anyway? I don't know, what do you think?

[AdamBrodzinski]

@jedwards1211 yea I was thinking about releases too... I'm going to try and pull in changes from my local repo...i'm always bad at cherrypicking in git. i'll tell you how it goes 😆

I imagine keeping a change-log.md file will be most helpful. We could also have a devel branch that's 'working for us' but is not thoroughly tested.

Yea deploying without one of those handy CLI tools is a PITA because you also have to setup forever and things like that. I looked into a bit further and the default meteor build doesn't setup the package.json deps correctly. I've always used this: http://blog.modulus.io/demeteorizer

I'll try and make a PR later that makes a deploy script using the different services.

[jedwards1211]

Yeah cherry-picking can be a bit tough. Plus I don't know if there's any way to try to merge in changes from a repo without forking it.

Do you know if most projects use a devel branch, or just keep the bleeding edge on master?

[tomitrescak]

Guys, so what's the state now on how to deploy the project. I know it's a fast paced thing, but how about a small guide that would explain it? @AdamBrodzinski's PR didn't make it to master. And I would love to know how to do mup or mupx. Ill play with what is in Adams PR with no meteor minification and see. But a guide would help. Thanks

[AdamBrodzinski]

@tomitrescak It's merged 😃

The easiest deploy is meteor deploy yoursite.meteor.com.

With mup you can run ./predeploy and then cd into your meteor_core folder. From here it's the same as the guides on the mup readme. You can automate your process by tweaking the deploy script to prevent having to cd into the directory all the time.

I wish I had time to write a guide but i'm short on time and burnt out... maybe soon 😄

[jedwards1211]

Yeah @tomitrescak I had to custom merge @AdamBrodzinski's PR, and now I converted it to shelljs, but it's in master 😄
I added some very minimal docs to the readme too. The deploy.js script handles building the webpack bundles beforehand, so all one needs to figure out now is the specifics of using mup or one of the other tools.