Skip to content
CanCode DevsCanCode Devs
All work

Case study

CI/CD Across the Product Stack

In plain English

Two release tracks so web, API, mobile, and AI ship weekly instead of by hand.

Weekly release cadence with PR testing and merge-to-main deployments.

Who it is for

  • Product teams who were burning time on hand-built web, API, mobile, and AI releases.
  • Ops who need one track for VPS products and another for AWS EC2 with SQS.

Problem

Web, API, mobile, and AI products shipped without automated pipelines. Builds were manual, slow, and inconsistent across hosts.

Manual releases meant human error and developers stuck on deployment mechanics instead of features.

Solution

Some products release through GitHub Actions onto a VPS. Others release through Jenkins onto AWS EC2 with SQS.

Those pipelines build Python, Next.js, NestJS, Flutter, and AI services. S3 holds artifacts and assets when a product needs object storage. Flutter Android signing is one Actions-side example: keystore from secrets, channel version, monotonic versionCode.

Outcomes

Weekly release cadence with PR testing and merge-to-main deployments.

New projects onboard onto the track that matches their host, without inventing a new pipeline.

GitHub ActionsJenkinsPythonNext.jsNestJSFlutterAWS S3AWS EC2SQSVPSDocker

How it works

Checks, then a build of Python, Next, Nest, Flutter, or AI. Release splits: GitHub Actions to a VPS, or Jenkins to EC2 with SQS.
Checks, then a build of Python, Next, Nest, Flutter, or AI. Release splits: GitHub Actions to a VPS, or Jenkins to EC2 with SQS.

From PR to a weekly release

Failed checks block the ship. A passing job deploys to a VPS or to EC2 with SQS, then notifies the team.
Failed checks block the ship. A passing job deploys to a VPS or to EC2 with SQS, then notifies the team.

What we built

GitHub Actions to VPS

  • PR checks

    Lint, unit tests, and frontend build before merge.

  • VPS deploy

    Build, then ship the release onto the VPS.

  • Slack notify

    Status with version and commit range.

  • Flutter Android

    Repeatable SDK, secret keystore, channel version name, internal-track artifact.

Jenkins to EC2 + SQS

  • Job checks

    Tests must pass before Jenkins ships a build.

  • EC2 deploy

    Jenkins ships the release onto AWS EC2.

  • SQS

    Part of the AWS host setup for those products.

  • Promote

    A green job is what ships, not a hand-built package.

What those pipelines build

  • Python and AI

    Services and model jobs go through the same check-then-deploy discipline.

  • Next.js and NestJS

    Web apps and APIs build in CI, then land on the host that product already uses.

  • Flutter

    Mobile releases are one of the stacks, not the only pipeline.

  • S3

    Artifacts and assets when a product needs object storage.

How it works

This is not one runner. Some products use GitHub Actions to a VPS. Others use Jenkins to AWS EC2 with SQS.

Success looks like a green check on the track that product already uses. Flutter internal tracks are not store production by default.

Integrations

  • GitHub Actions

    PR checks and VPS deploys for some products.

  • Jenkins

    Build and deploy to AWS EC2 with SQS for other products.

  • AWS S3

    Artifacts and assets when a product needs object storage.

  • VPS and EC2

    Host chosen per product, not a single shared box.

Have a similar challenge?

Start a project