[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: |
|
||||||||||||
| 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
|
| 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
|
| 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
|
| 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
|
| 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
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 ] |
Yes, it would have to. |
| Comment by Jakub Skoczen [ 07/Jun/19 ] |
|
Frequency for releases for Q2 and onwards has been established. |