DevOps

Mobile delivery automation — Flutter CI/CD, on-device acceptance testing, Google Play and App Store publishing

Mit Håndværk publishes itself to two app stores — and a real phone holds the veto

Mit Håndværk is a Danish marketplace app for craft, art and design — a Flutter app on Android and iOS over a Laravel backend, with subscriptions, real-time chat and push. This case is not about the app's screens. It is about the machinery that puts a new version of it in front of users: a pipeline that takes a commit on main and, roughly ten minutes later, has published it to Google Play production — but only after the release has been installed and cold-started on a real Android device and survived it.

The same pipeline covers Apple from a Linux server that cannot build iOS at all: a release tag hands the build to a cloud macOS machine, which signs it and uploads it to TestFlight — and the tag itself cannot be pushed unless the app's subscriptions are actually approved and priced in App Store Connect.

Everything in the picture above is read off the running system: the counters come out of the pipeline's own log, and the phone panel is the screenshot the publish gate pulls off the emulator on every single release.

Mit Håndværk — Danish marketplace app for craft, art and design (mithaandvaerk.dk); Flutter on Android and iOS, Laravel backend

Maintenance automation / DevOps

The boring superpower: a weekly gate that keeps twelve sites' dependencies current

Twelve production websites on one server, each with its own Composer dependency tree, and the oldest question in hosting: are they up to date, and is it safe to make them so? The dependency-currency gate answers it weekly and automatically — it inventories every vhost, checks each dependency tree against the PHP version that site's web server actually runs, queues the semver-safe updates for approval, and reports the breaking ones instead of applying them.

GrN.dk — server fleet (12 production vhosts)