The intention of this page is to document the acquisitions-specific release procedures, best practices, lessons learned, and other related information.

Milestone Dates and Terminology

Description of feature freeze, code freeze, etc.  

Additional Details TBD.

Release Procedure

High level description of the steps required to perform a release.  

Community Release Guides

Acquisitions-specific Steps - Refers to steps in the Community Release Guide linked above, but adds additional steps/sequencing for improved coordination and communication.

ui-modules: check that latest translations are in place (especially if you've changed existing values in en.json).

  1. Before you do anything, communicate with the team.  Let them know during daily standup that you're planning on starting a release.
  2. Determine the release and next versions - See - Discuss with the team if unsure about either.
  3. Create a release branch (See Best Practices)
  4. Update the NEWS/ file (See Best Practices)
    1. Make use of JIRA and add any stories that have been completed in this version but are missing from the NEWS/Changelog file.
  5. Bump interface versions that have changed (minor number if backwards compatible, major number if breaking changes)
    1. N.B. Make sure all required interface versions have been released.  If not, raise the issue with the PO/Tech Lead.
  6. Commit and push your changes
  7. Create A PR (See Best Practices) and request approval.  If there are mistakes this is the time to identify them, BEFORE creating a tag.
  8. Once you have at least 2 approvals:
    1. Backend Only: Run the maven command to create the tag and prepare for the next release, then push the pom file changes AND tags
    2. UI Only: Create a tag.
  9. If the PR checks pass, DO NOT merge your PR yet...  Goto Jenkins, find your module, find your tag, and build it.  
  10. If the tag build succeeded, Goto your github repo, merge the release's PR, click on releases, and draft a new release.  Copy/Paste in the section of your NEWS into the release notes and save/publish.
  11. Announce your release in the #acquisitions-dev and #releases channels with a link to the release
  12. Coordinate with the rest of the team before merging any PRs into master.  
    1. If there were interface/dependency changes there's a good chance multiple PRs will need to be merged together to prevent breaking the testing environment.
    2. The team may decide to hold off on merging any PRs until after the sprint demo.  You don't want to be the reason why someone's demo isn't working.
  13. Move your JIRA to "In Review" and assign to the Scrum Master.
  14. The Scrum Master can safely close the story and update the JIRA releases/versions
  15. If the module has API tests:
    1. Create a branch of folio-api-tests
    2. Update all schema references so that the commit hash from the release's submodule is used instead of HEAD/master.
    3. Update all mock data references so that the commit hash from the release's submodule is used instead of HEAD/master.
    4. Create and push a tag of your branch.  Please follow the naming convention: <module name>-<release version>, e.g. mod-orders-3.0.0 

Module Dependencies and Release Order

In order to satisfy dependencies at time of release, modules need to be released in a particular order.  

Generally speaking the precedence looks like:

  1. Storage modules
  2. Business logic modules
  3. UI modules

In some cases there are dependencies between business logic modules which require additional ordering.  

TODO: add a dependency graph here showing the acquisitions modules and the interfaces they depend on.

Best Practices

General best practices - How to structure your NEWS file, what to name your release branches, tags, etc. 

Lessons Learned

A place to document pitfalls, gotchas, lessons learned in order to help others from repeating the same mistakes etc.

Open Issues and Questions

A place to list open issues for tracking purposes, or ask questions for gathering feedback/comments.