iFood: Better Build Times for iOS and Android

iFood, has created an innovative system to help customers access takeout and delivery services in their cities. iFood allows users to easily order food from menus that are updated in real-time with accurate prices, descriptions, and exclusive promotions, all without any extra fees.

Moving to MacStadium

iFood started with bare-metal Gen 3 i7 Mac minis for iOS development and EC2 with a c5.2xlarge (8 vCPU + 16GB RAM) on AWS as their Android environment. Once all the infrastructure was in place, the team began to migrate from their previous CI environment to Jenkins. The move would allow a direct comparison between iOS and Android pipelines, even though two separate services were running them. It couldn’t have come at a better time since iFood’s development team was expanding, and so was their codebase. Now they had a scalable solution and room to grow.



"After a few weeks of real usage of the environments, we understood that we were right by moving to MacStadium," said Diogo Ribeiro Mendes, manager of QA and DevOps at iFood. "However, we didn’t have the same success on AWS. The Android builds were having mixed times and were not as constant as iOS."



With iOS builds running well, it was time for iFood to fix their Android builds. They devised a two-pronged approach: first, they created a build.gradle configuration dedicated to the CI, and then they changed their AWS instance to a c5.4xlarge (16 vCPU + 32GB RAM), doubling what they had initially.



In order to keep everything up and running, the team continued to run parallel builds for iOS and Android. Despite seeing some improvements with Android during those weeks, the team started to experience some strange daemon behaviors caused by the parallelism.



The two-pronged approach was quickly scrapped for a new, unconventional plan: move all the Android builds to Mac minis at MacStadium. This meant doubling their current MacStadium infrastructure.



We integrated our Android builds to bare metal Mac minis, and everything became stable on Android as well - thanks again to MacStadium.



"We switched our Mac mini G3 at MacStadium to the newest ones available, the Gen 4 i7 six-core with 32GB, and integrated our Android builds to those bare metal minis as well," Mendes said. "And everything became stable on Android as well - thanks again to MacStadium."



The team continued running daily pull requests and release tests in the iOS and Android environments on the minis at MacStadium. iFood noticed a tremendous build time improvement: 45% on iOS and 35% on Android. That was all they needed to feel confident about fully migrating to the new environment.

Even More Speed with Remote Caching

Since they had seen such improvement with moving to a bare-metal mini cloud at MacStadium, the team decided to leverage that and start using remote caching for both iOS and Android. iFood was able to use the newly improved Buck Cache for its iOS builds and Gradle Remote Cache for Android.



This gave the iFood teams another 50% improvement on build time in addition to the previous 40% gain they got from migrating to MacStadium.



[We experienced] a total of 75% better build time with the improvements we were able to see with MacStadium and remote caching.



"This is just an example, but we were able to bring the pull requests on iOS from 45 minutes to 10 minutes on the full pipeline," said Mendes. "Which is a total of 75% better build time, with the improvements we were able to see with MacStadium and remote caching."

Conclusion