1. Abstract
Merging code that hasn’t been fully tested is one of the biggest reasons teams experience missed release dates and flaky test suites. Why? Merging code often means other developers start their new work based on the newly merged code, changes are queued up for the next release, and the code quickly becomes coupled to other changes. The result is often code freezes, failing test runs, late-night release “parties,” and painful go/no-go meetings where you get pinned between postponing the release or shipping with bugs. This problem is compounding as teams adopt AI-generated code — code that can look correct but hasn’t been validated end-to-end in a real environment.
Deploying to and testing ephemeral environments gives your team the ability to know for certain that new features are implemented correctly before committing those features to the release and before other developers start depending on the new code. An ephemeral environment is a short-lived, on-demand deployment spun up automatically for a feature branch and torn down when the branch is merged or closed. This approach isn’t just a nice-to-have; it is becoming an essential practice for any team that wants to ship with confidence.
This is a concepts-first workshop. Rather than locking attendees into a specific tool chain, we focus on the underlying patterns and principles that make ephemeral environment workflows effective — patterns you can apply regardless of your current CI/CD setup, hosting provider, or testing framework. That said, we do not stay purely theoretical. Throughout the workshop we walk through a complete, working reference implementation built on GitHub Actions for pipeline automation, Octopus Deploy for deployment orchestration, and Testery for test execution and management — a real application that provisions an environment per pull request and tears it down on merge.

2. Agenda
The workshop is delivered as seven modules. Timings below assume a 09:30 start and follow the break schedule provided by the organizers (10:55–11:20, 13:00–14:00, 15:30–15:55); each break falls on a module boundary.

Module 1 — Introduction (09:30–10:25, 55 min)
What ephemeral environments are
• Definition: a short-lived, on-demand deployment created automatically for a feature branch and torn down when that branch is merged or closed
• The four defining characteristics: on-demand, isolated, disposable, automated
• How they differ from the environments you already have — shared staging, a QA environment, a personal dev box, a PaaS preview app
Why it matters
• Opening discussion: what does the room’s release process actually cost them today?
• The merge-then-test failure mode — merging is a commitment to release, and other developers immediately start building on your code
• Running tests after the merge means sharing broken code with the team
• Downstream symptoms: code freezes, long-lived stabilisation branches, late-night release “parties,” go/no-go meetings where the only options are slip or ship bugs
• Why trunk-based development requires testing before the merge to work at all
What you are trying to get
• Merge confidence — knowing a feature is correct before it is coupled to everything else
• A window for manual review and sign-off before functionality is committed to a release
• More representative infrastructure than a workstation, and enough capacity to run tests in parallel
• Reduced variability — eliminating “works on my machine” from the equation
• Faster, earlier feedback for the developer who still has the context loaded
Results — what good looks like
• Case study: 12,000+ tests per hour, typically fewer than five failures, no more code freezes or release parties
• The metrics worth tracking: percentage of pull requests with a green end-to-end run before merge, time-to-feedback on a pull request, change failure rate, how often the trunk is broken
• Honest accounting of the costs: infrastructure spend, provisioning time, and the engineering effort to build and maintain it

Module 2 — Branching Strategies (10:25–10:55, 30 min)
• Why the branching model determines whether ephemeral environments are even possible
• The options and what each implies: GitFlow, GitHub Flow, release branches, trunk-based development with short-lived branches
• Recommendation: short-lived branches, one pull request per change, merged within days rather than weeks
• Keeping test code in sync with feature code — same repository versus separate test repository, and the versioning problem the split creates
• Branch naming conventions, and how they flow through to environment names, subdomains, and resource tags
• What breaks with long-lived branches: drift, merge conflicts in test code, environments that live long enough to become pets
• Discussion: attendees map their team’s current model and identify the first constraint they would hit
Break — 10:55–11:20

