The best way to structure React Native git project?

Hi devs, for the last couple weeks, I was working on a react native project and at this point, I think I need to think seriously about the best ways to structure my git repo especially after implementing a circleCi for releasing App.

As you know we choose the react native to build a cross-platform app ( android and ios ) so we have multiple build types

• Beta version for android ( deployed on fabric.io)
• Beta and Prod version for IOS ( using testflight)
• Prod version for android ( google play)

CircleCI can run builds only based on the branch.

I am searching for the best ways to structure my git repo ( branches ) and git workflows.

Comments

[Kyle Johnson]

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