Builder's iterative improvements by leveraging multi-environments

This blog post is the first of the Inside Defer Series, opening a door into the inner workings of Defer on the technical and operating side.

The Defer Builder enables developers to get up and running with Defer with minimum code changes using background functions.

By building the projects, Defer adapts to all projects, not the other way around, saving tons of work for developers.

However, with hundreds of builds per day and continuous executions, introducing changes to the Defer Builder could be a slow and hazardous process.

For this reason, we dogfood the Defer Environments feature using the defer.demo repository as part of our Defer Builder QA process.

How we leverage environments for continuous and manual testing

The defer.demo repository is configured on Defer, where every framework subfolder is assigned to an environment:

We also leverage Environments for new features by assigning new environments to development branches, example with the qa/concurrency branch:

This gives us a defer.demo project with 20+ environments:

Defer is connected to GitHub and Slack, which gives us visibility when a new build version is breaking some specific setup or framework support:

The integration with Vercel enables us to continuously test new @defer/client versions.

Example of a notification of a failing build linked to a canary version of the Builder.

Defer environments use cases

Our dogfooding example is specific; however, the principles of leveraging environments for end-to-end QA or ongoing development work are universal.

Here are how you could leverage Defer environments to improve your development process:

Git flow environments

Most developer teams embrace the staging + production Git flow.

80% of Defer applications contain two environments that match an underlying Git flow: production and staging.

QA breaking changes and preview environments

Introducing breaking changes in background functions can lead to unanticipated execution issues (renaming issues, arguments breaking changes, workflow breaking changes).

For this reason, we recommend creating a new environment (assigned to a Git branch started from the default one, ex: main) to run a representative amount of executions on the updated background functions.

We suggest creating a new environment for each working branch or final Pull Request.

For this reason, we will soon introduce a “Preview Environments” opt-in feature.

Performance benchmarks

Like the former breaking changes scenario, the Defer environments can be leveraged to run performance benchmarks on background function optimizations.

The Defer Console showcases the average duration, information that you can leverage to do quick performance assessments: