2017-03-21 Meeting note

Date

21 Mar 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

• Jeff Xiong (Unlicensed)
• Pengfei Cui (Deactivated)
• Sebastian Brudziński
• Paweł Gesek
• Nikodem Graczewski (Unlicensed)
• Nick Reid (Deactivated)
• Chongsun Ahn (Unlicensed)
• Ben Leibert
• Brandon Bowersox-Johnson
• Mary Jo Kochendorfer (Deactivated)

Goals

• Releasing components - scheduling and process guidance

Discussion items

Notes

For reference, go over the current rolling a release.

Example release timing:

• All tests pass
  • Features should be checked that they worked - manual regression testing
• Bugs addressed
• Release notes for component (features working, need some standard - technical, list of tickets, more like a change log)
  • JIRA may be able to generate release notes, but sometimes not everything matches - not too accurate.  One way to look at it is to look at all the commits.  Might be a problem if components aren't their own project - the fix version field is for the ref distro.
  • Component lead directs developers to update the release notes as they work on a ticket
• Demo data - it should be appropriate for a release
• Bump the version (serviceVersion) -
  1. change the version in version.properties or gradle.properties
  2. Jenkins looks at that version in gradle.properties or version.properties and uses that when publishing
  3. manually check that version is released to docker hub and/or maven central
  4. 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
  • 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

Action items

• Guidance: What kinds of things are published to maven and/or Docker Hub?
• Look at these steps after our next release (end of March)