ATPL

Services · Cloud and infrastructure

Make every release routine, not an event.

For teams that still deploy by hand and hold their breath. We set up Git workflows, staging servers and pipelines that test and release your code the same way every time.

16
Years building technology
200+
Projects delivered
Talk pipelinesSee engineering work

Same path every time

Git, staging and the same path every time

Test, release and roll back without a hero at midnight.

  • Staging and live over SSH and Git

    Separate environments deployed from branches with SSH-key access, the set-up ATPL uses for its own client builds.

  • CI/CD pipelines

    Automated tests, builds and deployments on every push, with a rollback step that is tested, not assumed.

  • Environment configuration

    Secrets, environment variables and infrastructure settings kept out of the code and documented, so a new server can be rebuilt from a script.

  • Release notes and visibility

    Every deploy logged with what changed and who approved it, so a problem can be traced to a release in minutes.

Primary deliverable

Ships with the engagement

Live brief

01 · Lead outcome

Git workflow and branch rules

A branching model your team can follow, protected main branches and reviews, so work merges on purpose.

  • 01Staging and live over SSH and Git
  • 02CI/CD pipelines
  • 03Environment configuration
  • 04Release notes and visibility

How it ships

Map the current release

We watch how code gets to production today, then replace the fragile steps.

  1. pipe/01

    Understand

    We watch one real release from start to finish and write down every manual step and every place it could go wrong.

  2. pipe/02

    Design

    The pipeline is designed around your stack and hosting, with the number of environments you need and no more.

  3. pipe/03

    Build

    The pipeline runs in parallel with the old process for a few releases, until the team trusts it enough to switch off the manual steps.

  4. pipe/04

    Stay

    Pipelines rot as dependencies change; under support we keep the runners, images and tests current.

Release risk

Still deploying by hand

If release day means holding your breath, the pipeline is the product.

Talk pipelines

  • Friday

    Deploying means one developer copying files on a Friday evening and hoping.

  • Staging

    There is no staging server, so customers are the test environment.

  • Overwrite

    Two developers overwrite each other’s work because there is no branching discipline.

In production

ATPL sets up staging and live servers, Git-based deploys and CI/CD for the systems it builds, as listed on its current site; this page is written as method until a client pipeline can be named.

    Decide the shape

    CI/CD without theatre

    What it costs, what we automate first, and what stays manual on purpose.

    CI/CD is the practice of automatically testing and releasing code every time a developer pushes a change, so releases are small, frequent and the same every time. ATPL sets this up with Git, a staging server and a pipeline that deploys to live after the tests pass.

    You need the basics: a staging server, Git-based deploys and a backup you have restored. A two-person team does not need Kubernetes, and ATPL will say so; the aim is a release that takes minutes and can be rolled back, not a platform.

    A pipeline for a single application on ATPL’s usual stacks is typically a one to two week engagement, including staging, tests and rollback; multi-service systems are quoted after a short review of the repository and hosting.

    Yes. ATPL’s client builds release to a staging environment every week that the client can use, and the same Git and SSH set-up ships code to live; this page offers that process to teams whose software ATPL did not build.

    Chosen for the job

    Node.js · Python · Laravel · PHP

    Continue to