A modern programming language that makes developers happier.

kotlinlang

*Repo and CD Strategy*
I saw some talks about this over a year ago, but I'm wondering if more of a best practice has been discovered since. I would like to know the best way to structure a repo for a new shared module that will be accessed by 2 existing native apps. One Android, one iOS.
This is my current plan:
Store it in the android repo. To build for iOS, pull down the android repo, and set the folder path to the common build script. For CD, publish the pod to a private repo (with it's own versioning an release process) and adjust the location of the pod for the CD build.

Why not just have everything in the monorepo?

Not a bad idea. I would just move ios into the android one, or vice versa. Any drawbacks? It may make it more tricky to differentiate and trigger builds for CD? How will it know which app to build based on which files have changed in the repo?

Depends on cicd vendor but pretty much all of them support repo subpaths matching for the builds

<@UL1A5BA2X> any tips on managing git branching with a mono-repo? We already struggle to make it work with 2 iOS apps in 1 repo. Adding 2 more Android apps might be a bit messy.

That's basically what we use, except for the release branches. maybe that's what we are missing

Ideal state of monorepo is where a global release is defined by a single commit. That's both your apps releasing in sync. Maybe explore what you could change in your business flows to facilitate that instead?

When you get there, you can do a simple trunk based development

Hmm that will never happen, we acutally have 2 totally different products in the same repo currently :confused:

Ouch. Then they shouldn't really be in the same repo. In any case, you'd probably be best using two different groups if tags to release instead of release branches

Yeah _eventually_ they are supposed to merge into the same product. OK my current hypothesis:
• Move all 4 apps into the same repo
• Set up triggers based on folders changed in CI/CD. Changing a shared module will trigger multiple sets of tests.
• Continue merging to main when an app reaches “ready for regression tests” stage (we already give commits tags when they actually release)