Module 3 — Deploying Ephemeral Environments (11:20–13:00, 100 min)
What has to be true
• Infrastructure has to be provisionable automatically, with no ticket and no human in the loop
• Something has to decide when to tear it down
• DNS has to resolve to the right instance
• Configuration and secrets have to be injected per environment
• Dependencies — databases, queues, third-party services — have to be available or stubbed
The options
• Namespace-per-branch on a shared Kubernetes cluster
• Full infrastructure-as-code stack per branch (Terraform, Pulumi, CloudFormation)
• Platform-native preview environments (Vercel, Netlify, Heroku review apps, Azure deployment slots)
• Container-per-branch on a shared host, or Docker Compose for smaller stacks
• Trigger models: per-pull-request, per-branch, or on-demand by label — and why per-pull-request is usually right
Trade-offs to weigh
• Provisioning time versus fidelity to production
• Cost, and how quickly it compounds across a busy repository
• Blast radius and isolation between environments
• Operational complexity, and who ends up owning it
Making it work in practice
• Lifecycle: create on pull request open, update on every push, tear down on merge or close
• TTL sweepers for orphaned environments, because teardown will fail sometimes
• DNS: subdomain per branch, wildcard certificates, and the collision cases
• Configuration and secrets management per environment
• Cost controls: TTL, auto-sleep, per-repository quotas
• Edge cases that trip teams up: parallel branches, dependency conflicts, naming collisions, migrations that do not roll back
Worked example
• End-to-end walkthrough of a real reference application: pull request opened → branch name normalised → images built and pushed → release created in Octopus Deploy → environment registered in Testery → URL posted back to the pull request
• The matching teardown path: pull request closed → environment deleted
• How the same pattern translates to GitLab CI, Jenkins, and Azure DevOps
Lunch — 13:00–14:00

Module 4 — Test Data (14:00–14:50, 50 min)
• Why data is the hardest part of ephemeral environments, and the part most teams underestimate
The options
• Isolated database per environment
• Shared database with tenant or namespace isolation
• Snapshot and restore from a golden image
• Synthetic generation on demand
• Production clone with masking — and the compliance questions that come with it
Trade-offs and recommendations
• Provisioning time, realism, isolation, storage cost, and regulatory exposure
• Which approach fits a small team, a large monolith, a microservice estate, and a regulated environment
Managing data through code
• Schema migrations versioned in the repository and run automatically on provision
• Seed scripts versioned alongside the application, not maintained by hand
• Factories and fixtures over curated database dumps
• Idempotent seeding, so a re-deploy does not corrupt state
• Tests that create the data they need through the API rather than depending on pre-existing records
• Anti-patterns: shared mutable fixtures, hardcoded record IDs, tests that depend on execution order, manual database preparation
• Cleanup and teardown — and why per-environment isolation makes most of this problem disappear
• Exercise: attendees classify their team’s current approach and pick a realistic target state

Module 5 — Creating Automated Tests (14:50–15:30, 40 min)
• Writing tests that do not know where they are running: base URL injection, no hardcoded hosts, configuration read from the environment
• Managing environment-specific variables and secrets in the test suite
• Test isolation and independence — the prerequisite for running anything in parallel
• Handling application readiness after a fresh deploy: health checks and smoke gates instead of arbitrary sleeps
• Deterministic waits, and the flakiness patterns that come from getting this wrong
• Per-test data setup rather than reliance on global state
• Scoping the suite: what runs on every pull request versus what runs nightly
• Framework-agnostic patterns, demonstrated in Playwright, with equivalents in Cypress, Selenium, and WebdriverIO
• Demo: taking an existing test and making it environment-agnostic
Break — 15:30–15:55

Module 6 — Adding Tests to CI/CD (15:55–16:40, 45 min)
• Wiring test execution into the pipeline immediately after deploy
• Gating on a fast smoke suite before committing to the full run
• Parallel execution and sharding, to keep pull request feedback inside a useful window
• Reporting results back into the pull request — status checks, annotations, and links to failures
• Quality gates: blocking merge on failure, required checks, branch protection rules
• Handling flaky tests without disabling the gate: quarantine, retry policy, and the discipline to actually fix them
• Artifacts that make failures diagnosable — traces, videos, logs, and where to store them
• The cultural piece: getting a team to treat the gate as a feature rather than a bottleneck, and what to do when someone asks to bypass it

