Skip to content

Latest commit

 

History

History
99 lines (73 loc) · 4.18 KB

ContributionGuidelines.md

File metadata and controls

99 lines (73 loc) · 4.18 KB
Raw

Development and contributing

Internal development process

Development is performed by 2-weeks sprints (We use kind of Scrum framework). We use Git flow for development. Leading branch is always develop. Each new feature/bugfix is done in its own branch. All features/bugs are documented in zenhub.

After finishing branch and seeing that branch has successfully been build by travis a pull request to branch develop must be created in github.

Each developer of the team with approval rights can have a look at pull request and do the review. If no review is done for more than 24 hours, the developer is allowed to merge the branch to develop branch. Of course build in travis must work after merge.

The master branch is never touched. Never, except when release build is done. This is triggered by the project management. When release build is triggered the current develop is merged into master. For that master never ever must be updated manually.

Definition of Ready

The task is ready to be put into a sprint when all following conditions are met:

  • All dependencies are clear and the work to work with them are clarified
  • Use-case is defined in the task
  • Acceptance criteria are defined

Definition of Done

The Task could be accepted only when following requirements are met:

  • Code is reviewed (and approved) by another developer
  • API documentation in Swagger UI corresponds to acceptance criteria
  • At least one automated test for every Use-case exists

nice to have

  • Project documentation (Markdown files) contains the information how to run the demo of use case
  • Javadocs for public methods are written (including parameter description). For REST interfaces Swagger-annotations are sufficient.

Contributing

Any person are free to join us by implementing some parts of code or fixing some bugs. For that separate branch has to be created.

Technical conditions for the implementations

Code styling

If you are using Intellij IDEs, like we do, please consider importing our code-style settings. Further explanation in checkstyle

Java

  • Please use Optionals and corresponding streams instead of null-checks where possible
  • We prefer using Mockito over EasyMock for unit-tests.
  • We prefer SpringBoot autoconfiguration over manual Configuration where possible

Adding new modules

When adding new modules or changing other modules ensure you are adding them to last-module-codecoverage too.

Open API 3.0

We use API First approach, so that API files are the first source of a contract.

The code generated from

opba-consent-rest-api/src/main/resources/static/consent_api.yml
opba-banking-rest-api/src/main/resources/static/banking_api_ais.yml

is generated to

opba-consent-rest-api/target/generated-sources/open-api/src/main/java
opba-banking-rest-api/target/generated-sources/open-api/src/main/java

So the folders have to be made known to the IDE.

Checkstyle

The code uses backend.checkstyle.xml placed in the root of the project. To activate it with intellij install the CheckStyle-IDEA v5.34.0 Plugin and configure in Other Settings -> Checkstyle the version 8.19 and add the configuration file backend.checkstyle.xml.

How to Release

Release is being done using the release scripts ( (C) by Boris Skert ) located under scripts/release-scripts. For detailed info see README for release-scripts.

Steps to make a release

Release is made from local copy! Ensure that you have enough rights to push to master and develop branches

$ git submodule update --init --remote
$ scripts/release-scripts/release.sh <release-version> <next-develop-version>

Example

$ scripts/release-scripts/release.sh 1.0 1.1