Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 8 Next »

Working Draft

This page represents a working draft. Once it has been finalized, this warning will be removed.


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 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. 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 is representative of how CI for a typical component may be performed. Meanwhile, 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 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.


  • No labels