Module 7 — AI-Driven Development (16:40–17:15, 35 min)
• The new risk profile: AI-generated code that passes review but fails at runtime, arriving at a volume no team can manually verify
• Why an ephemeral environment is the natural verification point for AI-authored changes
• Did the AI build what I asked for? Reviewing the running feature on its own environment before merge
• Did it introduce regressions? Finding out before the code reaches anyone else
• Closing the loop: feeding test results from the ephemeral environment back to the AI so it fixes its own bugs
• Agent-driven workflows: deploy → test → report → fix → re-test, and where a human still belongs in that loop
• Adapting quality gates to the failure patterns AI-generated code actually produces
• Attendee action plan — each person names the first change they will make when they get back, followed by open Q&A

3. Objectives
By the end of this workshop, attendees will be able to:
• Explain what an ephemeral environment is, how it differs from a shared staging environment, and articulate the business case to their own team
• Choose a branching strategy that keeps test code and feature code in sync and scales past a handful of developers
• Compare the main approaches to provisioning ephemeral environments and select the one that fits their infrastructure, budget, and team size
• Automate the full environment lifecycle — create on pull request, update on push, tear down on merge — including the orphan cleanup that teams usually forget
• Select a test data strategy appropriate to their context, and manage schema, seeding, and fixtures as versioned code rather than manual setup
• Write end-to-end tests that run unmodified against dynamic, branch-specific environments and remain reliable in parallel
• Wire test execution into the pipeline and establish quality gates that block broken code without becoming a bottleneck the team routes around
• Use ephemeral environments to verify AI-generated code before it merges, and feed test results back to the AI to close the fix loop
• Adapt all of the above to their existing tooling rather than rebuilding their pipeline from scratch

4. Target audience and Prerequisites
Who this is for
• QA engineers, SDETs, and test automation engineers who own an end-to-end suite
• DevOps, platform, and release engineers responsible for CI/CD pipelines and environments
• Developers practising — or trying to practise — trunk-based development
• QA leads and engineering managers evaluating whether this approach is worth the investment
Especially valuable for teams that
• Run end-to-end tests only at release time
• Maintain a contended shared staging environment
• Live with regular code freezes
• Are adopting AI coding tools and want a verification safety net
Prerequisites
• Working familiarity with Git — branches, pull requests, merges
• General understanding of CI/CD concepts (what a pipeline is, what a build and a deploy step do)
• Some exposure to an end-to-end test framework such as Playwright, Cypress, Selenium, or WebdriverIO
No prior experience with Octopus Deploy, Testery, GitHub Actions, Kubernetes, Django, React, or infrastructure-as-code is required. This is a concepts-first session: attendees do not need to use the demonstrated tools at their own company to get value from it.

5. Technical requirements from attendees
The workshop can be followed without a laptop — all demonstrations are performed by the trainer. Attendees who wish to follow along should install the following before arriving, as downloading it on conference wi-fi may not be practical:
• Git and a GitHub account
• Docker Desktop (or Docker Engine with the Compose v2 plugin) — the reference application runs entirely in containers
• Python 3.12 and Node.js 20 or later, for running the test suites on the host
• A code editor or IDE of their choice
• Approximately 5 GB of free disk space, and TCP ports 5173, 8000, and 5432 available

Detailed setup instructions and the sample repository will be circulated to registered attendees approximately two weeks before the conference, including a one-command Docker Compose start-up and a pre-pull step so that nobody spends the first module downloading images.
Reference application
Examples are built on a purpose-built sample application — Django and Django REST Framework on Python 3.12, React 18 with Vite and TypeScript, PostgreSQL 16, tested with pytest and with Playwright plus playwright-bdd. Its pipeline uses GitHub Actions, Octopus Deploy, and Testery to create an environment per pull request and delete it on close. Cloud infrastructure and credentials for the deployment portion are provided by the trainer and demonstrated live; attendees are not required to hold Octopus Deploy, Testery, or cloud provider accounts of their own.