2017-03-21 Meeting note
Date
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
- 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
Time | Item | Who | Notes |
---|---|---|---|
5m | Start | Josh |
|
Releasing components | Josh taking notes | Discuss how components are released, and how to fit them into a reference distribution release schedule
|
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) -
- change the version in version.properties or gradle.properties
- Jenkins looks at that version in gradle.properties or version.properties and uses that when publishing
- manually check that version is released to docker hub and/or maven central
- 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)
OpenLMIS: the global initiative for powerful LMIS software