Note: this SOP applies to both, new designs, as well as changes to active configurations.

The process of designing and building a DHIS2 configuration (aggregated or tracker) is iterative. As these iterations are revised, there is significant level of change across iterations: items are discarded, elements are renamed, or configurations are abandoned in re-started (deleting objects in DHIS2 is a very difficult process). Using a development environments ensure you can create as many iterations as required, without affecting any live users, creating conflict on the data. It also doesn’t matter how much orphan objects you leave behind - dev environments are refreshed frequently.

Before you start

Requirements doc pack (LINK): a comprehensive pack includes a nice summary, details about the actors, data collection flow, security considerations. More importantly, it MUST include a D2A, psi’s framework for analytic requirements for any product.

Design and Build

As in most system designs, this is an iterative process on which varios prototypes are build based on the initial requirements, and then revised based on the varios stakeholders feedback revisions. You should used templates that allow you to partially automate your builds, in particular data elements and options/option sets (see DHIS2 metadata import options)

Environments

The process of design and development must be done in a designated development server, and never on a production server. This gives you the freedom to build as many iterations as required, discard data/objects without having to delete them, or abandon them as required, without ‘littering’ the production environment - dev is a safe space to experiment and iterate.

Testing

See Testing DHIS2 configurations and apps

Deploying

Once the testing has been finalised and approved by the product owner, you can proceed to its deployment. See H2 Deployment Guidelines - Environments

SOP versions