14.0:documentation:modules_reports:developing_and_releasing

Modules - Implemented reports [reports] - Developing and releasing

How to develop a new feature in the reports module:

  • Create a specification page in private section and consult it with module owner and other colleagues (on Slack). Specification page should contain:
    • Use-cases - which data should the report contain, what problem does it solve, which client needs it?
    • Functional specification - how should it work, edge cases
  • Ask a module owner, if this feature can be a part of the module and in which version it will be published
  • Create ticket in product Redmine with final requirements and with correct target version
  • Implement the feature in a separate GIT branch
  • Create merge request to develop
  • Get someone from the product team, or the module owner to review your changes
  • After successful review, ask module owner to merge you code

Rules for code review:

  • There are tests (test coverage of 80% for reports is hard to achieve but do your best)
  • All features are documented - the report is mentioned above and has a dedicated page describing its use and configuration
  • Changelog is updated
If your code does not meet the requirements mentioned above, it may be rejected.
  • When developing, use our standard gitflow:
    • Branch per feature. Branch naming as usual.
    • Develop on top of the develop.
    • Master branch contains tagged releases.
    • The only way for code to get into master is by pull request develop → master.
  • Release process
    • After merging all features wanted for the release, one (selected) developer builds the develop. If it builds fine and tests are also OK, the developer edits module version in the pom.xml file and sets it to X.Y.Z.
    • Developer creates pull request on GitHub to merge develop → master.
    • Repo admin (or any other authorized user) reviews the pull request, can request changes if necessary. Unresolved TODOs, missing comments, bad codestyle or documentation, suspected bugs, etc. - all those things can be grounds for change request.
    • If the pull request is OK, repo admin merges it.
    • Repo admin creates a new release in GitHub interface, version is set to X.Y.Z to correspond with version set in project sources.
    • After release, repo admin makes changes on the develop branch: upps module version to X(+1).Y(+1).Z(+1)-SNAPSHOT in the pom.xml and package.json. What the next version of the module will be is up to discussion preceding the release.