App Meter manuell bereitstellen VS mup

Question

Kann mir jemand helfen, den Bereitstellungsprozess der Meteor-App zu verstehen?

Ich benutzte Meter für eine lange Zeit, sobald ich die Entwicklung der Meteor-App von Grund auf auf der gleichen Maschine (VPS) begann, die ich dachte, um für das Hosten der App zu verwenden. Ich baute auch Localy eine andere App, und kopieren Sie einfach die ganze App, nachdem ich es fertig, auf einem anderen Rechner für das Hosting.

In beiden Fällen funktionierte es wie erwartet.

Kann jemand bitte erklären, was die Notwendigkeit von MUP ist? Und ähnliche Dinge zum Hochladen. Auch die Bundle-Datei, wozu dient sie? Isen't es nur eine "zip" Datei Ihrer App? Ich meine, wenn ich es nur manuell zippen (mit RAR zum Beispiel), wird das Ergebnis nicht das gleiche sein ??

Und ich denke, es ist einfach genug, um den Server für Meteor App auf eigene Faust einzurichten.

Vielen Dank im Voraus.

Answer 1

Ja, Sie können Meteor einfach ausführen, indem Sie die meteor CLI in Ihrem Quellordner aufrufen, aber es gibt mehrere Dinge, die tatsächlich das Erstellen und Bereitstellen tut.

Zuerst im "Entwicklungsmodus" ausgeführt wird der Code ständig nach Änderungen im Code für die erneute Bereitstellung suchen. Dies beansprucht Ressourcen ... Ressourcen, die bei der Bereitstellung auf AWS oder anderen Cloud-Diensten echtes Geld kosten, ganz zu schweigen davon, dass Ressourcen keine echte Arbeit mehr leisten.

Darüber hinaus optimiert der Build den Code, läuft Minimizer, Transpilers, etc. Dies geschieht in Echtzeit im Dev-Modus, die wiederum Ressourcen verbraucht.

Schließlich läuft im Dev-Modus eine interne MongoDB, wie bei einer vollständigen MongoDB-Installation. Die vollständige Installation wird, soweit ich weiß, die "eingebettete" Version übertreffen, und Sie können sie auf einem separaten Server ausführen, was wiederum Ressourcen freisetzt.

Abgesehen von der Leistung ist automatisiertes Build und Deploy dem manuellen Kopieren/Einfügen vorzuziehen. Jedes Mal, wenn ein Mensch etwas manuell einrichten muss, ist es an einem bestimmten Punkt nicht mehr möglich. Wir sind auf lange Sicht nicht gut in sich wiederholenden Aufgaben. In meinen 17 Jahren als professioneller Entwickler war ich Teil von MANY Installationen, sowohl in der Produktion als auch in der Produktion. Ich kann Ihnen sagen, dass die automatisierten Installationen WAY weniger wahrscheinlich im Laufe der Zeit über die Fleisch-Installationen fehlschlagen (Installationen, die eine Person benötigen, um sie tatsächlich zu tun). Wir tendieren dazu, die gleichen Schritte nicht immer wieder zu wiederholen, und als Ergebnis sind die Dinge jedes Mal anders.

In meiner persönlichen Meteor-Entwicklung habe ich sogar automatisierte Continuous Integration Server eingesetzt, um ALLE meine Implementierungen sowohl für Dev als auch für Prod durchzuführen. Ich richte die Skripte einmal ein, richte meinen CI-Server auf meinen Repo und überwacht ihn auf Änderungen. Wenn ich Code aktualisiere und zu meinem GIT Repo schiebe ... BOOM! Der CI-Server übernimmt, zieht den neuen Code herunter, baut ihn auf, testet ihn und wenn alles gut aussieht, entfaltet er ihn. MUP hat dazu beigetragen, diesen Prozess zu automatisieren, da es eine Menge schweres Heben handhabt. Und wenn etwas beim Build oder bei der Bereitstellung fehlschlägt, erhalte ich eine E-Mail-Benachrichtigung und gehe einfach durch die Logs, um zu sehen, was passiert ist. Ich benutze den neuesten experimentellen MUP-Build, der über Docker-Images bereitgestellt wird. Das ist nett, weil ich jetzt jederzeit Server zu meinem Cluster hinzufügen kann.

Und da ich bereits herausgefunden habe, wie man ein Projekt über MUP und Jenkins (mein CI-Server) automatisiert, ist es meist Copy/Paste und einige Configs für meine anderen Projekte zu aktualisieren.