...and since branch deploys all have the same performance characteristics of your production branch, you can even use branches as the source of different user experiences in A/B or multi-variant testing.
https://url.netlify.com/S18l3LDVu

If you have a custom domain, you can use your branch name as a subdomain
https://url.netlify.com/HkmY9UPNO
https://url.netlify.com/HkmY9UPNO

💥 Kapow!
Now you have multiple environments, each with their own CI/CD workflow based on git.
And you can do this as many times as you like. Unlimited instant environments FTW! 🎉
Now you have multiple environments, each with their own CI/CD workflow based on git.
And you can do this as many times as you like. Unlimited instant environments FTW! 🎉

Branch Deploys are how @Netlify delivers multiple environments.
For example, to create a staging environment, you create a branch called "staging" and push it to your repo. Netlify runs your build just like normal, but deploys it to a URL called "http://staging--yoursite.netlify.app"
For example, to create a staging environment, you create a branch called "staging" and push it to your repo. Netlify runs your build just like normal, but deploys it to a URL called "http://staging--yoursite.netlify.app"

...and away goes the headache of synchronising all of the software, patches and configuration of servers before getting to work on the code and content.
(which is where, as designers and developers, we do our real work!)
(which is where, as designers and developers, we do our real work!)

..."production" and "staging" environments can be on identical, globally distributed infrastructure, each with their own URL and workflow.
Gone are the days of pricing up servers and resources to host each environment for a site.
Gone are the days of pricing up servers and resources to host each environment for a site.

...this opens the door to automating the provisioning of environments.
Instead of creating "new" environments, we can deploy sandboxed instances to the same big network of infra to be operated by experts in that field.
Those experts don't need expertise in "our" special sauce.
Instead of creating "new" environments, we can deploy sandboxed instances to the same big network of infra to be operated by experts in that field.
Those experts don't need expertise in "our" special sauce.

...and what are atomic deploys?
https://jamstack.org/glossary/atomic/
https://jamstack.org/glossary/atomic/

...also this allows the hosting strategies of the sites to be normalised. The important practices and workflows for hosting such things can be common, like CDN hosting, edge caching, cache-management, atomic deploys.
What is a CDN?
https://jamstack.org/glossary/cdn/
What is a CDN?
https://jamstack.org/glossary/cdn/

A Jamstack approach decouples the front-end from the back-end and from the infrastructure.
It is no longer confined to being the output of a back-end system. (A win for those with skills in front-end engineering who can now work outside of the constraints of the back-end.)
It is no longer confined to being the output of a back-end system. (A win for those with skills in front-end engineering who can now work outside of the constraints of the back-end.)

This is one reason I embraced a hosting model with immutable deploys instead of a constant iterative mutation of environments, their config, and their code.
What is an immutable deploy?
https://jamstack.org/glossary/immutable/
What is an immutable deploy?
https://jamstack.org/glossary/immutable/

I wonder, have you ever:
- Made a project plan for a deploy/release?
- Had a long code/content freeze during a deploy?
- Costed a "deploy team"?
- Been on call or worked nights for a deploy or env migration?
(😬 Past Phil is nodding at me. I'm trying not to make eye contact!)
- Made a project plan for a deploy/release?
- Had a long code/content freeze during a deploy?
- Costed a "deploy team"?
- Been on call or worked nights for a deploy or env migration?
(😬 Past Phil is nodding at me. I'm trying not to make eye contact!)

...most of my life leading projects had me losing sleep over these things. With only stress and no actual confidence gained from having multiple environments because they were so hard to reason about.

Traditionally, the hardest things about creating multiple envs are:
1. Expense and time of provisioning multiple sets of servers.
2. Overhead of making each env a faithful replication of prod
3. Keeping the env configs the same over time
4. Keeping code and content consistent
1. Expense and time of provisioning multiple sets of servers.
2. Overhead of making each env a faithful replication of prod
3. Keeping the env configs the same over time
4. Keeping code and content consistent

Every big project I've ever worked on has needed multiple environments.
Always:
- Production
- Development
Usually:
- Staging
- Quality Assurance
- Testing
We wished:
- Feature/our-next-cool-feature
Once:
- Prod-backup-because-prod-is-wobbly
(🥺 please don't ask)
Always:
- Production
- Development
Usually:
- Staging
- Quality Assurance
- Testing
We wished:
- Feature/our-next-cool-feature
Once:
- Prod-backup-because-prod-is-wobbly
(🥺 please don't ask)

Phil Hawksworth
@philhawksworth •
Thinking about this favourite feature of @Netlify, and a workflow which a Jamstack approach enables.
🧵 Branch deploys ... https://twitter.com/Netlify/status/1374074796296843268
🧵 Branch deploys ... https://twitter.com/Netlify/status/1374074796296843268

Phil Hawksworth
@philhawksworth •

@sarah_edo @Netlify Honestly, I thought I had peaked with the choice of emoji on this: https://twitter.com/Netlify/status/1374074790429007885

@sarah_edo @Netlify I’m not saying that tweet was my single greatest professional achievement.
But others might.
But others might.

@sarah_edo Pokerfaces

@Tzmanics @sarah_edo #Perfection

@justinjunodev @sarah_edo @jlengstorf Conversely, I'm all about the boops.
I feel I might learn a lot under his boopelage
I feel I might learn a lot under his boopelage