Developing

The role Developer is anyone employed as developer in Partisia.

Code is in GitLab, PFF grants access.

Planning happens in Favro. This means that customer requirements start in Favro. We use Favro to break down issues into smaller tasks, which then is assigned. Simple bugs or work not related to a functional requirement can be recorded directly in gitlab as an issue here.

Standards

Backend code is built in java.

Frontend code is built in TypeScript and React.

Smart contract code for PBC is built in Rust.

There are two types of project targets

• Library - which is deployed to our nexus
• Docker container - which is deployed on gitlab container registry

Java libraries are jars. TypeScript libraries are tarballs. Rust is crates.

We use git for version control.

The goal of our code is to make reading as simple as possible - we write code for others to read.

Professional Communication

All text stored or sent as part of development work including code, documentation, commit messages, Favro cards etc. is to be considered professional communication. No profanity or offensive language is allowed. Assume that anything you write will be read by co-workers, customers or others at some point.

Transparency

All work must be committed and pushed at the end of the day (even for code that does not compile). It is recommended to make as small a change possible, commit and push these changes for transparency. Every branch should be connected to a merge request - we have more than 200 libraries at time of writing and gitlab navigation supports looking up merge requests.

Rebase

It is recommended to merge often with main when there are changes. Rebase can be used, however to use that effectively, detailed knowledge of the intersection of the changes is needed. The simplest and safest solution is to merge.

Bugs & Improvements

Bug reports, features requests and other improvement requests (henceforth report) must be communicated over relevant chat spaces (often named "Something Something: Bugs & Improvements".) This ensures that all relevant stakeholdes are made aware of the report, and can provide feedback in a visible forum.

Not all feedback will arrive over the appropriate channel, for example reports from external developers and users, but these reports should be redirected into the chat by the employee that received the report.

Issue and merge requests

Every task is defined by an issue, the issue is located in Favro.

Every task is solved on one or more merge requests (MR). It must be clear which issue any MR relates to, this can be done by linking directly to the issue in the MR. This is achieved by naming the branch with the ID in Favro and a short human-readable-name PAR-0000-short-title.

MR to main triggers a pipeline which automatically updates the major version.

Internal dependency changes (pom.xml/package.json/cargo.toml/.gitlab-ci.yml) can be merged directly, since the updated versions implicitly point to an issue elsewhere in the original.

The review process is described here,

Versions

By default, all project artifacts are versioned using a version number release.major.patch where

• release is incremented when making a new generation of the project (or the containing system).
• major is incremented when a potentially breaking change in functionality is made.
• patch is incremented when a bug-fix is made.

The release version is increased manually by the primary responsible for the project (or the containing system). Our pipelines automatically increased the major version when merging a branch to main. The bugfix version is only used when making a bug-fix based on a historical (already released) version.

In projects where it is important to manage backward compatibility very precisely we use Semantic Versioning major.minor.patch instead of the default above. This is mostly needed in libraries, where we regularly release updated version to the public.

Unittest

We strive for software for with high quality. We build unittest to ensure the software does as intended.

The tests of a project should support the following aspects

• Maintainability
• Documentation
• Simplicity
• Correctness
• Historic flaw
• Compliance

Pipeline

Pipelines (private definition and public definition) run for every project and must pass before branches can be merged to main. We deploy the latest main.

Java pipelines check formatting and code style, line coverage and mutation test.

TypeScript libraries have tests of code style and line coverage which also must pass. TypeScript frontend (UI) only checks code style.

Rust tests code style and line coverage.

Feature branch

Larger tasks can be split into smaller issues. The merge requests will then target a feature branch. Every branch merged to feature branch must be merged individually, therefore the feature branch can be merged by the primary at an appropriate time. A feature branch is treated equally to main regarding quality assurance and who is allowed to merge.