Messagenius
Multi-platform release engineering
Senior Flutter Engineer · 2022 — present
The same Flutter codebase ships to enterprise customers with different branding, feature sets and authentication requirements. Do that carelessly and the code fills up with if (customer == ...) checks until you can’t tell what any given build contains.
I own the release engineering that keeps that from happening: multi-flavor builds (dev, prod, and named customer flavors) driven from a shared Makefile system, iOS code signing across all of them, and remote configuration for per-customer server lists and feature flags. When a customer moves their server, they change a config value instead of waiting on app-store review.
I also integrated Azure AD authentication for the enterprise customers who require it before they’ll deploy. Sign-in is the first thing their users touch, so that integration gets no soft launch.
Highlights
- Multi-flavor builds (dev, prod, and named customer flavors) from a single shared codebase
- Own iOS code signing and the release pipeline across every flavor
- Remote configuration for per-customer server lists and feature flags, changeable without a store submission
- Integrated Azure AD authentication for enterprise customers who require it to deploy