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 Bitrise. 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 hill. So as we know, if you are working with react native apps, at the end you have two native applications, iOS and Android. And as we know, each application requires workflows or steps or configurations or requirements and so on. So mainly the react native developers are facing different requirements and processes and workflows for iOS and Android. Code signing hill. So you need to figure out how you can automatically do it, because you need to sign the application before releasing 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 secrets, and then to be able to release it to the app store. And complex configuration, as we mentioned. testing as well. So shall we run the UI testing on every pull 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 pull request? So how we can deal with this process. And slow releases as well. So maybe there's a company that's releasing every two months, which is huge. So because if 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 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 servers problems and how we can, or every day we are dealing with a different problem with the CI. So here, Scott Hanselman from Microsoft is a program manager. He said the most powerful tool we have as a developer is automation. automation is not like UI testing. It's automation for everything. So we 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 tasks that slow down or that 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 ci cd process. So we started with a ci cd strategy and then from the measuring or planning phase. And then we have the strategy for a ci cd. 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 devops adoption. As we mentioned, planning, ci cd strategy, building, testing, beta releases. This is especially for mobile because maybe for web we don't have, maybe sometimes we are speaking in 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 like 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 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 have the CI server and the CI server build triggered and then you are going to the continuous integration process, which is you are cloning the code repository, SSHK for accessing the code, and then start installing, as we know, react Native apps required to like npm install or yarn if you are using your yarn. 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 will all check pass. So this is like the first stage. This is for the react Native or maybe for the javascript or typescript application. Then you have iOS build. From here, we start to differentiate between iOS and Android. And as we know, as I mentioned, it's totally different requirements and the step. So for example, here, maybe you need to run or install like start installing the Cocoa Puffs dependences, then Xcode build, and then AutoCode signing. So there is like a mechanism or a step for AutoCode signing or like signing the application automatically. And then at the end, you will have the IP. Maybe then after that, you can run the end-to-end UI testing with maybe it can be with Detox, which is the framework that support react Native apps, or maybe you can use npm. This is an 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 like 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 scratch. So this helps 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 as a tester 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 will give us the application. And then we are 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. But 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 implement the CI-CD 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 test and integration. 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 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 action. So for example, here 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 you can have a task or action. It's called action. 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 deploy. 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 how we use like dedicated servers or our infrastructure for CICD. As we mentioned previously in the challenges, we have a problem that maybe sometimes we have a flaky like configuration issues in the CI server. So this is usually you need to start to think about the cloud CICD or cloud continuous integration. Because easy project setup, you can just like clone your project on GitHub and start building it. Ready-made environment, especially for mobile. So you can imagine if you have a clean environment and every time you are installing in VM or yarn, but if you have a predefined environment that's 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 test. 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. CICD is a coordination process between the different teams to remove any silos from the operations, development, product, and so on. Test automation is a vital part of mobile devops. And it's a journey, not a destination. As we know, it's accumulated work during maybe one year to reach to this full cycle for the process. And thank you. Thank you. Thank you.