Building React Native apps is a fraction of the whole app development SDLC. It comes with a whole bunch of tooling and processes around it. It’s very easy to get lost in the myriad of choices of tools and documentations. So, here I have collated the CI/CD workflows and pipelines in a flow diagram illustration and how we can implement it using Github actions.
Full resolution illustration Link
Github Link: https://github.com/paramsinghvc/Timely
Code Development

- Developers write the code in the IDE of their choice. The code formatting can differ for different devs. To ensure a universal formatting style, tools like Prettier, ESLint and EditorConfig can be used these days very easily.
- As soon as, you commit the code, static code analysis can be triggered on the local machine itself through automated pre-commit hook using husky which can be configured as follows in package.json.
3. Once the checks pass, the code is committed and you can push your branch to Github.
Continuous Integration — I

In the first pass of CI pipeline, we perform like linting, testing, coverage reporting whenever a Pull Request is raised against a specified branch, commonly develop, preprod/staging and main/master to ensure code quality and nothing broken gets merged into these important branches.
The steps can be represented by the github actions yml file as follows:
Here, we’re defining a job to run on a trigger action which is whenever a PR is raised against master, develop or preprod branch. It can be summarised in the following steps:
- Checkout your repository
- Install NodeJS and configure version and package manager as yarn
- Install node modules using yarn ci which looks like this in package.json script
"preci": "rm -fr node_modules","ci": "yarn install --frozen-lockfile"
4. Run lint command to run eslint
"lint": "eslint src --ext .js,.jsx,.ts,.tsx --fix",
5. Run Unit & Integration tests using jest
6. The last step is an optional decorator action for PR with coverage report as

Continuous Integration-II
After the install and test step, we want to make sure that the builds are passing while the PR is being reviewed.


Both of these point to other reusable workflows viz android-build.yml and ios-build.yml
Note how secrets: inherit
are being passed as it’s important to do, otherwise the secrets referred in those files won’t get populated. More on Github Secrets here
iOS Build
The ios-build looks like this
