on their machine • One member of the team has the keys to signing the app • Attend issues and make Hotfixes easier • APK is shared on slack, drive, dropbox, email or another. • Connect a QA's device to your personal computer to someone can test a version (apk or bundle) • The wrong signed app builds (third-party libs keys) • Nobody knows the features included in the release • Impossible to show premature versions • Google Play Internal test can not be used instantaneously • Firebase Distribution does not support app bundles
through early and continuous delivery of valuable software. • Visibility to all team about the development • Fix broken builds Immediately • Make it easy for anyone to get the latest version • Deliver working software frequently • A standardized way to make releases
integration code, where developers can read, guidelines, styles, tools, and resources to start to collaborate with the project. Branches • Our main branch is master • We work on feature branches and do PRs to merge them to master. • We used a release branch to prepare the Release Candidates, HotFix and finally do the Release.
different versions of the app to test different environments Builds Debug: Build Feature Integration with development rules, logging tools, and available test in a staging environment used by the development team. Preview: Build Candidate with production rules without logs tools, but available test in production environment used by the Internal team (All Team) Production: Build Production to be uploaded to Google Play Note: If you're using flavors, consider the different combinations
an automated build to detect integration errors as quickly as possible • Specify branches a. master b. "release-0.1.0" - /^release-\d+\.\d+\.\d+$/ c. "0.1.0" - /^\d+\.\d+\.\d+$/ • Keep the build fast • Try different configurations until finding the most performed to your project
a continuous build is that if the mainline build fails, it needs to be fixed right away. • Prevent merge broken PR's • Easier back to previous code versions • You're always developing on a known stable code base
to find potential vulnerabilities such as bugs and ensure conformance to coding guidelines. Keep your code healthy and maintain code quality. • Android Lint: Inspect & Validate Java, Kotlin & XML • detekt: Highly configurable analysis tool for your Kotlin projects (code smells & complexity) • ktlint: Kotlin linter based on kotlinlang.org rules and code formatter • PMD: Multi analyzer code for Java, Xml & more • FindBugs: Detects possible bugs in Java • checkstyle: Check for naming conventions, structural issues, class design for Java code
catch bugs more quickly and efficiently is to include automated tests in the build process. • Testing the business logic • Testing the integration with a server API’s • Testing User Interface • Testing Persistence Integration
whole team and company, not just the mobile developers, we need to communicate the most relevant changes included in the app. • Debug: Auto Generate release notes with last commit message • Preview: Add release notes with the most relevant changes • Production: Every ticket in JIRA linked to a merged PR should set the field “Fix Version/s:” to the next Release. This will help to generate automatically the changelog at the end of each release
production, but this does not have to be a bad thing. It’s an opportunity to learn about your system and the real world with which it interacts. Product: Ensure a product team test the requirements business logic QA: Help you gain a richer understanding of the real issues your system faces (Test automation means that you are more empowered in your role than ever.)
(Dynamic URL) to your team can test an app pointing to different URL Environments without a new release. App Builds Debug: Set a specific URL environment with a development build Preview: Set a specific URL environment with a pre-production build
update reaches only a percentage of your users, which you can increase over time. • New and existing users are eligible to receive updates from staged rollouts and are chosen at random for each new release rollout. • During a staged rollout, it's a good idea to closely monitor crash reports and user feedback. • Increase your staged rollout percentage according to the number of user installs
a system is common practice, particularly metrics that indicate app behavior as performance, memory usage, crash-free user, daily active users, analytics data, etc • Use Firebase Crashlytics is a lightweight, realtime crash reporter that helps you track, prioritize, and fix stability issues that erode your app quality. • Integrate used services to be notified as soon as possible ej. (Slack + Firebase Crashlytics ) • Verify performance and analytics data
which can help us to deliver new functionality to users rapidly but safely without a new release • Use Firebase Remote Config is a cloud service that lets you change the behavior and appearance of your app without requiring users to download an app update • Create your own platform or system to turn on/off features
implement CI/CD, start with minimum checks and validations • Try different setups in order to find the correct or fits your needs • Considerate company's resources and the size team at the moment choose a CI tool • Use kotlin DSL if you feel more comfortable to avoid Gradle files. • Keep the builds fast • Satisfy the customer through early and continuous delivery of valuable software. ¡Automate all the things!