Open Proces Huis (frontend)

This repo holds the Ember project that serves as the frontend of Open Proces Huis. Open Proces Huis is one of many applications developed under the Agentschap Binnenlands Bestuur (ABB), which is part of the Flemish Government. It allows for lokale besturen to create and share processes. Such process is created by uploading a BPMN file, and can be populated further with other types of files that serve as attachments. The application also allows for uploading new versions of a process's BPMN file, enabling for a very rudamentary idea of version control.

Getting started

Backend

The frontend relies on some backend for proper running. In fact, it relies on a wide range of microservices, each doing its own part. The setup of the complete microservices stack can be found in this repo, whose README also stipulates the necessary steps to undertake in order to get the stack running.

Frontend

First make sure the backend is up and running.

1. Clone this repository

git clone https://github.com/lblod/frontend-openproceshuis.git

2. Download the necessary NPM packages

cd /path/to/project

npm install

3. Run the project

ember serve --proxy "http://localhost:80"

4. In your browser, go to localhost:4200 to visit the homepage of the web application.

Routes

As with any Ember project, router.js holds all possible routes the application offers. What follows, is a brief overview of the most important ones.

• /mock-login: log in using a mock user (every user is part of a lokaal bestuur)
• /processen: list all processes of all lokale besturen
• /processen/<id>: consult the details, the latest BPMN file, all BPMN file versions, and attachments of a specific process
• /gedeelde-processen: list all processes of the current user's lokaal bestuur and upload a new one (a BPMN file is always the starting point for the creation of a process)

How to make a release

Before you make a release. Here is a checklist to make sure you have everything ready before releasing. In this example we will simulate bumping from version 1.3.0 to 1.4.0

Before the release

There’s a flow we follow in Jira to ensure everything is executed in the correct order before a release. First, we need to make sure all tickets that need to be deployed to TEST have been tested and marked as OK. If that’s the case for every ticket, we can proceed with creating a QA release.

You can check the progress of your tickets here: https://binnenland.atlassian.net/jira/software/c/projects/OPH/boards/275

Make sure that all tickets that are tagged with the OPH Release... tag are in the Klaar voor ACC column. Only then can we make a release.

All following steps describe how to manually create a new release. However, this repo also allows to use release-it to automate the release process. To use release-it, first generate a Github Personal Access Token. Next, run the following command and follow along with the interactive terminal session it initiates: GITHUB_AUTH=your_github_token_here release-it.

1. Update the changelog

• Go to the CHANGELOG.md and update according to the merged PR's since the latest release.
• Group into sections. Currently we use:
  • 🚀 Enhancement (new features)
  • 🐛 Bugfixes
  • 🔧 Maintenance
• Format using the same style as previous entries (PR number, description, author mention).
• Sort by PR number in descending order

2. Bump the version

• Go to the package.json and change the version like this:

-   "version": "1.3.0",
+   "version": "1.4.0",

• Commit and push:

git add CHANGELOG.md package.json
git commit -m "Release v1.4.0"
git push

3. Tag the release

git tag -a v1.4.0 -m "Release v1.4.0"
git push origin v1.4.0

You could also do this in the Github UI.

4. Merge previous tag to current tag

Go to the Github UI and go to the releases page

Draft a new release

Choose the tag that you created

• Select the new tag in the first dropdown
• Set master as the target branch
• Set the previous tag
• Set the release title (eg. Release 1.4.0)
• Add the release notes in the description. As we currently are keeping track of the changes in our CHANGELOG.md, we can just copy and paste the changelog of the new version we previously created.
• Check set as latest release and click on Publish release