Hola, I’m Hieu, a Software Engineer

The bad version of environment handling looks like this: const bool isProd = false ; final apiBase = isProd ? 'https://api.example.com' : 'https://staging.api.example.com' ; It works until someone ships with the flag flipped the wrong way, or until QA needs staging and production installed side by side and discovers both have the same bundle id. Flavors fix both problems at the build layer: three separate installable apps, each compiled with its own configuration baked in. The Dart side, first Start here because it is the part that determines everything else. // lib/config/app_config.dart enum Flavor { dev, staging, prod } final class AppConfig { const AppConfig ._({ required this .flavor, required this .apiBase, required this .appName, }); final Flavor flavor; final String apiBase; final String appName; static const _flavorName = String . fromEnvironment ( 'FLAVOR' , defaul...

Every Flutter repository eventually grows a .github/workflows/ci.yml containing flutter test . It passes, everyone feels covered, and then a release build fails on the build machine for a reason nobody’s laptop could have surfaced. CI earns its keep by catching the failures that local development structurally cannot: stale generated code, a dependency that only resolves because of your local pub cache, a formatting change nobody ran, a golden that drifted. This is a pipeline built around those. The shape of it Four jobs, in two waves: Job Runs Catches analyze every push and PR format drift, lint regressions, unused code test every push and PR unit, widget, and golden failures build PRs to main and tags compile failures that only occur on a clean machine release tags only signing, artifact upload analyze and test run in parallel and are fast. build is slow and gated. That split matters: a pipeline where every push waits eight minutes for an Android...