Sorry it took me a while to get to this :), hopefully I can be a bit of help.
I think this question can be answered in two parts if I'm understanding it correctly. Firstly is project structure, this is important as the project grows as it's the difference between knowing where everything lives and spending a while remembering where stuff lives. This becomes massively important if you're working in a bigger team.
This might not be directly related but I outline a project structure when dealing with projects that share web and React Native. dev.to/kylessg/a-sensible-approach...
The second part is more tricky, if I understand what you're doing. You're using build pipelines to distribute React Native bundles in a Code Push way?
I've got some (albeit limited) experience of this when taking over a project in expo. The main challenge, at least in my case was being able to push builds that may be incompatible with certain app versions, this would be due to any native changes the update relies on (e.g. adding something like react-native-fire-base in an update).
Here was the release approach I took:
Per major release (a release that has native changes), I had 2 builds on TestFlight and Play.
1 - A develop release (points to dev API, intended for UAT)
2 - A production release (points to prod, intended for production)
CI Pipelines were setup Pushing to any release/* branch deploys a JS bundle intended to the develop release, merging that into master builds a production JS bundle.
The problem came however when pushing a JS release that had native code changes and therefore was incompatible with the current native release. Here's how I approached this with CI and Expo:
Create a branch called /release/x.x.x
Update .gitlab.ci.yml to push to new release channels
Append major app version to release channels in AppConstants.javaandEXShell.plist`
Push a native version to testflight/beta that points to develop.x.x
Push a native version to testflight/beta that points to production.x.x
When happy with UAT merge release branch into master
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Sorry it took me a while to get to this :), hopefully I can be a bit of help.
I think this question can be answered in two parts if I'm understanding it correctly. Firstly is project structure, this is important as the project grows as it's the difference between knowing where everything lives and spending a while remembering where stuff lives. This becomes massively important if you're working in a bigger team.
This might not be directly related but I outline a project structure when dealing with projects that share web and React Native. dev.to/kylessg/a-sensible-approach...
The second part is more tricky, if I understand what you're doing. You're using build pipelines to distribute React Native bundles in a Code Push way?
I've got some (albeit limited) experience of this when taking over a project in expo. The main challenge, at least in my case was being able to push builds that may be incompatible with certain app versions, this would be due to any native changes the update relies on (e.g. adding something like react-native-fire-base in an update).
Here was the release approach I took:
Per major release (a release that has native changes), I had 2 builds on TestFlight and Play.
1 - A develop release (points to dev API, intended for UAT)
2 - A production release (points to prod, intended for production)
CI Pipelines were setup Pushing to any release/* branch deploys a JS bundle intended to the develop release, merging that into master builds a production JS bundle.
The problem came however when pushing a JS release that had native code changes and therefore was incompatible with the current native release. Here's how I approached this with CI and Expo: