ez-Dashing is a customizable free dashboard tool for agile development team. The project is very young but in active development. I contribute to this project during my free time, I am aware that many things could be improved. Feel free to contribute !
Guidelines
- Responsive
- Configurable
- Ready to use
Tech Stack
The online demo shows a running dashboard (release 1.0.0) configured to consume online public API (without authentication). Go on http://demo.thorpora.fr/ez-dashing/
The docker demo show a running dashboard (development build) configured to consume a mocked API. This demo is more complete because there are mocks for everything.
docker run --rm -it -p 8081:8081 --name ez-demo -t ylacaute/ez-dashing:demo
The first screenshots below is exactly what you should see.
Go on http://localhost:8081
You can directly start to use ez-Dashing by pulling the production docker image. You just have to define your json configuration.
docker run --rm -itp 8080:8080 --name ez-dashing -v /ABSOLUTE/PATH/TO/CONFIG/DIR:/ez-config ylacaute/ez-dashing:1.0.0
Go on http://localhost:8080
Please note that your config directory:
- MUST be in absolute path for Docker
- MUST contains 'server.properties' and 'dashboard.json' (check sample config directory in the project)
DEPRECATED
If you need ez-Dashing in production but without Docker, you will have to package it manually.
# BUILD FOR PRODUCTION
./ez.sh build-prod
# START FOR PRODUCTION (LOCAL)
./ez.sh start-prod <dir>
# More options here
./ez.sh -h
If this not satisfy your needs, you will maybe have to create scripts by yourself.
But keep in mind you should have no reason to start server like that, please use Docker for production.
Define a dashboard.json configuration file, composed of the sections below:
- env: global variables which can be used anywhere in the configuration
- server: server config, you currently can't touch this part
- theme: choose your favorite theme ("default", "black", etc)
- dataSources: refreshable dataSources making REST call and mapping the result to properties
- widgets: your widgets, usually attached to one or many dataSources. See widgets backlog to see available widgets.
- avatars: declare some avatars for your team
- thresholds: define the thresholds values which will impact the CSS rules
- grid: mainly responsive configuration parameters of the grid
You define an server.properties server configuration file:
- empty by default: this file must exist but can stay empty. It allow you override the default Spring boot configuration.
- DataSources are regularly refreshed. When refreshed, REST responses are mapped to properties depending your configuration
- Properties are then injected into the application state
- Widgets are dumb components with properties defined in the configuration and the mapped properties of the dataSources they listen to
- Widgets are re-rendered each time properties change
- User have a total control of REST requests and how data are mapped to the application
- No more REST client dependencies : you build your own
- One dataSource can serve many components (no request duplication)
- ClockWidget (current date)
- BugWidget (Jira)
- SonkinsWidget (Jenkins + Sonar metrics)
- SprintWidget (current sprint status)
- BurndownChartWidget (graphical scrum burndown chart)
- VelocityWidget (team velocity average on last sprints, update config at end of sprint)
- ReliabilityWidget (team reliability average on last sprints, update config at end of sprint)
- TeamWidget (name and logo)
- TextWidget (editable text, update server config)
- MoodWidget (editable team mood)
- PullRequestWidget (Gitlab)
- PullRequestWidget (Github)
- MediaWidget (Insert images, videos, sounds)
- jenkinsMonitoringWidget (widget not migrating yet)
- RadioWidget (shared music from server)
- Provide online demo
- Save widget position users can save/reset widget position in the localStorage
- Add a menu a menu allow to control the localStorage user settings
- Dashing theme add a dashing-like theme, even if ugly
- Add Jenkins pipeline build on commit, front + back tests, push docker images
- Release management release 1.0.0 is out !
- Better logging front & back
- Add documentation
- Improve Startup break the "startup" state tree
- DataSource Template dataSources should allow variables (not only global)
- Improve WidgetFactory type declaration should be automatic
- Improve unit tests
- Improve RestClient improve error management
- Fix React warning wrong way for minify/uglify for prod
- Improve Sonkins Widget sonar metrics should be parameterizable
- Dynamic widget ideally, make pure json configurable widget
- Use WebSockets instead of reloading config periodically
- Use Docker compose do we really need docker-compose ?
- Node 7
- Java 8
- Maven 3
Most of the time, you will work with front-end only. So your best option is to start a mocked API and start the dev server.
Start the dev server (hot reload)
npm run serve
- Hot reload: works for any kind of front sources change (js, sass, html...)
Start the mocked API (mock the backend)
npm run api
- On mocks change (ez-client/api/mocks): you need to restart the mocked API
- Verify all the chain without mocks: turn off the mocked API and start the back-end
Start the back-end server (dev)
./mvnw spring-boot:run -Dspring.config.location=file:/your/path/to/server.properties -Dspring.profiles.active=dev
- Profile dev: logs are in DEBUG.
- Profile prod: logs are in INFO and only in ez-dashing.log (not in console), in the same directory as the configuration.
- On dashboard.json change: you need to restart the server.
- Chromium : good (only last version tested)
- Firefox : good (only last version tested)
- Safari : not tested
- Internet Explorer not tested
ez-Dashing is licensed under the Apache 2 license.