[FOLIO-1715] add "release dependency check" to PRs Created: 17/Jan/19  Updated: 03/Jun/20  Resolved: 28/Jan/19

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

Type: New Feature Priority: P3
Reporter: Jakub Skoczen Assignee: Unassigned
Resolution: Won't Do Votes: 0
Labels: platform-backlog
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original estimate: Not Specified

Issue links:
Relates
relates to FOLIO-1614 SPIKE: decide on frequency of releases Closed
relates to FOLIO-1631 add a "released dependency check" to ... Closed
Sprint:
Development Team: Core: Platform

 Description   

Enable dependency check functionality implemented in OKAPI-683 Closed during the PRs to master across both front-end and back-end modules GitHub repos.

(Note: this will not work for cyclic dependencies but we currently don't have such in the project).

Note: this would require much more granular releases for backend modules.



 Comments   
Comment by Marc Johnson [ 17/Jan/19 ]

This suggests to me a development process like:

  • backend developer implements new feature / change needed by the UI (and makes it available by merging to master)
  • UI developer uses that to develop UI feature in a branch (including changes to interface versions)
  • backend developer formally releases backend modules (supporting that UI feature), without any other changes
  • UI feature pull request passes validation and can be merged
  • UI feature is merged

Is that a reasonable understanding of the process we intend to use?

Comment by Jakub Skoczen [ 18/Jan/19 ]

Marc Johnson Yes, correct. And as I far as I understand currently the process is the same with the exception that when the UI feature (depending on backend feature) is completed, it is merged to master without a dependency check. This works for folio-snapshot because the backend feature has been most likely already merged to master and Jenkins has generated a snapshot artifact that will be used to satisfy the UI feature dependency.

Comment by Marc Johnson [ 18/Jan/19 ]

Jakub Skoczen This would effectively need to formally release the backend modules after almost every story, in order to allow the UI to merge the associated, blocked story, because otherwise a regular UI pull request will fail?

This will likely mean multiple formal releases per sprint of each backend module involved in a UI story.

Are we intending to do the same for between storage and business logic or edge modules?

This could also mean that we formally release a backend module, without it having been used in any environment, except locally by a UI developer?

Is that a sensible interpretation of this change? Or have I got the wrong end of the stick, and this check includes snapshot / pre-releases?

Comment by Jakub Skoczen [ 28/Jan/19 ]

Marc Johnson Adam Dickmeiss We have discussed that forcing "release dependency check" on the PR level would create a need for many backend releases through-out each sprint. Instead, the proposed solution was that each sprint we would only perform one release for both backend and front-end and perform this check only during UI module release procedure ( FOLIO-1631 Closed ) and when updating the "folio-release" environment ( FOLIO-1577 Closed )

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