Application development usually goes through at least three environments:
- Integration (development): your laptop, your developers’ laptops. This is where you collaborate on the building of an application, work on new features, fix bugs, etc. In Meteor, this is where you (and your co-developers) use the
meteor commands and work on branches using
git and GitHub.
- Staging (QA/UAT): Usually a completely separate server (or container, VM, or instance) which matches your live environment in all respects except public access. No development work is done here: it’s used only to prove it works. (In a continuous delivery pipeline, you would employ a GitHub hook to trigger the build server to pull the release from GitHub and do a
meteor build onto the staging server where it can be tested.) At this stage your app on the staging server is a pure NodeJS app - there is no
- Live (production): When your app is proven to work in staging, you make a GitHub release, which (in a continuous delivery pipeline) triggers the build onto the production server in the same way as on staging.
Each of those environments can exist in multiple different places. Normally, staging and live are externally hosted. For small, in-house (intranet type) applications, they could run on any server able to run NodeJS within your infrastructure.
Clearly, for small applications, you can simplify the requirements, and build manually where needed. However, the key points are that you continue to use
git during development, separate your development and production environments, and you do not run your production application with the