Release Notes

Release Summary

The DIGIT HCM v1.8 release introduces a Central Instance Deployment Model—running services for multiple countries (Mozambique, Liberia, Nigeria) on a single Kubernetes cluster. Data for each country is securely isolated at both:

  • Namespace level (Kubernetes separation)

  • Database schema level (PostgreSQL schemas)

Goals:

  • Reduce ongoing maintenance

  • Standardise configurations across countries

  • Avoid duplication of services

  • Still allow country-specific customisations where required

  • Save infrastructure costs by leveraging a central instance capability

Note: This update applies only to application-facing services. Admin Console and Micro-Planning services are not included.


New Capabilities

1. Admin Console (v0.4)

  • What it is: A no-code, configurable console.

  • Purpose: Allows partners and field teams to independently design, localise, and deploy campaigns without engineering help.

2. Server-Generated Beneficiary IDs

  • What it is: Pre-generated Beneficiary IDs created on the server.

  • How it works: Synced to the app during login.

  • Benefit: Enables registry reuse across campaigns by giving each household/individual a unique ID.

3. Enumeration Tool

  • What it is: A Tool for capturing household- and individual-level data.

  • Features: Supports conditional questions and structured relationships (e.g., parent-child).

  • Purpose: Flexible community health enumeration in areas without standard formats.

4. Transit Tool

  • What it is: New "Transit Post" campaign mode.

  • Use case: For locations where pre-enumeration isn’t possible (e.g., bus stops, parks).

  • Purpose: Records aggregate counts with location details instead of individual records.

5. Attendance Proof of Work

  • What it is: QR Code Scanning for employee attendance.

  • Benefit: Improves reliability and accountability in campaign deployments where supervisor-marked attendance lacked verification.

6. Peer-to-Peer (P2P) Data Sharing

  • What it is: P2P downsync sharing between devices via Wi-Fi Direct.

  • Purpose: Enables offline data sharing to keep field work running in low/no-connectivity areas.


Enhancements

1. Centralised Multi-Tenant Deployment

  • Single Kubernetes cluster for Mozambique, Liberia, and Nigeria.

  • Common namespace: Shared core services (e.g., egov-user, workflow, egov-otp, MDMS V2).

  • Dedicated tenant namespaces: Country-specific services (e.g., Liberia HRMS, Nigeria HRMS).

2. Multi-Schema Database Support

  • Single PostgreSQL instance with separate schemas (public, liberia, nigeria).

  • Automated Flyway migration using migrate.sh for all schemas.

  • Schema lists and enablement flags are configurable via Helm & environment YAML.

3. Mobile App Endpoint Segregation

  • Separate apps per country (example: Mozambique - mz, Liberia - lb, Nigeria - ng).

  • Each app connects to tenant-specific URLs for correct routing.

4. Standardised Kafka Topic Naming

  • Tenant-prefixed format prevents collisions.

  • Example: mz-save-household-topic, lb-save-household-topic, ng-save-household-topic.

5. Helm & Configuration Improvements

  • Common values.yml for baseline DB/service settings.

  • App-specific values.yml overrides for schema/multi-schema flags.

  • Backwards-compatible for services without multi-schema needs.

6. Centralised Internal Gateway & MDMS v2

  • Internal gateway configurations are stored centrally for easier updates.

  • MDMS v2 configs consolidated per tenant for consistent metadata.

7. Shared vs. Tenant-Specific Services

  • Shared services: Household, Individual, Stock, Facility, Product, Service Request, Egov-HRMS, Project, Referral.

  • Tenant-specific services: Deployed only where needed (e.g., Liberia HRMS, Nigeria HRMS).


Last updated

Was this helpful?