Dev Team Release Workflow

How should your team get code from a laptop into production? There's no single right answer — it depends on your team size, your risk tolerance, and whether anyone's going to audit you later. The good news: with Tapitalee you can start simple and layer on process as you grow, without rebuilding anything. This post walks through four levels of release workflow, from a one-command deploy to a fully gated, audited pipeline.

If you're a CTO or engineering manager weighing this up, think of it as a menu rather than a prescription:

• Level 1: one-command deploys from a laptop
• Level 2: deploys from your CI pipeline
• Level 3: preview environments for every pull request
• Level 4: approval gates and audit trails

Most teams end up somewhere in the middle.

Level 1: The simplest thing that works

For a small team or an early-stage product, the workflow can be exactly one step: a developer runs a single deploy command from their terminal. Tapitalee builds the code (common stacks like Ruby, Node.js, Python, Go, and Elixir are detected automatically — no Dockerfile required), pushes it to your AWS account, and rolls it out with no downtime. New containers start before old ones are retired, and if the new version fails to start, the platform rolls back automatically.

Even at this level you get things that used to require real platform engineering: database migrations run automatically as pre-deploy steps before each release (and halt the deploy if they fail), every release is recorded with git tag, and rolling back to any previous version is one command.

This is a perfectly legitimate place to stay for a while. Deploying from a laptop gets a bad reputation, but the risky part was never the laptop — it was the lack of health checks, rollback, and history. Those are covered.

Level 2: Deploys from your CI pipeline

The next step most teams take is moving deploys into CI, so that the version reaching production is always one that passed the tests. Tapitalee ships prebuilt GitHub Actions for building, deploying, creating releases, and managing environments, so this is usually an afternoon of work rather than a project.

Two details matter here, and they're worth asking about whatever platform you use:

• No cloud credentials in CI. Pipelines authenticate with application-scoped, individually revocable tokens. Your CI system never holds AWS keys, and database credentials are supplied to containers at runtime rather than baked into builds.
• Same code everywhere. Releases are pinned to a git commit hash, so the exact codebase that passed tests is what gets promoted to staging and then production — no drift between what you tested and what you shipped.

A typical shape: merge to main triggers a build, a new release (e.g. v123) is created, and staging deploys automatically. Production is then promoted from the same release, either automatically or on demand.

Level 3: Preview environments for every pull request

This is the feature teams tend to fall in love with. Every pull request automatically gets its own complete running environment with its own URL — its own configuration, and either its own database or a shared staging one, your choice. Reviewers click a link and see the change running, designers and product managers can review without any tooling, and "works on my machine" stops being a conversation.

Preview environments are torn down automatically when the PR closes (or after a configurable lifetime), and because Tapitalee compute scales to zero and bills per second, an idle preview costs essentially nothing. Sprawl and surprise bills — the two classic objections — are handled by default.

Things to think about: do your previews need isolated databases (better for testing migrations) or a shared one (cheaper, faster to spin up, more realistic data)? Tapitalee supports both, and you can mix approaches per application.

Level 4: Approval gates and audit trails

As you grow — or as SOC 2, ISO 27001, or an enterprise customer's security review enters the picture — you'll want more formal control over what reaches production and a record of it. This is where change-management controls stop being paperwork and start being platform features:

• Release approvals: a production build is created but held until an authorised person explicitly approves it. Both the deployer and approver are recorded — exactly the evidence an auditor asks for.
• Release registry: every build linked to its source commit, version tag, diff, and release notes (which can be imported straight from your changelog).
• Deployment history: a full, queryable record of who deployed what, when, and with whose approval.
• Role-based access: who can deploy, who can approve, who can view secrets, and who can only read — defined per role, or per application on Enterprise plans.

A question worth asking your team: who should be able to approve a production release, and is that currently enforced by anything stronger than convention? If the honest answer is "anyone with the AWS console password", a gate is a cheap fix.

What it's like for a developer, day-to-day

One of the quieter benefits of this setup is what your developers don't need: AWS credentials. Most of the team never touches the AWS console at all. A developer's day looks like this:

• Write code, open a PR — a preview environment appears with a link to share.
• Merge — staging updates itself; production waits for promotion or approval.
• Check logs — live log streaming and metrics from one CLI or the dashboard, no cloud console login.
• Run a migration or console — one-off tasks and interactive consoles run in fresh containers inside the app's network, launched from the CLI or even the browser. No production credentials on any laptop.
• Something's wrong? — roll back to the previous release with one command, then investigate calmly.

For managers, the same design means offboarding is one action: remove a user and all their deploy, console, and cloud access is gone instantly — no credential rotation, no hunting for shared keys.

Choosing your starting point

Some honest guidance on where to begin:

• 1–3 developers, pre-launch: command-line deploys are fine. Add CI deploys when the second person starts stepping on the first.
• Small team shipping to real users: CI deploys plus preview environments. This combination alone puts you ahead of most teams.
• Growing team, availability expectations: add automatic staging deploys and promote-to-production from the same git commit.
• Compliance on the horizon: turn on approval gates, roles, and MFA enforcement. The audit trail has been accumulating the whole time — you're formalising, not rebuilding.

The important thing is that these are configuration choices, not architectural ones. The team that starts at level 1 and the team running gated releases are on the same platform, in their own AWS account, with the same deploy command.

If you'd like to see a canonical example of the full workflow wired up with GitHub Actions, have a look at our reference demo application: github.com/tapitalee/bigdemo. Or read how one team put all of this into practice in our Heroku to AWS case study.