Ⓒ Copyright 2016, Martin Bramwell, Warehouseman Last edits : 2016/01/29
These explanatory scripts, videos and slideshows, will start your Meteor development infrastructure immediately with: package development, testing, documenting, logging, code style linting and continuous integration and deployment
This is not strictly part of the tutorial, but I created a Docker image that should make this step very easy for you.
We start off with a fresh Ubuntu 14.04 LTS virtual machine and install all the platform dependencies. These are global installs requiring 'sudo'. Subsequent sections should not require 'sudo'. The script shown can run to completion without intervention, or stop at intermediate steps to view explanations.
Towards the goal of "packages-only-apps", we are mainly interested in version control of each distinct package, but we still need a 'do-nothing' app in which to instantiate the packages.
So, we'll prepare a Meteor project and store it in GitHub.
This section shows the steps needed to begin testing a Meteor package.
We'll prepare a package, secure it in GitHub and run preliminary tests with TinyTest in the browser and on the command line.
If you want reusable components, especially if you are working with one or several teams, it's very important to ensure consistent styles and documentation standards from all contributors to all your projects. In this and the next section we'll set up an environment where standards conformance is easy.
The first element is linting with esLint, run in the editor for instant feedback as well as on the command line so conformance can be published and monitored as part of continuous deployment.
The second part about code quality exploits two powerful tools: jsDoc and "GitHub Pages".
We'll put together a mechanism for easily documenting code files and then publishing them as a browsable manual, automatically, and hosted, free of charge, on GitHub.
This section expands on your workstation toolbox to include working with continuous deployment in the cloud. It covers everything involved in setting up linting, automated documentation, unit testing, version control, end-to-end testing and continuous delivery in-the-cloud. So, while a working system is integrated and delivered continuously, it is not yet continuously deployed.
A vital piece of application architecture is scaleable logging: run-time logs that track critical server-side activity at appropriate levels of detail. We "require" Bunyan, a toolkit for NodeJS that focuses on very flexible logging with JSON output, that can be readily archived and subsequently "mined", for example, for usage patterns.
Here we create a complete working, tested, documented Meteor package from a pre-exising NodeJS module. This step also introduces the "impedance mis-match" between the synchronous layer that Meteor builds on top of the asynchronous substrate of NodeJS.
To close the loop on all the preceding development stage parts we now bring the online documentation up-to-date and automate end-to-end testing of our package in-the-cloud; such that interested users can quickly get started using it.
We build our project as an Android app, place it into our project as a download link, then deploy it to Meteor's servers. We use our understanding of that to complete our CI script so we can do it all automatically in CircleCI, every time we push a commit to GitHub.
You cannot run the Android emulator in the Docker machine we created earlier. It's very slow anyway. In this video I show how to install Android KitKat x86 in a Qemu/KVM virtual machine and then connect to it from Meteor in order to "run android-device". You get most of the advantages of the emulator and most of the advantages of connected physical devices, with the downside of neither.
Please use only in accordance with The License.