[FOLIO-1614] SPIKE: decide on frequency of releases Created: 14/Nov/18  Updated: 03/Jun/20  Resolved: 07/Jun/19

Status: Closed
Project: FOLIO
Components: None
Affects versions: None
Fix versions: None

Type: Task Priority: P2
Reporter: Jakub Skoczen Assignee: Jakub Skoczen
Resolution: Done Votes: 0
Labels: platform-backlog, sprint56
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Issue links:
Relates
relates to FOLIO-1577 Automated builds for FOLIO 'release' Closed
relates to FOLIO-1715 add "release dependency check" to PRs Closed
Sprint:
Development Team: Core: Platform

 Description   

To keep FOLIO "release" distribution fresh we need more frequent releases of backend and front-end modules. Currently there's usually no need to make releases more frequent than once per quarter (when they are required for the quarterly release management). Doing them more frequently throughout the quarter and rebuilding "release" environment will decrease the time needed to prepare the quarterly release. Eventually the "release" environment can take over from folio-snapshot-stable for demo and integration of modules across FOLIO.



 Comments   
Comment by Jakub Skoczen [ 17/Jan/19 ]

Marc Johnson Zak Burke Adam Dickmeiss Can we increase the frequency of backend module release to the point where each new feature (each PR) that we want to use in a front-end module or a business-logic module results in a new release? This would be required to enable FOLIO-1715 Closed . As far as UI modules are concerned – can we release a new version each sprint?

Comment by Marc Johnson [ 17/Jan/19 ]

Part way through last year, I was releasing the circulation modules pretty much on this basis.

It requires planning of work in such a way that features are not merged in an interleaving way into master, and time from the owner to perform the release.

This planning of work gets more complicated as we add teams / developers working concurrently on features in the same module, and where there is dependent work across modules (e.g. a new property added to storage, to allow a new business logic feature to work)

I'll write up the rest of my comments on FOLIO-1715 Closed .

Comment by Jakub Skoczen [ 18/Jan/19 ]

Zak Burke Michal Kuklis Niels Erik Nielsen what do you think about releasing UI modules once per sprint?

Comment by Michal Kuklis [ 18/Jan/19 ]

That sounds a bit too often to me but perhaps it could still work if we distribute/delegate this work to multiple people. Otherwise I worry it will be too time consuming for just 3 of us.

Comment by Marc Johnson [ 18/Jan/19 ]

If I'm understanding FOLIO-1715 Closed correctly, the backend release frequency will likely need to be multiple times per sprint (roughly once per UI story for each backend module)

Comment by Marc Johnson [ 21/Jan/19 ]

Given that most backend stories that are needed for most UI stories are made in a single pull request, this suggests we are intending to release each backend module after almost every pull request merge.

Have I understood this correctly? Which teams does this apply to?

Comment by Jakub Skoczen [ 21/Jan/19 ]

Marc Johnson Yes, although it's okay to bundle multiple backend changes into one release. Generally, John Malconian and I discussed rolling out FOLIO-1715 Closed at some point. If enabled, it would mean that the PR for UI feature that depends on new backend behavior cannot be merged until the backend release is available.

Comment by Marc Johnson [ 21/Jan/19 ]

Jakub Skoczen I think what I'm most confused about is why we want to restrict merging story changes rather than just formal releases of UI modules on released dependencies?

In effect, the development process would become

  1. Start backend work for UI story
  2. Start UI work for UI story
  3. Merge backend work for UI story
  4. Block UI work (with pending branch and PR) until formal backend release
  5. Formal backend release
  6. Merge UI work
  7. UI work reviewed by tester / PO
  8. UI work is formally released at end of sprint

My primary concerns are that this is likely to delay step 6 and 7, and that backend work will be released prior to being used (which for stories where the behaviour is primarily implemented in the backend means more likelihood of the need for bug fix releases / marking old releases as unfit for purpose).

Comment by Jakub Skoczen [ 28/Jan/19 ]

Marc Johnson [Adam Dickmeiss John Malconian Zak Burke Guys, we discussed that it makes more sense to release both front-end and back-end modules close to each other. I would propose we try to release them once per sprint, is that acceptable?

Comment by John Malconian [ 28/Jan/19 ]

Seems logical to me, Jakub. Worth a try to see how it goes.

Comment by Marc Johnson [ 28/Jan/19 ]

Jakub Skoczen I think we can try it.

I think we need careful planning between the core functional, core platform and other teams contributing to core modules to decide what goes in.

Are we thinking these are released prior to the end of the sprint, or at the beginning of the next one?

I think we also need to review who / which teams are responsible for these releases, since the teams have been re-organised.

If it will mostly be the core functional team, I think that needs factoring in to the teams capacity.

Given that the goal of this is to be able to build a core environment from formally released versions, does this also apply to all of the modules that the core relies upon as well, e.g. mod-feesfines, mod-source-record-storage?

Comment by John Malconian [ 28/Jan/19 ]

Given that the goal of this is to be able to build a core environment from formally released versions, does this also apply to all of the modules that the core relies upon as well, e.g. mod-feesfines, mod-source-record-storage?

Yes, it would have to.

Comment by Jakub Skoczen [ 07/Jun/19 ]

Frequency for releases for Q2 and onwards has been established.

Generated at Thu Feb 08 23:14:38 UTC 2024 using Jira 1001.0.0-SNAPSHOT#100246-sha1:7a5c50119eb0633d306e14180817ddef5e80c75d.