A Nutshell Guide to React Native DevOps

Hi, everyone. Thanks for having me today. My name is Motez and I'm working as a developer advocate at Bit-Trice. So, mainly, every day I'm helping the mobile developers to trying to figure out what are the challenges that they are facing, especially with cross-platform apps or native apps.

So, today we are talking about the mobile deployment. So, as we know, if you are working with React native apps, you have at the end you have two native applications, iOS and Android. And, as we know, each application required like workflows or steps or configurations so on. So, mainly that React native developers are facing like different requirements and processes and workflows for iOS and Android. So, you need to figure out how you can automatically doing it because you need to sign the application before using it to the App Store. As we know, it's not like the web application. You need to sign your application or certificate or provision profile or like secrets and then to be able to release it to the App Store.

Complex configuration, as we mentioned, testing as well. So, shall we run the UI testing on every request or shall we leave it before release? How we can run it? Which framework we are using? Shall we run the unit and UI test and everything for every request? So, how we can deal with this process? And slow releases as well. So, maybe there's a company is releasing every two months, which is huge. So, because if you are like, you have a business and you have different competitors in the market, which is if you wanted to release a new feature, this is a huge or a longer process to release every two months. So, we need to try to eliminate the process for two weeks at least. Like, two weeks release cadence. And inflexible and fragile CI. So, don't waste your time for fixing the CI server's problems and how we can or every day we are dealing with the different problems with the CI.

So, here, Scott Hanselman from Microsoft, as a program manager, he said like the most powerful tool we have as a developer is automation. Automation is not like UI testing. It's automation for everything. So, it can automate deployment, releases, code review or anything as much as we can, we should automate the process. So, the target is we need to spend less time on task that's slowed down or the developer downs and focus more on delivering the features. Because as we know, the developer hours is the main focus or the most important things for the companies. So, because of this, I believe the process that will fix these issues or these challenges, it will be a mobile DevOps or a mobile CICD like process. So, we started with a CICD strategy and then from the measuring or like planning phase. And then we have the strategy for a CICD. And then we are building and testing or releasing and building our mobile apps. And then we are monitoring our mobile apps.

It's not like we just release it to the App Store. No, there is another stage for monitoring mobile apps. Such for example, if you wanted to monitor the app crashes or the application performance monitoring in general. So, once you release your mobile apps, you have another tool or another process to start reviewing and monitoring the mobile app release.

So, here we have six steps for a mobile developer adoption. As we mentioned, planning, CICD strategy, building, testing, beta releases. This is especially for mobile. Because maybe for web we don't have... maybe sometimes we are speaking in a web deployment about canary deployment or like blue-green. But this is required for mobile apps, which is beta releases that you are releasing to your beta testers to check that everything works fine in your application. And this can be for test flights, for example, for iOS or for Firebase app distribution or for the App Store, for internal channel. And production releases. And then we have a monitoring.

So, here, let's assume this is like the full process. So, I'm trying here to figure out how we can automate this process. So, for example, you just, like, create a code or like push a code. And then to the GitHub or any source code you are using, the request is raised. Maybe you can you have the CI server. And the CI server build is triggered. And then you are going to the continuous integration process, which is you are cloning the code repository, SSH key for, like, accessing the code. And then it starts installing, as we know, React native apps required. So, like, if you are using your ER. Then you can start running the static code analysis. This will be like the first step. Then you can run a unit and integration test. And maybe you will have a coverage report. And then if everything is okay, it'll check bus. So, this is like the first stage. This is for the React native or maybe for the JavaScript or TypeScript application. Then you have an iOS builder.

From here, we start to differentiate between iOS and Android. And as I mentioned, it's totally different requirements. So, for example here, maybe you need to run or install like start installing the KukuBots dependencies, then Xcode build and then auto code signing. There's a mechanism or a step for auto code signing or signing the application automatically. And at the end, you'll have the IP.

Then after that, you can run the end-to-end UI testing. Maybe it can be with Detox, which is the framework that support React native apps or maybe you can use Appium, this is the open source for mobile apps. And then you are uploading the artifacts. Then if everything is okay, so now we are continuously like doing the stages or step by step. And even if we have a problem, let's say we have a problem in the continuous integration stage, maybe in the unit and integration test. This will be useful for the team because in this stage, you found the problem early. So, if you are running UI test or unit test or integration and then it's crashed or you have a problem, then you will figure out in the early stages in the development so we are still in the pull request.

So, you can imagine this issue is the customer find it on the app store or in the application after release the mobile app. So, you need to release another version or another hotfix and you need to do this process again from the scratch. So, this help us to fail fast. So, this is like a concept of fail fast. So, we are failing fast and we are here like moving a shift lift in testing and running is a test in early stages on the code development to avoid any other problem or issues on the life or the production. This is the same for iOS, it's only the different things here, we are using different comments like, for example, for Android, we are assemble or run the bundle debug task which is will give us the application and then we are signing your application, signing our application and then also it will be the same for running the UI test or running the end-to-end test. With continuous deployment we are here, maybe we can run like deploy to the Firebase app store distribution or to Google Play Store. Here, we will find another challenge. So, shall we run all of these things in sequential like run the iOS build first and then run the Android in one workflow? This will be the problem, so maybe it will take time. So now, we need to think about another challenge after we implemented a CICD solution, which is pipelines. So, we can run different workflows in barrel at the same time, for example, let's assume that the first one is a workflow one which was the continuous integration to running a unit of jQuery. So, we can run it first if it's green, so then, we can start the iOS and Android in barrel at the same time, to save our time because now, if we are running this and before releases, this will take time. So, now, we can think about the build pipelines. And also, we have another choice. You can implement or you can use a Fastlane. Anyone here using Fastlane? Okay. So, Fastlane is a Ruby-based file. It's a Ruby configuration file.

It's called the FASTA file. So, with FASTA file, you can configure everything as a task or as an action. So, for example, here in Android, in Android section, you can, for example, have, like, submit a new beta to, like, Crashlytics or to Firebase or Crashlytics from Firebase. And for Android, for example, you can have a task, a specific task for uploading it to the test flight for beta testers. So, here is, you can have a task or action. It's called action and that. So, you have different lanes as we find here. So, the description, this is the lane. So, we have a lane is beta and the lane is deployed. And for iOS, we have lane beta as well. So, you can add incrementable number, which is because you are releasing a new build. Or taking screenshots for the metadata or for the App Store and also deploying it to the App Store, you can have like another task for this one.

So, now, to fix this problem or the challenges that we are facing, we need to think about, shall we use like dedicated servers or our infrastructure for CI-CD? As we mentioned previously in the challenges, we have a problem that maybe sometimes we have a flaky like or we have a like configuration issues in the CI server. So, this is usually you need to start thinking about the Cloud CI-CD or cloud continuous integration. Because easy project setup, you can just like clone your project on GitHub and start building it. It really makes the environment especially for mobile, so you can imagine if you have a clean environment and every time you are installing in VM or you are, but if you have a predefined environment is included all the tools that you are using for your mobile app, this will save time for sure. And the customizable workflows, as we know, we have different workflows for iOS and Android, seamless code signing for iOS and Android and automated unit integration and the tests, there are different steps can help you in this process. And distribute react native app was easy.

So at the end, the idea is a mobile DevOps is a mindset. But we need to agree as a team, which process or which platform we need to use. It's a mindset, culture, process, and the tools. CI-CD is a coordination process between the different teams to remove any silos from the operations, development, product, and so on. This automation is a vital part of mobile DevOps. And it's a journey, not a destination. As we know, it's accumulated work during like maybe one year to reach it to this full cycle for the process. And thank you. Thank you.