 Hello everyone, I am Abhinanda and I am Product Engineer at Gojek. So before we start like let's do a quick recap of the day. So we started the day with Arun stock on the different strategies that you can use to optimize your network performance. And then the next stock was by Pratul. It was about the best practices that you can have, how to improve your culture and everything. And then we moved on to talk from Mintra about the progressive web apps and their future. After that we had a discussion on how to scale the mobile apps and there was a final discussion. And then we moved on to the security talk from attackers perspective. Then next was the lotty talk here and here we are to the last talk about the CI CD. So this talk is our journey or so it's like my thoughts about our journey at Gojek about in the that we had in the mobility. So about me, I started at the backend team in Gojek by working on Golan, JRuby and all. Then after sometime I moved to the DevOps and infrastructure automation team. I was working there on Chef, Ansible and the different cloud platforms. And then since the last one and a half year I am part of the Android and the release engineering team at Gojek. So I have used my learnings from the previous teams that I have worked with in the Android team currently. Also my talk is inspired from my previous talks at RootCon fan, DroidCon Poland that I have given in the last year. Gojek has grown by 900x times in the last 18 months that is like 90,000% and Gojek is app only platform. We only have apps the Android app and the iOS apps on Play Store. So we don't have any website. We have close to 50 million downloads on both the stores combined. So this talk is not about Gojek. This talk is not about growth. This talk is not about the products that we have at Gojek. So this talk is about mobile team journey. So to make this amount of growth possible mobile team played a key role. And so in this talk I will be like explaining how did mobile team evolve or what are the changes that we had in the mobile team to make this thing possible. So coming to the fundamental question, what changed? Can anyone guess? So we started small with few engineers, a very small problem that is like solving a transportation problem for Indonesia. And then now we are at 50 million downloads and solving multiple problems, more complex systems we had and we have more engineers. So there is something that is changed, right? So from the version one of our app to the current version that is 2.28 on Play Store. There is a big change. It's not just the app that we see here and here, this is the change. Behind the scene there is something big that is change in the last 2 years as we grew. So what is that change? So that change is the way we work in our mobile team. So the way we used to work previously when I joined the mobile team and the way we work now, this changed basically. So yeah, so these are the things that also change in the way we work in the mobile team. That is the tools that we use now, the app architecture, the team structure that we have currently, the development workflow that we follow now and the different processes that evolved as we grew. So I will be covering all of them in the upcoming slides. There was one core change which was a driving force that was responsible for all the changes that I mentioned in the previous slide. What was that change? That was moving from nothingness to CI CD. So as like every other startup, we also started small. There was no CI CD practices or tools available, we were not using any tools. And then as we grew there was a need of moving to CI CD. So then we started following the CI CD practice. Previously we did everything manually. We used to build the app on one developer machine and then upload it to play store and the app store. We used to do all the testing once the app is built on that developer's machine and then delivered it to the QS. So from that to following the CI CD practice automating everything, this is what was the core change that we had at work. And then we grew further. We migrated from one CI CD tool to another CI CD tool. This was another change. So this was mainly driven by the requirements or the problems that we were facing at that time. When we decided to experiment with something else and then evolve our practice. So why did we do it? We migrated from Bitbucket to Jenkins. Bitbucket plus Jenkins setup that we were using previously to GitLab. So why did we do it? What impact we had after moving to GitLab? And what were the advantages of using GitLab over Bitbucket and Jenkins for us? And how did this setup help us to scale and grow? How did it simplified everything for us? And I'll be covering all these answer to all these questions in my upcoming slides. Before we move on for those of you who don't know what CI is or just a basic refresher on what is continuous integration. This is the textbook definition from the Jeff Humble's continuous delivery book. That continuous integration is a development practice that requires developers to integrate code into a shared repository. So you have to have a Git repository where everyone in the team who are working on the code base needs to check in their code. And then once that this code is there, it is automatically verified by the tools, automatic testing tools, whether you run unit test or integration test or UI test. And so how does this help? But since we have testing on every command, this helps us to detect problems easily. So that since the problems are detected early, that could be solved early. Which was not the case when we had, we did not had any CI practice. So CI is a development practice that we should follow. Which tool to choose is a question. So there are a lot of tools in the market. You can choose any of them. Whichever fits best for your organization that works for you well, you choose it. There is no hard coded or defined guidelines. If you, you can start with as small as, spin up a docker container on your own box of a image. You can say a Jenkins image or any image and spin up that docker container. You can run the CI. No issues. Or you can host your own CI setup. Or you can use any of the already hosted CI setup available. So it all depends on your scale, your requirements and whichever tool your team is comfortable using it. So that system has to be very easy to use, configure and it has to have a good support and a community around it. These are the few things that you can keep in mind while choosing the CI tool for your. So these are the benefits that helped us to move to CI. Like we had this big problem of since it was the last day before the release when all the code was merged. There were some bugs which were, we were not able to catch them. So now after moving to CI, we are able to catch these bugs early. And also since we can catch them early, we can fix the problem early. CI also gives a big advantage of having, creating a visibility in the organization. So there is a dashboard and everyone in the organization can view it. So if you are having multiple teams working on the same code bit, you can have a dashboard. If there is something wrong, if the build is broken or the build is read, then people know, ok, we have to fix it. And then this CI also helps us to create a solid foundation. So you spend less time in debugging things and building more features. So and the next advantage is you don't have to wait for anything. So just push your code and CI will build it, test it and yeah, that's it. You, once you have the build finished, pipeline is completed, then you have the reports and the results. If the build fails, then you need to look it, otherwise CI does it for you. This will help you to deliver your features rapidly. To start following CI, seed in your organizations, you need to follow these practices. These are again from the continuous delivery book by Jess Humble. So these are the practices that you need to follow your working on CI. So developers check out code into their private workspace. So since it is a single gate repository and yeah, this is the most important one. It has to be a repository, shared repository. It cannot be Dropbox. It cannot be pendrive that you are ok or it cannot be a developer machine. So you are passing on the code around the FTP server or something. It has to be a version repository. So once developers check out that, pushes the commit or makes a commit to that repository. That whole source code is taken by the CI tool and CI tool builds it. Once the build is finished, it does the unit testing. And then after the build is done, we have the artifacts. It passes on the artifacts to the next phase of the CI practice that is testing. So this testing phase then runs the integration test or the UI test and other different kinds of tests that you have in the pipeline. Once yeah, next one is the build has to be self-testings. The testing has to be integrated on CI. If there is no testing on the CI, you cannot follow that practices. It has to be automated in some manner. You can start small in the beginning but yeah, you have to add more and more tests and more and more kind of tests later. Every commit that you do has to build on a integration machine or the CI server. If there are any broken builds, then you have to fix them immediately. Next one is the build has to be fast. The whole concept of CI CD is based on feedback. The faster the feedback is, the faster you get the reports and analysis, it would be better for you. CI server also assigns a build label to every build or every artifact that it produces. And if the build is successful, it informs the whole team via some kind of mechanism, whether it is a dashboard or it is an email or it is a Slack integration. It informs everyone in the team if the build is successful and if the build fails also then also it informs. And if the build fails, the team has to fix it. Since I also mentioned in the advantages or benefits that everyone can see what is happening. There is a dashboard, the CI dashboard has to be hosted publicly, at least internal to the organization. It does not have to be a private IP with username, password, base, access that only the admin can see it and he will only monitor the build. Everyone needs to have the visibility in the organization. And then you can automate the next steps that is like the project. So, you as in team members, if you are working on CI practice, then what are your responsibilities? Check in as frequently as you can, make small commit so that if there are any bugs or problems, they are detected early. Don't check in broken code. First, make sure the build or the test runs successfully on the local box. Then only you push it to the remote repository so that CI can build it. Also, don't check in the untested code. Don't check in when the build is broken. If the build is already red and you have seen that, then don't push the code to make it more problematic to debug, whether your commit costs the build to fail or the previous one. Also, the last one, don't go home after checking in. Wait for the system to build to give the feedback to finish the testing and the different. Continuous delivery is just an extension to continuous integration. So, you hook up the delivery part to continuous integration and you trust the automated test. So, once you, so let's say you have made the commit and if that commit passes all the phases like it builds the app, it runs a unit test integration, everything passes. And then finally, the app that is built, it is automatically deployed in production in terms of iOS and Android. Let's say it gets uploaded to the app store. So, if you have that kind of automation, then you will call this as continuous delivery. So, why GitLab worked for us? One of the main advantages that we switched to GitLab was the code, the CI and the CD. Everything was at one place. So, we did not have to go to Bitbucket separately to comment and then to review PR and then come back to Jenkins to see the build dashboard and then then again go back to Bitbucket. So, GitLab had this feature of hosting your own source code and then it has its own CI, CD, set of it. GitLab is also open source and it has a very good community. Also, it has two editions available that is enterprise edition and community edition. Community edition is to use, you can host it on your own infrastructure. Or if you also want to use the public GitLab, you can use that. Or if you want to buy the enterprise setup, that will also work. So, open source edition or the community, sorry, not the open source, the community edition has all the features that are required for following the CI, CD practice. So, we decided to use that. It is also easy to use and very easy to set up. And the most important advantage for developers or my team members who are working with me in the Android team is this to configure CI, CD for your own repository whether it is Android or iOS. It is only yamen-based configuration. So, in Jenkins, we used to do it with groovies that was a little bit hard for everyone to understand. Here it is just plain yamen. I will show the pipelines that we have for Android and iOS in my upcoming slides. Yeah, coming back to what changed. So, these are the things that I have mentioned that changed for us at Gojek. So, starting with tooling. Yeah, we introduced automation, integrations like Slack, email, Jira and all. And then alerting and analytics also on the build process. So, GitLab provides all the features. It has like exhaustive set of features in community addition as well that you can use. Then another advantage of GitLab is the multi-runner. It runs on all the platforms. You want to run it on Docker, you want to run it on Mac, Linux, Windows. It has a multi-runner for everyone. I will cover what is the GitLab CI multi-runner and the architecture that I will explain in the upcoming slides. Commonly used tool sets for CI CD are all available in GitLab. And also if there is something you cannot do with whatever is available with GitLab, you can try the external tools that supports integration with GitLab and also GitLab has exhaustive set of APIs like Curl, you can just do Curl request or something and integrate it. We also use Fastlane and Cocoa Word for iOS, building the iOS app and Griddle build tool for building the Android app. So, these are the tools that we are currently using. The next one is app architecture. So, our app architecture also changed when we were in version 1 of the app to the current version that we have. By app architecture, I am not referring here to MVP or MVVM or Redux or Viper. The app architecture here is we switched from a monolithic repo to a multiple repo-based architecture. So, what was a monolithic repo? Or most of you might know that ok, we have just run Android repo, we write all the source code into it and we build that out of it and same for iOS. For us, we started with monolithic repo and it was like soon it turned out to be a very big codebase which was difficult to manage. So, the main problem was the build time. So, we had 20-minute build time for Android and 60-minute build time for iOS. It is a big build time. If you are a developer and you have to wait for 20 minutes, after making just one change and then test that, it is a big build time. So, we needed to have a way so that at least this build time reduces. So, and then on the day of the release, at least like two or three days before the release, it was a big PR help. All the developers like used to send PR and then you have to review them, merge them and sometimes it used to take even like four or five days to get all the things merged and then test it and then do the changes and then reduce. It was also difficult to track changes. Since like the app is scaling, we had so many features and also there were so many changes. It was so much difficult to track in one single. Also, the code was helicoupled since everything was there in one single repo. So, we needed to split it. So, how did we split it? Like, so we broke this Android and iOS repo, the monoliths into roughly 40 product reports. So, what I mean by product repo is, so each repo in iOS and Android will be a product repo and we have different products, go pay, go ride, go food, go mart and all. So, each of them were having a source code relevant to that product only. There were some duplications and all. We tried to mitigate that using some of the repos that were having a common code relevant to like let's say 4 or 5 product repos and then including that module into it. So, the advantage now is the code is decoupled. It's easier to work. You know that okay, if you are working on a go food repo, the code is only related to go food. This also led to faster development cycle. So, and then all these 20 iOS and Android repos now deployed the artifacts. So, we now build ARs or the artifacts and then we push them to the artifact. So, these are the product repos that we have at GoJet. So, starting with auth, base, booking box, busway, food mart, home, paypoint, school stuff, you know. And then these are the two repos, common config and mobile code checks where the common code that is needed by all the repos is there. And similarly for the iOS also, we have different product repos. And once we have this GoJ consumer app Android and GoJ consumer app iOS, this is the final app container. This is the final app that uses all the rest of the 18 or 19 modules to build the. The advantage now is every product had its own CI CD setup. Previously we had just one pipeline and now each product can work in isolation. They have their own CI CD setup so that we can get more fine-grained metrics to track the test coverage and other things. Also like now the product teams are after this architecture change, the product teams are now more aligned. So, let us say Gopu. Gopu has some feature and if it wants to participate in the release, they can work independently and they can decide whether they are ready to participate in the release cycle or not. Previously it was like, if there is a last moment change, it was difficult to like revert if it was a model. So, those kind of small add-ons. Then now the productivity also increased, right. Previously everyone, all the developers are working on one single code piece and now you have to just work on the smaller subset of the code piece. And then finally all the modules get smushed and into the final app container and that is like tested and then released to Play Store. So, yeah, we use Artifactory, JFrog Artifactory for dependency management. So, yeah, I have mentioned the common context. So, these grader files, so everything that we did, breaking into multiple reports from a monolith, most of the things we were able to like do it with grader. So, like mobile code checks, so all the Lintrules, Feinbergs, PMD, all the checks, automated checks that you need to do for all the reports were here in this files. And then all the dependency management related code was there in the dependency.grader. Yeah, moving on to team structure. Team structure also changed. Previously we had technology specific teams. We had Android team and then we had iOS team. So, and they were working on their monolith reports and then we now have regrouped these product teams into different subsets depending on the product they are working on. So, product team have their own report to work with and they can decide how to participate in the ring. So, it's similar to the microservices concept that we have at back end, breaking one big chunk into smaller teams, smaller code base. And so, now this front end product team is focused only on that product. It does not need to care about what is happening in other product teams and all. This does not mean that we don't communicate with other developers in the organization. We do, but yeah, you are just focusing on your product. The inter team and intra team communication also improved in the multi repo structure and coordinating the release was easy. On the day of the release, all you have to do is just take the build from the CI and upload it to play store because all the code reviews and everything merging, building the final app is done by the CI and that are mostly handled at the team level. So, and final app is also tested before uploading it to play store. So, this is the team that we have currently in every product team we have Android devs, iOS devs, a designer or maybe more than one designer and back end devs, then we have QA, PM and product owners. As I mentioned that our build times were reduced both for iOS and Android from 20 to 1 minute and 60 to 1 for iOS. So, previously it was one repo, we pushed the code, we build the app and tested it, ultimately build the artifacts and then release it. It was all done locally on one developer box. After moving to CI now everything is mostly all of them are handled by GitLab. So, also we did some tweaks around the GitLo to make it work for our organization. So, it is not that this is a practice that I am teaching you to follow this. You can work on this, you can have something better. So, this is just an experiment that we did, it worked for us. Maybe it won't work for us like in the near future. So, currently we are at 50 million dollars and now if we move from 50 million to 1 billion there would be something that we definitely need to have changed. We will face the problems at next scale. So, these are the tweaks that we did. So, we have we follow this 30 to 40 to 50 to 62 convention. So, we have three branches on each product repo and on the final consumer app. So, if you are working on the current feature, you get your code merge to develop and then the artifact is published and that is deployed to the artifact tree. So, stable is the version that has already gone to alpha and then the master is the version that is already in the play store. So, if you are working currently then on the date of the code freeze or on the day of the release cycle, the last date of the release cycle, you just move all your code from develop to stable and then we release the alpha app version and also start the full cycle testing on the stable version. And then after everything is done, alpha app works well and that like the feedback from the store is good then we move that code from stable to master and then finally the app is released from the master. If after going to play store, if there are some bugs or some crashes that happens that were not caught in during testing, we do the bug fixes accordingly. So, if it goes into play store and then if there needs to be some hot fix release needs to be made, we fix that on the master branch and then we bump up the version and release it. Similarly, on the stable branch, if the app is in alpha and there is some feedback from alpha users, we bump up the version of the stable branch itself and the rest of the team continues to develop on the develop branch. And this anything other than this naming convention is basically a 32 version artifact that is deployed which you can use for testing, you can say locally or if you are working on a feature branch, you can get the 32 artifact and then make the app using that and test it before even merging to that. Yeah, this was all of this was gradle magic. So, there was nothing like some magic happening that I did or someone did in project. It was all gradle magic. So, the 32, 42, 52, 62 I mentioned all of the corresponding versions are replaced here and then the transitive is set to true and yeah and the final app knows that okay, it fetches only the artifacts and it does not need to fetch the dependencies that are mentioned in that particular artifact. So, let's say if busway is dependent on base library, it won't fetch base library. Okay, processes also changed. So, previously someone, so this is a thought process like previously someone was managing CI for me to I manage my own CI. All the product reports they manage the own CI now. So, we have close to 70 member mobile team and there were a lot of people problems, communication problems and all. So, most of these were solved like coordinating with the QAT, giving them the build and all. After having the CI CD practice, like most of them were solved. It also simplified a lot of processes and software development like PR review, merges, testing and all this. Everyone releases the app. I got to point this thing out. So, it is not just me who knows everything how to have this whole CI CD setup and how I only know that okay, this is how you release it to the Play Store. So, we follow this practice every release cycle. We nominate one Android and one iOS Dev. So, they are responsible for coordinating the whole release process, following up with the testers of different product teams and like and then finally till the app is uploaded to Play Store and even after the app is uploaded to Play Store, if there are some patches or not, they will monitor them and then like respond to the fixes if there needs to be any. So, everyone knows everything. It is not just one person who is like having the knowledge of the whole release process of the app. Since the code was modular, the testing and the review process became a lot more easier. So, testing, unit testing, we have like both for Android and as we have unit testing, unit testing is like must to have. Then instrumentation testing is using Espresso. Then we also have something called as API testing. Since the UI testing, so we have UI tests that are running using Appian, which takes a lot of time to run. So, before even starting that, we just make sure that okay, all the APIs are working correctly or not. So, we do that using the API testing. And yeah, we are using few open source tools, one of them is like OpenSTF. So, to remotely manage the in-house test lab that we have. So, this is the test lab that we have. A set of 20 Mac Minis, which has the GitLab, CIE that are installed on them and physical devices connected to it and which runs the Appian test, the Espresso test on the day in and day out on every commit that we do. Also, we have a nightly running regression test. So, running a regression suit on every commit is a big difficult because now we have so much of tests to run. So, we run, we trigger like regression suit at 12 a.m. in the night every day. Release process. We follow two week releases mostly and sometimes maybe in two months, once in two months or three week releases. And the participating product team just have to push their port from developed to stable. And then after the testing is done, App AlphaFix released, the full cycle testing is done. Then they have to move the port from stable to master branch. Once the port is on the master branch, we release the App to Play Store. And that is also done in the phased and the percentage rollout that is provided by App Store and Play Store respectively. Architecture at Gochek. So, I mentioned about what is the CICD setup that we have at Gochek. So, this is the happy mobile developer who pushes the port to GitLab. GitLab is like GitLab master. Since GitLab is both, it hosts the source code as well as it is a master as well. So, once the code is here, it delegates the commit to this GitLab runner. So, we have two kinds of GitLab runners. One of them are the Docker containers. And another set is of the Mac OSX in house 20 Mac Minis farm that I have shown you in the previous slide. So, since for Android, you just need Android. It is independent of the OS. So, you can run it on the Docker containers. Whether you run it on cloud or locally, it does not matter. So, we run it on cloud on Docker containers having the Android installed on a base image. And for building the iOS app, for testing the iOS apps, you require Mac OSX to be on your machine. So, for that we have set up this Mac Mini. This Mac Mini also solves us the problem of testing Android. So, for doing the UI testing of Android apps, you need to have devices connected unless and until you are not using emulators. So, yeah, we have set up that also on this Mac Mini farmers. And this both kind of runners are connected to GitLab. So, these are the stages that we have. So, this is a GitLab CI.AML file. Very easy to write and manage and learn. This is for Android, like specific to Android. So, we have these stages, build stage, test stage, API smoke test, US smoke test, UI regression test, UI mix panel regression test. And then the dispute whether we distribute it via fabric to internal users, alpha users or directly uploaded to the store. So, it uses the Android CI Docker image to and runs the command Gradle clean build on the Docker container. And once the build is complete, it archives the artifact and upload them back to the master. So, artifacts are basically the APK files, the test reports or the manifest and the mapping files that are needed for pro guard crash litics, the obfuscation process. So, and there is this last thing that is called as tags. So, Android build is a tag for the Docker containers or the GitLab CI runner that is tagged with like the first set of runners that I showed in the previous slide that are that is Android build. And then this is how it looks on the pipeline view or on the dashboard of GitLab. Similarly for iOS, I use Fastlane to build the iOS app. So, because Fastlane simplifies everything, the provisioning profiles and certificates and keys and everything for the system. And at the end of the stage, we have IPA and DSYM files that are archived and uploaded to master. So, these runs on the runners that are on iOS or the Mac mini form. So, we have tagged them as iOS. Like everyone here will some will say, okay, no, multi repo works for us. So, there is nothing like kind of best practices or something. If mono repo works for you, go ahead with that. If multi repo works for you, go ahead with that. Like mentioned the pros and cons of the different approaches. So, if you have a mono repo, it's easier to navigate. There is no dependency management and all those artifacts reset up and all that. And the cons are if your code grows and yeah, the build times are high unless and until you are using some magical tool like bug or something. And PR review process is complicated if it is a bigger code. And rows of multi repo is modular code. At least this was the advantage for us. When we have split the code into the multi repo structure, the modular code brought in the ownership. Each product team owned its repo. They worked on improving the code quality, writing more tests, making it more cleaner and all. Experimenting with different architectures and all. Even like some of the teams are now even using botlin in some places. So, building that specific module is resulting in faster build time instead of building the whole app every time even on the pieces of code that you have not got done. Cons are integration testing and FCT becomes full cycle testing becomes important because ultimately the final app is the one that is going to restore. It is not your just your own module. So, the testing becomes important and artifacts management is the overhead. What is future for project? So, yeah definitely. So, the current process is working for us. Maybe we are still experimenting with what can we do to make it more faster. So, one of the ways is like we can switch to another build tool by Facebook that is what is bug. Uber uses it, Facebook uses it. They have build times in milliseconds or seconds you can say. But yeah we are heavily relying on automatic code generation using dagger and all data mining and all data mining and all. So, but yeah we have this option in Gradle 4.1. So, Gradle 4.1 is released which also has the concept that is similar to bug. So, this if there is a change in a module then you do not build the whole app completely. So, we are still experimenting and making it more modular. So, the next step is to create more and more modules not just the 20 repos we will try to create like 50, 100 or 200 modules and then try to see if the performance improves with Gradle 4.1. And yeah, summaries and key takeaways. So, the ultimate goal this was covered in the whole day today in Pratul stock, Arun stock and so on. So, ultimate goal is to have happier teams improve developer productivity and there should be no people problems or it should be like at least you should reduce the existing people problems that you have and the communication lies. The third one is the most important one don't just blindly copy paste the strategy whether it is the CSED practice or you are doing anything from ok Google is doing it, Facebook is doing it, Bojake is doing it. Oh, let's do it. It will work for us. No. Try to come up with a strategy inspired from those companies and build up your own experiment with it if it works then it is good then or try to evolve it try to tweak it change it. So, ultimately it has to work for your organization, your scale try to make a manual interaction as minimal as possible that is like go to full automation. You can just for example, you can just have let's say building the app to play store and app store as a manual button that you can press this level of automation you can aim for if not like uploading every time to place for automatic and yes aim for smooth, better and high quality delivery and faster time to market. Ultimately we are building it for users we are building it for customers so you should have faster time to market and for that you need to have a CSED practice in place and evolving tools and processes and everything that I have covered. I also have a workshop on 17th of September. I will be covering mostly the Fastlane and the GitLab setup. It is a hands on workshop. You will be building a full Android, iOS and React Native pipeline if you want to join that and whatever I have covered in this talk will be doing hands on of that. Yes, I have 2 minutes and 17 seconds. If you have any questions go ahead. You are built on a master. Yes. If some errors happen, some bugs are happening then how do you immediately push a new update? So first we halt out the release. So in place store you have seen that option of halt the release. So first we release it to 2% users then 5% then 10% something like that. If we have a crash that is increasing in 2% of users we halt, we fix it, push 28.1.0 and then again continue with the release. What is it? The build time reduced to less than 2 minutes or less. Yes. You are referring to the build time of the complete app right? I am referring to the build time of that particular product repo. So what a product repo is? So let's say we are working on GoFood. So that repository will have a GoFood source code with a launcher activity which will have a trigger to the GoFood. So if you have seen the Gojek app, we have tiles right? Once you tap on the tile, you go into that product and the rest of the flow is related to that product only. So we have a small dummy kind of app which will just open the GoFood flows. With rest everything is in place, the org, the other dependencies are in place but it will just open the GoFood and GoFood related flows. So that product repo, build time or that small app only with that GoFood team is now building in less than a minute. That is like, fine for now. At least having a 1 minute build time is better than 20 minutes and wait for the rest of the score to build in. Android takes 5.6 after moving to Greater GoFood. Yes. Standard of the product? Yes. I have a product which is used by people. Yes. So what are the products used? Yeah, so I mentioned this, you are right. So we have this, let's say GoPay. GoPay is, GoRide also uses GoPay, GoFood also uses GoPay. You can use payments to do any other thing. So definitely this GoPay is used for other reports. So if you want to use, let's say you want to work on 4 reports. So if you are doing some change that requires you to work on 4 product reports, so definitely we fail the challenge how to work on multi-reports structure. So we mitigated that using Gradle. So we had this in settings.gradle, we have this, okay, you want to use more than one module, just mention that and you can work on 4 products. It's just a simple, just mention all those in settings.gradle. Let's say we have a similar project with multiple modules. This module should be released as a public module on Jcentre. Okay. And this module is dependent on sub-modules, sequential dependencies. So unless I release first module, I cannot release second module. And first module's version should be mentioned in the second module. Yes, definitely. Do you think it's completely in one single repository? Yes. Every time first I release one module, I have to update some version in the code and then I have to reduce the other one. Yeah. So how this release process can be managed? So I have to do some code change and then I have to reduce the next module. Okay. So how it works for us? I mentioned this, like this is how we solved it, the 32, 42, 52 and 62 I mentioned, right? Yeah. So the artifact with, so you can use 32, so you made a change, right? Use 32 version of that artifact. And for rest of the other dependencies just used 42. So this is how we solved it. This was the most easiest way that we could do. If you have a new code, if you have some other network, what other network is it? Yeah. So currently the core module that we have is the base. So everyone depends on the base. So if you don't want to, so let's say if send team wants to have their own set of implementation, you can go ahead with it. So all of these, we have given flexibility to all the product that they can use their own server URLs specific to their backends and have their custom caching, custom implementation. If they feel that, okay, this is something that is good, can be reused by other teams that project, then we ultimately merge that to the base. So this is how we experiment. So like Akhila is working on caching in Gopi team. So he'll build that, try that in the Gopi team. And if that works, we'll move that to the base so that everyone can use it. You mentioned have smaller commits. Yeah, smaller commits, yes. How do you enforce or motivate your developers towards that direction? So it's a guideline, it's a practice. One way that I can think of is make a githook as Pratul mentioned in the talk in the morning. You can make a githook that okay, the commit should not have more than this number of files or something. This is how you can automate it. Otherwise, this is just a practice that we have asked everyone to follow. So let's say, how we do current is, we are doing it in the manual way. Once you complete that feature, you send the PR. The first thing I'll check, okay, how big is the PR is? If it is too big, I'll say please break it into small PRs so that it is easier for me to review. And if there is any bug or some breaking changes, then I can narrow down, okay. This is the small piece of course that is causing the change. So currently we are doing it in the manual way, but yeah, we can use githooks for that. It's like the app developers that you have. Are your backends as well broken, the exact same product? Yes, we have more than 200 microservices running at one point of time. It's all of your product that was just talked to their own most of the time. Yes. The case like the base is where you get to share. Yeah, base is where you get to share. The common network part, the shared platform part. And if there is something that you want to reuse from other modules, just move it to... What about, you know, something like the microservices are on Docker or something? Have you orchestrated all those 200 services rather? In the backend? No. Currently we are migrating to, so we are in process of migrating everything to Docker, but we haven't yet started that for production. So only one of the posts microservice is on Docker, completely on Docker. So we are still in process of migrating.