aviator-multi-tenant v0.0.0

Aviator Multi-Tenant Server

• Installation
• Core Concepts

The application is the autopilot server for multiple aviator tenants.

ten·ant

1. A brand or vertical that has its own styles and business rules, separated by domain.

Installation

Required Prerequisites

You need the following tools installed to build and run the app locally:

• nginx
  • Install directly or with brew
  • Verify your installation with $ nginx -t.
• nvm: verify with $ nvm --version

Execution

All dev and build tasks are invoked via Make. Unless otherwise noted, most of our $ make {target} recipes will automatically run their prerequisite tasks, such as installing npm dependencies or performing a build for the development environment.

Common development tasks

# run server in watch mode for development
$ make run-dev

# run server in watch mode for development,
# but use non-CI runtime configuration and data
# default `NODE_ENV` value if unset is `ci`

# Staging
$ NODE_ENV=staging DEV_ENV=production make clean run-dev

# Production
$ NODE_ENV=production DEV_ENV=production make clean run-dev

# run tests
$ make test

Show a list of available make targets

# show list of available `make` targets
$ make
# -OR-
$ make help

CSS Workflow

Stylesheets are imported from the brand-identity package located in the Component Library

Filename conventions

• Use initial capital CamelCase to designate a module that exports a class or Component.
• Use extension prefixes for non-source files to designate intended file usage.
  • *.spec.* test files
  • *.spec-utils.* test helper methods
  • *.integration.* integration test files
  • *.fixture.* test fixtures
  • *.entry.* entry points for Webpack. Outputs follow these rules:
    • Presenters: src/{presenter}/client.entry.* -> build/static/presenter-{presenter}.js
    • Client bootstrapper: src/bootstrap-client-app.entry.js -> build/static/bootstrap-client-app.js
• For Sass files, see CSS Workflow.
• Use lowercase, hyphen-separated filenames for all other cases.

Folder Name conventions

• use - separated lower-case words: plugin-base-page, presenter-contributors
• Use the prefixes for folders where appropriate:
  • presenter-*: presenter
  • plugin-*: other plugins
  • router-*: presenter
  • tenants/{slug}: tenant

Code Conventions

• Prettier is used to format code. This happens automatically for any touched file prior in a precommit git hook. The easiest way for this not to affect workflow is to install the prettier integration for your editor and set it to "format on save".

Builds and Deployment

See the Infrastructure doc!

Pre- and post-merge builds

We require 💯code coverage, but we also want each step of our workflow to be as fast as possible. To do that, we remove redundant steps from our hosted builds:

• Pre-merge, each PR must pass in CodeShip, which runs our linters and test suite.
• Post-merge, the Departures build skips tests for time savings, as tests are guaranteed to have already run during code review.

Testing

See the Testing doc!

Debugging

Use the React Developer Tools to inspect the props of the application in your browser. This is equivalent to seeing the data that would be rendered as JSON when requesting your endpoint with Accept: application/json.

Logging

Any errors sent to the base workflow's errorHandler are sent to Sentry.io along with a stack trace and many other details to help you debug the problem.

Non-production Dashboard: https://sentry.io/cn-digital-technology/multi-tenant-nonproduction/ Production Dashboard: https://sentry.io/cn-digital-technology/multi-tenant-production/