1

Can someone help me understand the deployment process of meteor app?

I used meter for a long time, once i began the development of meteor app from scratch on the same machine (VPS) that i was thinking to use for hosting the app. I also built localy another app, and just copy/paste the whole app, after i finished it, on another machine for hosting.

In both ways it worked as expected.

Can someone explain please what is the need of MUP? And similar things for uploading. Also the bundle file, what is it for? Isen't it just a "zip" file of your app? I mean if i just zip it manually (with rar for example), the result will not be the same??

And i think it's simple enough to setup the server for meteor app on your own.

Thank you in advance.

Robert
  • 190
  • 1
  • 10

1 Answers1

2

Yes, you can run meteor simply by calling the meteor CLI in your source folder, but there are SEVERAL things that actually building and deploying does.

First, running in "development mode" causes the code to constantly look for changes in the code to redeploy. This takes up resources...resources that cost real money when deployed on something like AWS or other cloud services, not to mention it takes resources away from doing real work.

On top of that, the build is optimizing the code, running minimizers, transpilers, etc. This is done real-time when running in dev mode, which again takes up resources.

Finally, dev mode runs an internal MongoDB, as apposed to a full MongoDB install. The full install will, as far as I am aware, outperform the "embedded" version, plus it allows you to run it on a separate server, which again frees resources.

Performance aside, automated build and deploy is preferred over manual copy/paste. Any time a human has to manually setup something, it is BOUND to fail at some point. We are not good at repetitive tasks over the long haul. In my 17+yrs as a professional developer I have been part of MANY installs, both in production and non-production. I can tell you that the automated installs were WAY less likely to fail over time over the meat-installs (installs that require a person to actually do them). We tend to not do the same steps over and over, and as a result things are different each time.

In my personal Meteor development I have even taken to using automated Continuous Integration servers to do ALL my deployments, both for Dev and Prod. I setup the scripts one time, point my CI server to my repo, and it monitors it for changes. When I update code and push to my GIT repo...BOOM! CI server takes over, pulls the new code down, builds it, tests it, and if all looks good deploys it. MUP has been instrumental in getting that process automated since it handles a LOT of the heavy lifting. And if anything fails in the build or deploy, I get an email notification and simply go peruse the logs to see what happened. I use the latest experimental MUP build that deploys via Docker images, which is nice because now I can add servers easy-peasy to my cluster at any time.

And since I already figured out how to automate one project via MUP and Jenkins (my CI server), it's mostly copy/paste and update some configs for my other projects.

CodeChimp
  • 8,016
  • 5
  • 41
  • 79
  • 1
    I forgot to mention: MUP and MUPX are not the only tools you could use to automate your deploy, BTW. They are just the easiest to setup for Meteor, IMHO, since they "know" meteor. Others to consider would be Grunt, Gulp, and even Webpack to name a few. Grunt and Gulp are more scripting tools, whereas Webpack, to me, works more like Meteor's own install/build api in that it tries to package things as apposed to simply running a script of sorts. – CodeChimp Aug 17 '16 at 17:51
  • Thank for your answer. Could you provide please some instructions or some links about how to achieve this "CI server takes over, pulls the new code down, builds it, " I mean how to setup the CI server for updating the app. That was actually one of the reasons i was avoiding the "build" command. I had no idea how to make changes to the app after everything will be minified. – Robert Aug 19 '16 at 07:50
  • 1
    Well, I use Jenkins, but there are lots of CI server apps out there. In my case, I setup a polling trigger to watch a particular branch of my GIT repo, then I use a simple SSH build step that calls MUP to perform the build. I have 2 MUP settings files, one for Dev and one for Prod. I also have a build step that runs Sonar for auto code reviews. All of this is pretty well documented online, and entire books have been written. If you plan to do consulting, I'd highly recommend a fully automated process like this. – CodeChimp Aug 19 '16 at 13:35