preloader

Recap: Shipyard at CypressConf 2023

We had a great time at CypressConf 2023! Natalie delivered a talk on the importance of running E2E tests before merging to staging, and we chatted about DevOps and ephemeral environments with other attendees.

/images/blog/cover-images/Shipyard-CypressConf.png
Shipyard was at CypressConf 2023

by on

And that’s a wrap: CypressConf 2023

Nearly 6,000 testing enthusiasts attended the first-ever CypressConf last Tuesday. It was a virtual event done right: insightful talks covering important topics in testing, great attendees asking great questions, and cool virtual booths!

Thanks to those of you who visited us at our virtual booth! We’ll be contacting our lucky AirPods raffle winner shortly.

As of this morning, the Cypress team has published all conference recordings, accessible from this YouTube playlist.

E2E Test Before Merge With Natalie Lunbeck

I presented my talk E2E Test Before Merge: Cypress + Shipyard which you can view below (or directly on YouTube). Check it out:


Here’s an overview of what I covered:

When are E2E tests generally run during the SDLC?

Although unit tests are run in your CI on a per-branch basis, E2E tests tend to get run against a staging environment. Even worse: the E2E suite is often run against multiple merged features at a time.

This is wildly inefficient: developers can’t see any bugs uncovered by E2E tests until waiting for a merge/deploy to staging. Once they push a commit intended to fix the bug, they have to wait again for the branch to get merged and for tests to run again. QA has to sift through bugs caught in staging and determine to which PR each bug belongs.

An obvious solution?

Running E2E tests on every branch shortens the developer feedback loop. Developers can open a PR, run the E2E suite against their feature branch, iterate and fix any bugs. After all tests pass, they can call in a peer for code review and get their PR merged.

It seems almost too obvious. What’s stopping everyone from doing this?

E2E tests must be run against a production-like environment, complete with the similar dependencies and data. Until recently, this required custom infrastructure.

Ephemeral Environments for E2E testing

Ephemeral environments are the modern solution to a persistent roadblock in automated testing. By leveraging them in your CI, you can spin them up when a PR is opened, run the E2E suite against them, and trigger a rerun on every following commit.

Ephemeral environments streamline E2E testing with a few of their base features:

  • They automatically rebuild when you make a code change, so the environment always reflects your branch’s current state
  • They can be accessed directly by stakeholders via an SSO-enabled link (just as easily as by your CI pipeline)
  • When you hit SLV timeout or merge your PR, the environment automatically spins down

Try it at home

If you have a Shipyard account and a working repo with a Cypress E2E suite, you only really need to add a few things to your existing CI workflow. Here’s how you can get this working:

  1. Create a new Shipyard application
  2. Set your Shipyard API token as a GitHub Actions secret
  3. Add the Shipyard GitHub Action and Cypress run command to your GitHub Actions CI workflow
  4. Open a PR or make a commit to trigger the CI workflow

Learn More About Ephemeral Environments

If you’re interested in how ephemeral environments work at a high level, check out our community site EphemeralEnvironments.io. PRs are always welcome!

To get started with ephemeral environments, sign up for a 30-day Shipyard free trial. You can easily leverage Shipyard’s environments in your CI with our CircleCI orb or our GitHub Action.

Try Shipyard today

Get isolated, full-stack ephemeral environments on every PR.

What is Shipyard?

Shipyard is the Ephemeral Environment Self-Service Platform.

Automated review environments on every pull request for Developers, Product, and QA teams.

Stay connected

Latest Articles