Evolving to new development practices (TECH)

Owned by Kevin Cussen (Deactivated)
Last updated: Oct 02, 2015 by Rich Magnuson (Deactivated)
2 min read

Description: Short-term approaches to identifying technical debt; how to apply new development practices now; Common shared upstream branch

Leads: Darius

Rapporteur/Notetaker:  Rich

Audio Recording:  Development Practices d2s4.mp3

Notes from Session:

Intro

In this session, we start to decide which practices to follow, and how to handle technical debt.

Who is currently contributing code?

  • TW to 2 for MOZ
  • VR, CHAI, JSI and PATH to eLMIS

High Level work to accomplish in the short term:

  1. We Commit to making 2.0 the upstream branch by end of 2015
  2. Need CI and automated reviews  (possibly need a QA environment)
  3. Updated workflows around pull requests/reviews
  4. Test data set/configuration
  5. Need 2.0 Demo instance (there are ones for TZ and MOZ projects)



What are the implications for countries between now and 2.0 master?  (Not addressed in discussion)

Tasks: (Owner is in brackets)

  1. Nominate and establish technical WG
  2. Accessibility from 1.0 is merged into 2.0 [VR]
  3. Gitflow setup (rename '2.0' to 'master', etc.) [VR]
  4. CI Server:  [VR]
    1. Need to pick a CI:  "travis", based on github permissions.  Most orgs currently use Jenkins
  5. Sonar server [any org]
  6. Publish rules in dev documentation, a "contribution guide"
  7. Dedicated time for regular reviews, merge into master
    1. Public expectations between organizations, who has privilege to commit to master trunk?
      1. Write down the vetting requirements/criteria for this committer
  8. Establish tech review board, and its arbitration process
    1. Publish Pull request process and expectations
  9. Tool selection (issues, wiki, etc.)
  10. Create test dB, demo environment



VillageReach doesn't need to do all of the above tasks.  Govern & Tech tracks should review and decide.  Tomorrow, decide Tech WG members.

 

  • Should have some upfront feature review so project knows ahead of time if a feature belongs to core or not, to set expectations and avoid surprises.  Product design should occur beforehand.
  • How is a feature, ready to be merged, defined as Done?  Any requirements around documentation, testing, etc.
    • Question arising from doc concern:  If code is merged into dev/master, what is the Done criteria?  If feature is gradually built and constantly merged in, when is that feature "done"?  Needs to at least be Done by the next release tag.

 





OpenLMIS: the global initiative for powerful LMIS software