DCB release and development model

Owned by Gurleen Kaur1
Last updated: Nov 17, 2023 by Tetiana Gusar

1. Branching Approach

New Modules

  • No changes to the development process
  • Will ONLY be deployed to the MOBIUS cluster

Existing Modules

  • Total of modules. 3 BE and 6 FE.
  • The long branch called “DCB” will be created from the latest release tag of the module.
  • Changes will be pulled in to the DCB branch from the b.xy branch by the lead, as needed.
  • DCB branch milestone tag convention - yyyy.mm.SerialNo.
  • Will have milestone tags every sprint for all modules. If the module doesn’t need a milestone tag (if there are no changes) call it out separately.
  • Will be pushing changes from the “DCB” branch into master as needed (team gets to decide this).
  • Release versions will be tracked on the wiki page - DCB Releases - Folio Development Teams - FOLIO Wiki

2. BE new modules for supporting DCB functionality

  • edge-dcb - The purpose of this edge API is to bridge interaction between FOLIO system and external dcb system(external systems like open RS). There are two modules involved in DCB workflow: mod-dcb, which interacts with other Folio modules and edge-dcb, which acts as a gate between DCB and Folio. Locate <–> edge-dcb <–> mod-dcb <–> Folio
  • mod-dcb - The module provides API to store dcb transaction details and call Folio's exsiting circulation api's to execute the circulation flows based on library roles.
  • mod-circulation-item - The module provides API to create and fetch the virtual items.

3. BE Modules modified for supporting DCB functionality

  • mod-circulation - To reuse the circulation code for DCB circulation flow.
  • mod-users - To create a dedicated user-type for DCB.
  • mod-patron - To determine virtual item details for the patron.

4. FE Modules will be modified for supporting DCB functionality

  • ui-requests
  • ui-circulation-log
  • ui-checkout
  • ui-checkin
  • ui-users
  • stripes-smart-components

5. Steps to release DCB functionality for testing before Mobius go live and Q release

Preparation

Before any Q work happens on master, create a long running dcb branch in the affected repositories. This is our long running branch.

There are two goals:

  • Base all future DCB development off of Poppy, not Q.

  • Keep development happening as fast as possible. Don't be blocked by Q features that other teams are doing.

To create your long running branches, in each repository do

git checkout <poppy release tag> # Tag will be something like v1.2.3
git checkout -b dcb v1.0.0 # Use actual Poppy release tag
git push

This will create a branch called dcb which will now be our Poppy base for all affected modules for all DCB work going forward.

Finding the Poppy release for a module can be found here in the platform-complete repository in the R2-2023  branch.

Ongoing

Now that we have our long running branches what follows is the workflow for working with them. This is the same flow for each affected repository.

When working on a new DCB ticket do the following.

Create a feature branch for your work based on the long running dcb branch.

git checkout dcb # Base your new feature branch off of dcb not master.
git pull # Get the latest
git checkout -b <JIRA ticket number> # Such as CIRC-1907
git commit # Add your commits as normal and push


When your feature is done you can now open a PR. Get your approvals and push your changes. When you are ready to merge do not merge this PR directly into master. Instead select dcb as the branch you are merging into in the github UI. Merge your code into dcb. The PR is now closed. Next, go back to the command line and try to merge the new code to master.

git pull # To get your changes from dcb that you just merged into using the Github UI.
git checkout master # Switch into master.
git pull origin master # Make sure you have the latest from master.
git merge --no-commit --no-ff dcb # Merge dcb branch into master without comiting the result.

Your dcb code has now been merged into master. If there were merge conflicts, git will have marked them as conflicts.

To get a quick sense of the extent of the changes.

git diff # Scroll through the result to see what it looks like.


You can also perform the above steps using your Intellij which has excellent merge tools,  which visualize all of the conflicts, and helps a great deal when resolving them. Resolve each one, making sure you understand the implications of each. If you don't, do git blame and see who made the changes which are conflicting with yours.

Resolve your conflicts then commit them using something like:

git add .
git commit -m "Merging dcb into master"


If resolving the conflicts is taking more than an hour or two, leave it and discuss with the team at the next standup. We may consider not merging your changes to master in order to not lose momentum.

Make sure to run all of your tests one more time to make sure you didn't break anything with the merge. If tests fail you have to fix them before pushing to the remote/origin.

Fix anything or if everything looks good, push your merge to master.