Android - Development Workflow
This guide provides a comprehensive overview of the development and release workflow for Q2 Mobile SDK modules on Android. It walks through each step from initial development to production release, explaining what partners/FIs do and what Q2 handles in the process.
Workflow Overview
The following diagram illustrates the complete development and release workflow:
Detailed Workflow Steps
1. Local Development Phase
During this phase, you develop and test your module locally before submitting for Q2 review.
Key Activities:
- Create a feature branch from
master - Develop your module using the DevApp tool
- Test locally - Verify all functionality works in DevApp
- Test with obfuscation - Enable minify and test with R8/ProGuard (critical!)
- Commit and push your changes
Before submitting your merge request, you must test your module with R8/ProGuard obfuscation enabled. Without proper testing and consumer rules, your module will crash in production builds.
See Consumer ProGuard Rules for complete testing instructions.
For complete local development guidance:
See Local Development for detailed step-by-step instructions on:
- Creating branches and development workflow
- Using DevApp for testing
- Creating and testing ProGuard consumer rules
- Handling third-party libraries
- Troubleshooting common issues
- Best practices for security, performance, and maintainability
2. Merge Request & Q2 Review
Once local development and testing are complete, you submit your code for Q2 review.
Key Activities:
- Create Merge Request - Push your branch and create an MR from your branch to
master - Submit Support Ticket - Notify Q2 through q2developer.com with:
- Link to your merge request
- Summary of changes
- Testing environment preference (Sandbox/SDX/PTE)
- Any module
data {}configuration changes
Settings.json from DevApp is not automatically copied to test/production
builds. Include any data {} changes in your ticket.
- Q2 Reviews - Q2 reviews for security, safety, and stability issues (not code quality)
- Feedback Loop - If issues are found, fix in your branch, push updates, notify Q2, repeat
- Approval & Merge - Q2 merges to
masterwhen approved
For detailed guidance:
- Submitting Support Tickets - Ticket templates, required information, and examples
- Code Review Process - What Q2 reviews and what's your responsibility
3. Test Build Phase
After Q2 approves and merges to master, the CI pipeline automatically
generates a test artifact and Q2 creates a test build for you.
What Happens (Automatic):
- CI builds your module with test configurations
- Test artifact generated and stored in package registry
- Q2 creates test build pointing to Sandbox/SDX/PTE (based on your ticket)
Your Testing:
You receive the test build and thoroughly test your module's functionality.
Even though you tested locally, the test build uses:
- Production CI/CD pipeline - Same process as production
- R8/ProGuard obfuscation - May reveal issues not caught locally
- Production-like signing - Tests the full build process
- Full app integration - Your module with the complete Q2 Mobile Application
- Real backend environment - Sandbox/SDX/PTE instead of local DevApp
Issues not seen locally often surface here.
If Issues Found:
- Fix in your feature branch → Create new MR to master → Repeat review cycle
If Testing Successful:
- Proceed to production deployment request
4. Production Release
After successful test build validation, you request production deployment and Q2 handles the release.
Key Activities:
- Submit SDK Deployment Request - Notify Q2 through q2developer.com that testing is complete
- Q2 merges to production branch:
- FIs: Q2 handles merge internally
- Partners: Submit MR from master to production, Q2 approves
- CI generates production artifact (automatic)
- Q2 creates release tag and makes module available
Result:
- Module is now available for production Q2 Mobile Applications
- Listed in Q2 developer catalog (for partners)
- Ready for inclusion in FI builds
For detailed instructions:
- Submitting Support Tickets - How to submit deployment requests
Branch Structure
The repository uses a protected branch structure:
-
masterbranch: Protected branch used for certification builds- All development merges here first
- Test artifacts are generated from this branch
- Requires Q2 approval to merge
-
productionbranch: Protected branch used for production builds- Only receives merges from
master - Production artifacts are generated from this branch
- Represents released, production-ready code
- Only receives merges from
-
Feature branches: Your development branches
- Can use any naming convention
- Created from and merged back to
master - Flexible for your team's workflow
Summary
| Phase | Who | What Happens |
|---|---|---|
| Development | Partner/FI | Create branch, develop in DevApp, test locally |
| Merge Request | Partner/FI | Create MR to master, submit support ticket |
| Code Review | Q2 | Review code, provide feedback or approve |
| Test Build | Q2 | Merge to master, CI generates test artifact, Q2 creates test build |
| Testing | Partner/FI | Test the build with obfuscation/signing/integration |
| Deployment Request | Partner/FI | Submit SDK Deployment Request |
| Production Release | Q2 | Merge to production, CI generates production artifact, create release tag |
| Done | - | Module available for production use |
Additional Resources
Workflow Guides
- Local Development - Detailed guide for day-to-day development
- Submitting Support Tickets - Detailed ticket submission guide
- Consumer ProGuard Rules - Creating and testing obfuscation rules (required)
- Third-Party Libraries - Submitting private libraries for Q2 hosting
Other Resources
- Code Review Process - What Q2 reviews and your responsibilities
- Android Publishing Overview - High-level publishing information
- DevApp Setup - Setting up the Q2DevApp tool
FAQ
Can I merge directly to production?
No, all changes must go through master first. This ensures proper testing and
review before production release.
What if I need to make changes after merging to master?
Create a new branch from master, make your changes, and submit a new merge
request to master. Once approved, a new test build will be generated.
How long does the review process take?
Review times vary based on the complexity of changes and current queue. Most reviews are completed within a few business days.
Can I test with a different environment?
Yes, specify your preferred environment (Sandbox/SDX/PTE) in your support ticket when requesting the test build.