Mojaloop Community Central

Cover image for Path to release quality
Samuel Kummary for Mojaloop Foundation

Posted on • Updated on

Path to release quality

Mojaloop guidance on the path from Experimental, Alpha / Beta (quality, processes) to release quality:

  1. Documentation

    • Readme page of all repos to follow the template and provide for sections where applicable:
    • Overview of functionality
    • Instructions to run the service independently
    • Instructions to run tests
    • Configuration options (env variables, etc to be set)
    • Known issues
    • Links to documentation for details on product features, functionality
    • FAQs
    • Sequence diagrams with varying level of detail
    • Detailed deployment documentation, stand-alone and where applicable with/alongside Mojaloop platform
  2. Continuous Integration, Continuous Deployment (CI/CD) steps to include

    • Unit tests with coverage following Mojaloop standards
    • Integration tests
    • Functional tests (if applicable)
    • Lint checks: link: https://docs.mojaloop.io/community/standards/guide.html#config-files (eslintrc.js)
    • Code coverage check (limit doesn’t have to be 90% for Beta, can be lower)
    • Vulnerability checks
    • Image scan
    • License checks / audit
    • Note: Can use existing template on other current release level repos for reference
  3. GitHub

    • Main branches to be protected (Primary branches to be named “main”)
    • PR tiles to use “conventional commit” standard (integrated with CI/CD) (Link: - - https://docs.mojaloop.io/community/standards/creating-new-features.html )
    • Codeowners to be added to all repos part of the core platform
    • Codeowners approval required for merges
    • No skipping CI steps for commits in general
  4. Project issues

    • Issues to follow story template
    • Well defined acceptance criteria required
    • Acceptance criteria and priority of issues to be confirmed during prioritization / refinement meetings with input from Product (owners/managers).
    • Encouraged to use: size estimate, task list, sprint / milestone, release, Epic
    • Stories to have information needed to navigate through changes needed on GitHub repos (Links to PRs, etc)
    • Issues to be closed after Product Owner confirmation
    • All artifacts, design decisions to be publicly available on Mojaloop GitHub
  5. Releases & Testing

    • Helm charts needed for all services
    • Need well defined test collections along with provisioning collections that cover all the features supported.
    • Release notes to contain (at a minimum):
    • High level summary
    • API versions supported
    • Individual service versions (with links)
    • Bug fixes
    • Testing instructions
    • Known issues
    • Breaking changes if any
    • Release cadence to be discussed with Release co-ordinators and Product teams.
    • Assess deployment options prior to releases and ensure tests, deployment instructions are in-line with releases as they’re made.

Top comments (1)

Collapse
 
samk profile image
Samuel Kummary

Publishing this here after conversations with several active workstreams and the community from over six months ago.

Any changes needed here can be discussed at the DA, CCB and Product council but these are based on already approved and adopted standards.