PeaceLingo · engineering

From a code change to the App Store, automatically checked at every step

Every fix or feature goes through the same pipeline. Tests run on every pull request, deploys roll back by themselves if the new version is unhealthy, and nothing counts as shipped until the live product passes the checks a user would.

Automatic gate: stops the pipeline on failure Human approval What happens on failure

1Change

Isolated branchEach fix or feature is built on its own branch, never on the shipped code.
Typed commitsfix: and feat: messages drive the version number and the changelog later.
Local preflightBackend tests, secret scan, a production-mode server smoke test, iOS and web builds, before anything is pushed.

2Pull request checksevery PR · in parallel

BackendUnit and API tests: sign-in, purchase verification with forged-certificate cases, usage limits, cost guard.86 tests
Security scansSecret scan of the full history, static code analysis (CodeQL), and known-vulnerability audits of every shipped dependency.
WebType check, unit tests, production build.
MobileiPhone Debug and Release builds; Android phone and Wear OS unit tests and builds.
Any red check blocks the merge.

3Deploymerge to main

API serverContainer image built from hash-locked packages, tagged with the commit → deployed to the EU server over a pinned, key-only connection → health check.
Unhealthy → automatic rollback to the previous image.
Web appThe release build refuses to run without the production API address and sign-in configuration → global CDN.
WebsiteStatic pages → global CDN, strict security headers.

4Verify liveafter every deploy

Security smoke testSign-in required, developer shortcuts off, forged tokens refused, admin routes closed.
User-eye checksEvery page and link loads; no developer or template text on screen; the app points at production; the sign-in provider accepts the app's ID; the browser may reach the API.
A failure marks the deploy as not done, and it is fixed before anything else ships.

5Release appsversion tags

Version + changelogA release PR is opened from the typed commits; merging it tags each app.
Approve releaseA person approves before signing keys are used.
iPhone → TestFlightArchived, signed and uploaded for beta testers.
Android + Wear OS → Play testingSigned bundles to the phone and watch test tracks.
Store review → phased rolloutiPhone over 7 days; Android 5% → 20% → 50% → 100%, paused if problems appear.

Security built into the pipeline

Each protection is enforced by the pipeline itself, so it holds on a busy day too.

No keys in code or appsSecret scanning on every push; API keys live only on the server, never in an app someone could take apart.
Locked supply chainBuild steps pinned to exact commits, server packages locked by hash, base image pinned by digest. A hijacked release of a tool can't slip in.
Known flaws caught earlyDependency audits and static analysis on every change; weekly automated update PRs that must pass the same pipeline.
Encrypted, approved secretsCI jobs get a read-only token by default; deploy credentials unlock only for approved production or release jobs.
Least privilegeThe app runs as an unprivileged user; the deploy account has no admin rights; servers accept key logins only, from a verified host identity.
Production refuses shortcutsThe server will not start if any developer-only switch is on.
Verified purchasesEvery App Store and Google Play purchase is checked with the store's signatures before it unlocks anything.
Hardened edgesStrict Content-Security-Policy on every page, HTTPS enforced with automatic certificates, and no server version exposed.
Weekly quality runEvery Monday the summary quality is scored on test meetings: facts kept, owners named. A drop is caught before users notice.
Cost guardFree trials have a monthly budget enforced by the server, so growth can't run up an unplanned bill.

Pipeline defined as code in GitHub Actions, with the same steps in local release scripts. Hosting: API on an EU server, web app and website on a global CDN.