Skip to content

Project Overview (Development)

Sohaib Iftikhar edited this page Dec 16, 2019 · 1 revision

1. Build System

The build system is written using sbt. It is composed of two projects:

webui

Based on an AutoPlugin we have our own YarnPlugin. This defines commands for the webui project that can be seen in the autoImport object inside the object YarnPlugin.

server

This is Play project which also makes use of the DockerPlugin to push builds made on a branch to be pushed to dockerhub.

2. Backend

Broccoli uses Play 2.6.X at the time of writing this. The interface to the HTTP is managed through controllers. For communication other than the HTTP API we use the controller that is defined in WebsocketController. The data is structured in case classes that are placed in models. The logic for handling user requests is under services with the primary service being NomadService that interacts with Nomad. There is an additional HTTP module for performing GET requests to Nomad that is handled through the NomadHTTPClient. The storage for instances is configurable and can be configured to work with FileSystemStorage or CouchDBStorage. Currently, in production, we use FileSystemStorage. The type of storage you want to use can be modified in application.conf under play.modules. See the reference.conf for more details.

3. Build system frontend

We use webpack for building the front end. It picks up the webui/src/index.js and compiles it to a js file inside dist. There are two configurations that we use for webpack. webpack.config.prod.js is used for a normal build. If you want a development sessions with the webpack development server you can use the webpack.config.js. The development configuration also defines a devServer that runs on 8080 and forwards API requests to the Play server on localhost:9000 but serves javascript/css files through the webpack-dev-server. This allows for hot loading frontend modules. The setup can be used using yarn start from the webui directory.

We also use yarn as the package manager for the frontend. The package configurations are defined inside the package.json in webui. Since we use Elm as a front end language the packages related to Elm are handled through elm-github-install. The configuration for these packages is defined in elm-package.json.

4. Frontend

We use Elm as a frontend language. Currently, we are using version 0.18.x. Elm follows an MVC pattern where we have the model, view and update (controller) functions. These defined inside Main.elm. Since we use WebSockets for communication with Broccoli we also have an elm module that is handling WebSocket messages and applying correct decoders based on the message type. These are defined in Ws.elm. The frontend also follows the same pattern as the backend for data objects being defined under models. Views are generated recursively with the bigger views like BodyView encapsulating smaller views like InstanceView which further encapsulate smaller views like the InstanceDetailView etc.

5. Tests

Broccoli uses both unit and integration tests. Unit tests for the backend are using specs2. Unit tests for the front end use elm-test. It is generally recommended that for every function or change added to Broccoli there should be corresponding tests added to the backend and the frontend.

To use the integration tests we first build a docker image using the Dockerfile in test/docker. Once we have a built docker image we are ready to run the integration tests. The integration tests are currently defined in two ways. There are some integration tests that are defined through the sbt module IntegrationTest that looks for tests under server/src/it/scala. We have a docker context called the BroccoliDockerContext that takes up the responsibility of spinning up and tearing down running instances of Nomad, Consul or Broccoli. The tests execute within the spawn and tear down functionality. The other integration tests are written under in http-api-tests. These tests use simple curl commands to query broccoli and verify the result based on preconfigured text files. These are written in a simple format that is defined through the http-api-tests library.

6. Continuous Integration

Since Cluster Broccoli is an open-source project it uses Travis for CI. The configuration for Travis builds is defined under travis.yml. This includes building broccoli, running unit and integration tests, building the docker image and in case of commit to a branch pushing the docker image to docker hub. It is the responsibility of the developer and the reviewer to ensure that commits are not merged to master until all tests are green. Since the build is done in a step by step manner and docker is the last step, no image is pushed to docker until all tests are green.

Clone this wiki locally