# Mojaloop Release Process

The Mojaloop Release process follows a community led approach, specifically technical work-stream led, in collaboration and consultation with the Product Council and the Design Authority (DA).

The DA frames the policies, guidelines and technical criteria for the releases (such as quality metrics) while Product defines the feature and product requirements where such aspects are involved. This is executed by the relevant workstream(s).

# 1. Mojaloop Release process

YM8f9iPhGU1jAfr-dQUk4e34QMGPG1ZWnbmC4ERGpsqp70GJH2he2Nje4poq_dii642B82j-Cj-2-HuYTkEF4poIBg8rJSfWYagBVOMyt6PQs5_P2YRE9magU_jE

Community event (PI level planning), workstreams, features, release quality, testing, checklist, release candidate, example epic, Release

The Mojaloop Release process follows a

community led approach
specifically technical work-stream led
in collaboration and consultation with the Product Council and
the Design Authority (DA)

Criteria, guidelines: The DA frames policies, guidelines and technical criteria for the releases while Product defines the feature and product requirements Example releases notes, criteria for v17.0.0, v17.0.0 (opens new window)

Testing continues after the release is made as well and daily cron jobs run to test, until the next release is made, to ensure stability.

Current tasks and acceptance criteria for Mojaloop (helm) releases:

Example story: 3122 (opens new window) , 3847 (opens new window)

The decisions on what features to include, which ones will be ready and included are not included as they happen during planning stages (and based on deliverables)

[x] Ensure all core services and services included in release follow standards for
- [x] Dependabot alerts
- [x] License files
- [x] License headers in source files
- [x] Snyk alerts
- [x] codeowners files
- [x] Branch protection rules on main branches verified
- [x] Review open issues
- [x] Review open pull requests
- [x] Review audit exceptions provided and clear / minimize the list
[x] Update manifests for "release Pull Request (PR)" GH actions WF
[x] Validate the PR released and the process
[x] Deploy default values with RC on AWS moja* environment
- [x] Validate GP collection works with 100%
- [x] Validate FX, inter-scheme tests works with 100%
[x] Deploy, validate RC on a second environment
- [x] Validate GP collection works with 100%
- [x] Validate FX, inter-scheme tests works with 100%
[x] Identify issues with QA Scripts if any - fix them and retest
[x] QA for bugs, regressions, log them
[x] Fix bugs logged if critical
[x] Validate with TTK GP collection
[x] Test on-us configuration option (deploy time change) and verify on-us tests pass
[x] TTK test-cases repo Release is published
[x] Release notes for helm RC is drafted
- [x] Guidance for migration from Release (may have to be a separate story if sufficiently big / complex)
[x] Update release notes with Upgrade Strategy Guide link
[x] Helm Release is published
[x] Deployment of released Helm on a dev envirnoment
- [x] Helm release is deployed on dev successfully
- [x] Regression testing on dev using TTK collections
  - [x] GP collection
  - [x] Core Bulk collection
  - [x] Third-party collection
  - [x] SDK Bulk collection
  - [x] SDK R2P collection
  - [x] ISO 20022 mode tests
  - [x] FX collection (or tests)
  - [x] Interscheme test collection
- [x] Validation using CGS Golden path regression tests
- [x] Test upgradability from previous release (v16.0.4 / v16.0.0)
[x] Deployment of released Helm on a QA environment
- [x] Helm release is deployed on QA successfully
- [x] Validation using Golden path regression tests on QA
  - [x] GP collection
  - [x] Core Bulk collection
  - [x] Third-party collection
  - [x] SDK Bulk collection
  - [x] SDK R2P collection
  - [x] FX collection (or tests)
  - [x] ISO 20022 mode tests
  - [x] Interscheme test collection
[x] Validate daily cronJobs on dev/qa for GP runs well and Cleanup scripts
Validate that we can upgrade from the previous stable release, and this is also to pick up any "gotchas" that may need to be addressed as part of the release, or perhaps release notes need to be updated assuming that it would be up to the upgrader to deal with.

# 2. Mojaloop Release process - proposed updates:

Propose release schedule and timelines

Example: Feature freeze for a (major) release before six weeks prior to the next PI kick-off (or community event)
Freeze bug fixes (non critical) to be included four weeks prior to release date
RC to be validated by at least one downstream implementer such Mini-loop or IaC or Core-test-harness or another implementer
Release to move ahead on time if there are no high or medium priority bugs open in RC and validated on a dev environment and one downstream team / implementer
Streamline release numbers between various components of the Mojaloop platform, such as the Finance Portal
Include performance numbers with details on the setup on which the baselining was performed
Resource usage: capture resource footprint for a base release
Document support mechanisms for Mojaloop releases

# 3. Mojaloop helm release contents

Mojaloop services that support core functionality for the platform and other key services supporting them, along with tools needed for testing such as simulators

Core Functionality with Configurability

Account Lookup
- Account Lookup Admin
- Oracles
- ALS (Account Lookup Service)
Quoting
- Support for persistent/pass-through modes (configurable)
Transfers (Clearing)
- Support for on-us transfers (configurable)
Settlement
- Support for various types, granularity, and frequency
Transaction Requests (Request-to-pay functionality)
3PPI Services (Third-Party Provider Interface)
API Layer - For parties, quotes, transfers, and transaction requests
Notifications
- ML-API-Adapter
Currency Conversion
Extended Functionality
- Central Event Processor
- Email Notifier (prior to version 15)
- Traceability and Monitoring Support
- Instrumentation
Auditing
- Comprehensive auditing capabilities
Supporting Services & Tools for Testing
- ML TTK (Testing Toolkit)
- ML Simulator
- SDK-Scheme-Adapters
- Payment Manager Instances
Third-Party Scheme Adapters
- Integration with third-party schemes
Participant Life-Cycle Management
- Participant Creation
- Participant Updates
Participant Support
- Simple, Easily Usable Tools for Adopters (Example: SDK-Scheme-Adapter (opens new window), Integration Toolkit (opens new window) )
- Onboarding Functionality and Support

# 4. Mojaloop Platform

Primary mojaloop (helm) release and config that supports
- Core clearing engine including support for Bulk
- Quoting
- Account lookup and supporting components
- Settlement engine
- API layer
- Support for request-to-pay (transaction requests)
- Participant life-cycle management
- Ref: Mojaloop helm release (example: v15.1.0)
PISP / 3PPI functionality
API Gateway(s)
- Provide a secure API layer
- Provide Ingress, Egress, IP filtering, firewalls
- Support security mechanisms: JWS, mTLS
- Reference: WSO2
Security components:
- HSM where relevant / used
- Identity & access management
- Cert management
- Connection management
Finance Portal, Reporting
- Portals for Hub Operations, Business Operations teams
- Portals, capabilities for Technical Operations teams
- Ref: FP v3 based on Business Operations Framework
Monitoring Support:
- Operational support and tracing (example: EFK, Prometheus, Grafana, Loki)
- IaC uses Grafana, Prometheus and Loki
Use IaC as reference, example: https://github.com/mojaloop/iac-modules/releases/tag/v5.7.0

# Current Releases

Note: The versions below are the latest published version for each distinct release artifact provided for reference. Consult the release notes for the respective Helm release to see which versions are included in the Helm Charts Packaged Release version.