Date

04 Apr 2017

7am PST

Meeting Link

https://www.uberconference.com/villagereach-isg

Optional dial in:
Dial in: 401-283-5773
PIN: 66343

• note the changed dial in number and pin

Attendees

• Josh Zamor

• Elias Muluneh

• Sebastian Brudziński
• Paweł Gesek
• Nikodem Graczewski (Unlicensed)
• Ben Leibert
• Mary Jo Kochendorfer (Deactivated)

Goals

• Review component version and release process from last meeting
• Briefly look at next big areas of development:
  • Stock Management
  • Reporting
  • Program Data

Discussion items

Notes

Malawi impl discovered a flyway migration issue in Ref Data.  There is a ticket for testable db migration that might help:  OLMIS-2236.  However most teams rely on diligence rather than automated tests.  This hasn't been made a priority yet.

From our last meeting, we reviewed the component lead steps we created:

Component release steps revision:

• All tests pass
  • Features should be checked that they work - manual regression testing
  • note to check that data migrated from previous version to current release candidate
    • modify your local ref distro to include your new component release (RC)
    • would be faster to have a DB dump from each component release (needs a ticket for having Jenkins create and keep that artifact)
• Create / Review CHANGELOG for component (write down in style guide the standard)
  
  • Bugs addressed
  • Look at JIRA tickets AND  look at all the commits.
  • Component lead directs developers to update the CHANGELOG as they work on a ticket
• Demo data
  
  • it should be appropriate for a release
  • review changelog for tickets that might change/add demo data - if something doesn't look right, then raise it in the technical forum and hold the release.
  • anything else we can do - more inline with development?
  • so demo data is created as part of tickets (not a final step for the component lead)
• Bump the version (serviceVersion) -
  1. change the version in the file version.properties (UI components) or gradle.properties (Java/Service components) - in a single commit and push to MASTER
  2. tag that commit as a release (this can be done on GitHub through drafting a new release)
  3. Jenkins detects the change in MASTER, takes that version in gradle.properties or version.properties and uses that when publishing
  4. manually check that version is released to docker hub and/or maven central
     1. Components that are deployed in the Reference Distro are published to docker hub
     2. Components that are consumed in Java services are published to Maven central repo
  5. separate commit to bump to the version that comes after the just released version (as SNAPSHOT)
• Updating deployments
  
  • contract tests updated to next SNAPSHOT version (consumer of docker hub)
  • deployments updated to either released (UAT, demo) version, or SNAPSHOT (test) (consumer of docker hub)
• Announce it
  • emails, notify the larger group, etc in the dev forum
  • telling any dependents so they can start building against the new stuff
• We don't have a programmatic way to check dependencies version.
  
  • Be really clear in release notes? E.g. the ref UI has lots of components, each should document what Service it works for.
  • Dependents should break in a nice way - log it, show a nice error to the user (UI), etc.  Be polite to each other
  • We could build this (Services do report publicly what their version is) - when will we need it?  We haven't had a problem yet, so perhaps wait until we do to get clear requirements before building.
    • Perhaps a build time check
    • Do we need it?  ROI seems a bit low and so that's why we haven't done it yet

We're pretty happy with these bullet points, though it needs some cleanup.  We identified that demo-data and regression testing were still pretty manual and a not so easy area for component leads to manage.

Action items

• Josh Zamor propose how demo data can be more reliably pulled into development cycle
• Josh Zamor clean these notes up and publish (contribution guide/rolling a release)