This is an old revision of the document!


The Deployment WIKI

The deployment WIKI provides a knowledge base of deploying Sahana for different types of disasters, scenarios and roles. It also provides some best practices for the particular situation. Please also share your experiences so that we can make this knowledge base richer and more effective.

A full list of our deployments and the template are available for use and reference.

Best Practices

The following best practices are based on past Sahana deployment experiences including Pakistan, Sri Lanka, Philippines, Peru and US. (target) Org in the paragraphs below refers to those who can apply Sahana to improve efficiencies in coordination either internally or within a network of relief groups. They can include Government, NGOs, UN, Spontaneous Volunteers.

Requirements Gathering

Spend time to understand the requirements and get it in writing

Justification - It is important to spend sufficient time upfront to clearly understand the requirements and to document them should further clarification be required later. Always communicate this documentation to the target org before you begin to set expectations and schedules. It is better for the team doing the customization to meet the members from the target org onsite rather than doing this remotely.

Understand the problem first and if Sahana is a match and not vice versa

Justification - Understand the real problem being faced by the target org and match/customize Sahana to that, rather than use Sahana like a hammer looking for a nail. It is better not to deploy Sahana, than to deploy a solution that does not match the coordination problem.

Understand the IT literacy and vocabulary of your target audience

Justification - There is no point giving Sahana to those that do not have basic IT literacy. It is better to appoint one IT savvy person to act as a Sahana helpdesk and center point for those that are not IT literate. The terminology used on the system should also match the target user group.

Understand the security constraints of the target organization __early__ and match Sahana to it

Justification - The data being served by Sahana is often very sensitive, so an effort needs to be put in place to secure the data to only authorized people. The orgs usually have their own security policy and restricted ports & practices. Sahana can be configured flexibly with an authentication and authorization (access control) that matches the environment. Don't leave this as a last moment task or it becomes a show stopper.

Deployment Approach

Have the beneficiaries been helped? Use the Red Cross Code of Conduct as your baseline

Justification - As Sahana addresses the humanitarian response domain always ask the question to yourself irrespective of what the target org need, if the beneficiaries have indeed been helped by the customization. It will keep your leadership on the customization well grounded. The Red Cross Code of Conduct provides a good base line for all of us to measure against.

Deploy Sahana on an environment comfortable to the target organization

Justification - There have been many instances where the Linux OS has not matched the target organization's ability/capacity to maintain the system. In this instance we recommend you install Sahana on an OS familiar to the target organization (usually Windows) or all issues including non-Sahana ones will be propagated back to you. Sahana is available to be installed on Windows as a WAMP package or the portable App version.

Operations and Technicalities

Deploy Sahana off a stable branch

Justification - The disaster coordination domain is a mission critical domain and we cannot afford to have systems failing in the middle of disasters. Thus irrespective of how old the stable branch is, you should customize Sahana off a stable release and not a development release such that you have some degree of assurance on reliability.

Use bug trackers, capture change requests to prioritize and schedule tasks

Justification - Bugs will pop up as you customize Sahana for the target org. Ensure you have a quality process in place to track & fix bugs. Also you can expect a lot of changes from the target org especially during a disaster, so be ready to track them effectively such that none are missed and schedule them effectively based on priority. At the top end you can use a project management tool such as dotproject to schedule the team. It is better to have a dedicated team assigned to ensure delivery and deadlines.

Clearly understand maintenance and training needs and ensure it is covered by someone

Justification - A deployed Sahana and the XAMP system needs to be maintained and administered. A good training program is also needed so that users get a good understanding of how to use the system. Ensure there is someone or support group responsible for the above after deployment as you can expect a lot of queries (mostly trivial) and minor configurations once the system gets deployed.

Support the main releases by putting bug fixes and new modules back to the Sahana codebase

Justification - Please continue to support Sahana as you build new modules, create enhancement and fix bugs for target organizations by submitting that code back to the code base according to the standards specified, such that a minimal amount of work is need to integrate it. The sooner you can do this the better it will be before the codebase diverts from the deployment customization.

Use staging servers and an update process for change requests

Justification - As the system gets used by the target organizations there will be change requests that will involve changes to the code. Ensure you have a staging server to test new patches and a fault-tolerant mechanism to update the production server once the tests are complete on staging.

Standards and References

Use the Red Cross Code of conduct as your baseline set of principles when working in this domain

Justification - The Red Cross Code of Conduct has been formulated by many years of experience operating in the Humanitarian Response domain and it is advisable that you keep to these principles when working in this domain such that you do not get into political issues or other related problems. We have elaborated on the Red Cross Code of Conduct with respect to Sahana here

Read through the Sphere Handbook to understand standards in Disaster Response

Justification - The Sphere handbook is guide for disaster management that takes into account recent developments in humanitarian practice in wat/san, food, shelter and health, together with feedback from practitioners in the field, research institutes and cross-cutting experts in protection, gender, children, older people, disabled people, HIV/AIDS and the environment. The handbook is the product of an extensive collaborative effort that reflects the collective will and shared experience of the humanitarian community, and its determination to improve on current knowledge in humanitarian assistance programmes.

Deployment Modes / Usage Roles

Any specific details for the deployment of Sahana for the following usages (roles)

- all modules active

- just needs Organisation Registry & Inventory Management modules

Disaster Types

Any specific details on Sahana configurations for the following disaster types

Customizations

Community Integrated Deployment

Best Practices

  • Someone to join the sahana-user list and to facilitate bringing in deployers (for example the IBM China team) into the sahana-user and sahana-maindev communities as appropriate early in future emergency/deployment processes. The following issues can then be supported and addressed:
  • Bugs found : Bugs found should be reported by the deployment team through the sahana-user and sahana-maindev lists - someone from our core team can then take responsibility for getting them added to Tracker. Patches can then be provided by the community back to the deployers.
  • Bugs fixed : Process TBD to get bug fixes made by deployment teams back into the main codebase. These could similarly be reported back directly to the sahana-maindev list and the patches to be incorporated into future release candidates.
  • New modules : Often new modules are developed for a specific deployment - for example, the situation reporting module completed for the Bangladesh deployment. This code should be returned to the community for consideration by the PMC of being merged into the main codebase.
  • New features : Similarly, enhancements to existing functionality is often made during deployments to meet the specific need of the operational situation - such as the financial disbursement tracking that was linked to the DVR for the Peru deployment. Again, this code should be returned to the community for consideration by the PMC of being merged into the main codebase.

QR Code
QR Code deployments:start (generated for current page)