Page Comparison

Introduction 

Example Budget and Timeline 

Requirements-Gathering Guidelines

Technical Setup Guide

Server Environments

• OpenLMIS 3 uses Docker and supports hosting in the cloud or in a data center of the implementer's choosing.
  • The OpenLMIS project provides a recommended deployment topology tuned for Amazon AWS cloud hosting. (Include link).
• It is strongly recommended that any implementation of OpenLMIS establish separate server environments for Production, Staging/Testing, and Dev that are isolated and as identical as possible.
• The OpenLMIS environments should adopt best practices given the value of the data and the need for reliable, uninterrupted, secure operation: automated backups, performance monitoring (include link for Scalyr setup info/recommendations), change management, etc.
• (Include links to the core documentation we have for parts of this.)
• Any other guidance on servers/environments?

Continuous Integration and Deployment (CI/CD)

The core OpenLMIS project uses an instance of Jenkins at http://build.openlmis.org to provide continuous integration and delivery (CI/CD).

• It is strongly recommended for implementers to establish an automated CI/CD pipeline.

• The Jenkins setup used by OpenLMIS itself can be replicated and leveraged for implementations. (Include link to core documentation for Jenkins like this). Implementers can establish their own Jenkins setup or could choose an alternative tool for their CI/CD needs. Below we document the Jenkins-based approach to CI/CD.
• Why do this? Trigger automated tests so developers get immediate feedback of anything broken. Trigger performance tests to measure the system performance against a specific known set of data, configurations, and server resources. Automate every deployment so there is never a human being logging onto servers to manually make changes (which is prone to error and hard to re-produce reliably over time and with staff turnover.)

Implementers will find a number of jobs on http://build.openlmis.org upon which they can base their own. Ones Because of the micro-services nature of OpenLMIS, each service/component has a Jenkins build job. For example, a job such as the OpenLMIS-auth-service are  is representative of how CI for a typical component may be performed. Meanwhile, the there are also deployment pipelines to update each server environment with a specific build version or snapshot of a set of components. For example, a job such as OpenLMIS-3.0-deploy-to-test project is  is illustrative of how this CD pipeline may be achieved.

More information about Jenkins can be found here. Meanwhile, detail about the Core project’s use of it is available in its documentation. (The link above is another place...maybe we need to group the set of relevant links and explain what each link covers.)

As described here, the core OpenLMIS project makes extensive use of continuous integration and delivery (CI/CD) to help ensure its quality. Implementers are highly encouraged to do the same. OpenLMIS and its constellation of microservices are flexible enough for use with a wide variety of tools and technologies. Nevertheless, implementers may find it convenient to adopt tools such as Jenkins used by the core project.