Delivery

CI/CD Pipeline Development

Releases are automated and repeatable from day one, not a bolt-on at the end.

Clay illustration of CI/CD pipelines
CI/CD Pipeline Development featured graphic

How it works

A left-to-right map of the work. Ports stay on fixed sides so the edges do not cross more than they have to. Pan or pinch if you want a closer look.

The usual problem

  • Store builds live on one person’s machine, so a holiday blocks a release.
  • Signing, flavors, and store metadata drift between Android and iOS.
  • A broken architecture rule can still ship if CI never sees it.

How I approach it

  • Every pull request runs the same pipeline the release will run.
  • The client keeps store accounts and secrets. I never take them.
  • Lint is a gate, not a suggestion.
  • Android and iOS are first-class. One platform is not “later”.

Process

  1. 01

    Branch and PR

    GitHub Actions on every pull request.

  2. 02

    Quality gate

    The custom Flutter lint package fails the PR when architecture rules break.

  3. 03

    Signed builds

    Gradle and Fastlane produce store-ready artifacts.

  4. 04

    Publish

    Upload to App Store Connect and Play Console.

  5. 05

    Handover

    Workflow files, lanes, a secrets setup doc, and a release checklist.

Stack and tools

GitHub ActionsFastlaneGradleApp Store ConnectPlay ConsoleCustom Flutter lint

Proof from real work

Kadipay and MDBriefcase

Production Flutter delivery

Release pipelines with store publishing and a lint gate in CI, treated as part of delivery rather than a late add-on.

Open the case study

What you get

  • Workflow files
  • Fastlane lanes
  • A secrets setup doc
  • A release checklist

How risk stays down

  • No “works on my machine” releases.
  • The client keeps the store accounts and secrets.
  • The same lint that reviews the PR also gates the pipeline.

Questions agencies ask