The Challenge: One Codebase, Two Apps, Zero Sanity
Managing two distinct Android applications – one for staff, another for students and parents – from a single React Native codebase using Expo presented a unique set of challenges. The core problem was distinguishing these apps at build time, a task initially handled by environment variables. This approach, while functional, quickly exposed the fragility of the existing release pipeline. The primary goal was to transition from Expo Application Services (EAS) to GitHub Actions for both Android builds and Play Store releases. This move was driven by the exhaustion of EAS's free build tier and the impracticality of local builds, which were consuming excessive developer time and resources.
EAS Free Tier Exhaustion and Local Build Bottlenecks
The initial reliance on EAS's free tier proved unsustainable. Builds frequently failed mid-sprint due to exceeding usage limits, halting development progress. Attempting to circumvent this by building locally proved equally problematic. Developers found their machines bogged down for twenty minutes per build, a significant drain on productivity. This situation underscored the need for a more robust, scalable, and cost-effective CI/CD solution. The team's existing infrastructure on GitHub Actions, with its ample free CI minutes, presented a clear path forward. The objective was to replicate the EAS build process within GitHub Actions, ensuring seamless deployment to the Google Play Store.
Version Numbering Woes: The Ignored Counter
A critical oversight in the local build process involved a gitignored local counter used for version numbering. This counter, residing only on developer machines, failed to persist across fresh CI runner environments. Consequently, each new build on a CI server would reset the version number, leading to a cascade of release errors and the inability to properly track app versions. This mistake highlights the importance of version control and persistent state management in automated build systems. Without a reliable, version-controlled mechanism for incrementing build numbers, the team faced constant deployment failures and confusion.
The Deceptive Google Play Error Message
The journey to a stable release pipeline was further complicated by a misleading error message from the Google Play Console. The console actively provided incorrect information regarding the root cause of a build failure. This actively lying error message, as described by the developers, wasted significant debugging time. Instead of pointing to the actual issue, it led the team down rabbit holes of unrelated potential problems. This experience is a stark reminder that even the most sophisticated platforms can present misleading diagnostic information, requiring a deep understanding of the underlying systems and a willingness to question the provided error codes.
Transitioning to GitHub Actions: A New Pipeline
The migration to GitHub Actions involved setting up a comprehensive CI/CD pipeline. This required configuring workflows to handle the build process for both the staff and student/parent apps. Key considerations included managing environment variables, ensuring correct app signing, and automating the submission of builds to the Google Play Store. The goal was to create a system that was not only reliable but also efficient, minimizing manual intervention and build times. This transition involved scripting the build process, integrating with the Android SDK, and configuring authentication for Play Store uploads.
Automating Multi-App Builds
Distinguishing between the staff and student/parent apps within the GitHub Actions workflow was paramount. This was achieved by leveraging environment variables set within the CI/CD configuration. The workflow was designed to conditionally apply specific configurations or build flags based on these variables. For instance, different app icons, package names, or API endpoints could be targeted for each app variant. This ensures that the correct application is built and configured for its intended audience and deployment target. The process involved careful scripting to ensure that build artifacts were correctly named and organized for subsequent deployment.
The Value of a True CI/CD System
This experience ultimately underscored the immense value of a well-implemented CI/CD system. Moving away from manual APK generation and relying on a robust automation pipeline like GitHub Actions significantly improved efficiency and reduced errors. The ability to manage complex build configurations, handle versioning reliably, and automate deployments directly to the Play Store freed up developer resources and accelerated release cycles. The lessons learned, particularly around debugging deceptive error messages and managing versioning in an automated environment, are invaluable for any team managing multiple app variants from a single codebase.
Future Considerations: Expansion and Optimization
While the immediate goal was to stabilize the Android release pipeline, the team recognizes the need for ongoing optimization. This includes exploring more advanced CI/CD strategies, potentially incorporating automated testing frameworks, and further streamlining the build and deployment process. As the applications evolve and user bases grow, the need for a highly efficient and reliable release mechanism will only increase. The transition to GitHub Actions provides a solid foundation for future development and scaling.