Current State Technical Evaluation (TECH)

Description:  Review current code assets including features and technical debt 


Leads: Rich, Ashraf


Rapporteur/Notetaker:  Darius

Notes from Session:  (audio recording failed)

Intro

  • Key Question:  "What should the next implementation do?  Which branch does it start from?"

Currently:

  • "2.0" is pulling from "eLMIS" automatically, at every commit
  • "eLMIS" has pulled from "2.0" once (very recently) and intends to continue doing this manually ~ every week
  • "2.0" is a "development trunk", it's not typically fully functional

 

Karl: I'd like to see over the next 6 months, that "2.0" becomes the master upstream branch for development. And having the "eLMIS" in bitbucket makes things a lot harder.

 

Rich: Right now, 2.0 is not really "upstream", and we all want it to be.

 

Ashram: Once VIMS is released (later this year, or next year) then we can put resources into shifting from bitbucket to github.

 

Rich: Current state: 2.0 is not releasable (e.g includes incomplete features)

 

Karl: Have a separate repository with Moz-specific configuration. Going forwards, we should have a default/demo configuration and feature toggles that disable features not yet complete.

 ---------------

New features in 2.0 (Ashram)

 

* Different configurations for R&R, with different calculations ("R&R Templates")

* Different groupings within an R&R

* Reports

* Checks status of equipment before certain orders (and requires explanations for broken equipment)

* Dashboard on home screen (role-specific)

* uploading of photos from an android application (ODK)

* integration with RapidSMS gateway

* GIS map

* ILS gateway

 

------- 

Some Code Statistics (Josh)

  • 68k lines of code
    • core: 12k LOC
    • reports: 12k LOC
    • openlmis-web: 5.6k LOC
    • vaccine: 3k LOC

            

  • including tests, ~100k lines of code
  • total test coverage: ~25%
  • ~200 DB tables

             (Ashram: some database tables are there as proof of concept and are great examples of things to "clean up")

What we need to make a master branch?

  • Cleanup:  remove tables
  • Hide features (UI)
    • Doc/describe how
  • Have a default/demo config (following github.com/clintonhealthaccess/lmis-moz pattern)

    • Evaluate TW customization module

    • For country-specific configurations
    • Doc and recommend as good practices
  • Doc and describe features
    • Identify which are Global versus country-specific
  • Merge in "accessibility"
  • Published FAQ on current state?
  • Endgame:  final test/stability run; merge to master
  • Finalized branching strategy (e.g. "gitflow")