Platform, DevOps and Release Management
(UXPROD-1814)
|
|
| Status: | Closed |
| Project: | UX Product |
| Components: | None |
| Affects versions: | None |
| Fix versions: | Q3 2019 | Parent: | Platform, DevOps and Release Management |
| Type: | New Feature | Priority: | P2 |
| Reporter: | Jakub Skoczen | Assignee: | Jakub Skoczen |
| Resolution: | Done | Votes: | 0 |
| Labels: | NFR, cap-mvp, platform-backlog, po-mvp, q3-2019, q3.1-2019 | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original estimate: | Not Specified | ||
| Attachments: |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Issue links: |
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Epic Link: | Platform, DevOps and Release Management | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Back End Estimate: | XL < 15 days | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Development Team: | Core: Platform | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| PO Rank: | 9 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Rank: GBV (MVP Sum 2020): | R1 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Rank: Lehigh (MVP Summer 2020): | R2 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description |
|
(Q3 2019 portion which represents rollout of this feature across platform-core modules, most of the functionality has been implemented in Q2) Problem statement The goal is to build the "preview capability" and integrate it with the PR process by providing a link to an environment as a PR notification from the CI. The link should be used by the PO to verify and accept or reject the feature. Description This capability aims to enable POs and manual testers to review development work before that work is merged to the mainline branch (usually "master") of any given FOLIO module repository (with the focus on ui- module repositories). The review would be performed on a FOLIO environment deployed at the point in time when the PR is created – hence it will be isolated from other changes that happen across FOLIO module repositories (changes by other teams or unrelated changes by other developers within the same team). If the review is unsuccessful, the PR is closed and additional development work is performed on the feature branch. Once additional work is completed the PR is re-opened. If the review is successful, code review is performed by the developers responsible for maintenance of the particular FOLIO module repository and the code is merged to the mainline branch. At this point the PR is closed and the preview environment is destroyed. In order to assemble a FOLIO system that will serve as the basis for the preview environment, the CI process running during the PR must provide a "baseline" platform (stripes container and a set of backend module dependencies) for the particular module for which the PR was issued. In order to do so, the CI system will rely on released FOLIO modules and artefacts (see
There are, however, use cases when the developer of the feature may want to rely on unreleased (aka snapshot) dependencies – e.g when a particular feature spans multiple modules and assembling and testing the entire feature would require performing partial module releases that's not been tested for the particular feature. This should be supported but should be tightly controlled by the developer. Any such snapshot dependencies will be refused by the (existing) CI quality gate during the module release process. In order to perform a release the developer needs to convert any such snapshot dependencies into release dependencies. Please see the attached diagram FOLIO dev and release process.pdf Consequently, with "PR environments" operational for all ui- modules in FOLIO, the non-isolated and shared "folio-snapshot" environment will no longer play the role of supporting PO and manual tester reviews for new features. In terms of more general (e.g end of quarter) functionality review and testing, those will be moved over to the "folio-release" environment (see
Implementation notes The implementation can be performed in two stages: 1. Provide the ability to construct the PR environment based on released platform artefacts only – this limits the scope of the task and avoids building additional mechanics in the CI to to construct "mixed" (releases plus snapshots) environments. It does not support directly the use case of building features that span multiple modules but still allows it by developers performing early releases in modules (usually backend) that include partial dependencies for a given feature. This is effectively the scope for the PoC (
2. Add the ability to include snapshot dependencies in the PR environments – e.g by clearly expressing snapshot dependencies in a configuration file provided along with the PR code (e.g "install-extra.json"). This additional configuration would be picked by the CI build process and allow providing snapshot dependencies in the select cases. The configuration file could be merged to the mainline (with any conflicts needing to resolved at the point of the merge) but it would have to be removed during the release process (CI disallows any snapshot dependencies for released artefacts) The actual implementation of the CI process may require new approaches in how the FOLIO reference environments are orchestrated – due to potentially large number of feature branches and PR across FOLIO modules at any given point – the existing approach to deployment used when constructing existing reference environments may not be sufficient. See
|
| Comments |
| Comment by John Malconian [ 05/Apr/19 ] |
|
This is a large undertaking - obviously. One of the primary concerns I see is the necessity of providing some kind of full FOLIO stack for every PR just so one module can be "previewed"/tested. The likelihood of a problem with something other than the actual candidate module to be merged is high. To reduce this risk, only the absolute bare minimum of components needed to support the module in review should be included in the stack. One way to approach this is to break down 'platform-core' and 'platform-complete' into a smaller subset of platforms.
There most likely are others. Breaking down the platforms into smaller subsets will allow greater autonomy by various development groups to manage and be responsible for their own platforms as well as provide integration tests for each platform independently. Although there would need to be some kind of basic guidelines and uniformity in how these platforms should be managed so that they can be pieced together to form 'platform-complete'. 'platform-complete' should eventually consist of only nested platforms. |