What does the build & deploy process look like?

Headless Shopify storefronts are fundamentally different (from "standard" Shopify) in how they work, how they're hosted, and how they're updated.

Firstly, "build" can relate to two things:

The actual development process ("building" the headless solution)
A process that usually runs in a Node.js environment, where a headless store is "built" (the code is compiled, any static routes are pre-rendered, and the Javascript is bundled). This "build process" usually occurs via a continuous integration/delivery pipeline and is then deployed somewhere on the web (a CDN, cloud platform), etc.

This article relates to the latter.

With regular Shopify, your store is kind of just "there", and updates are made by changing content in the Shopify backend, updating your theme files, installing apps, etc. You see your updates instantaneously, as everything is connected and "all-in-one".

With headless, your decoupled frontend will be responsible for sourcing data from Shopify (and potentially various other sources like a CMS), pre-rendering any static pages, compiling all the code, and returning a bundle which is then deployed (pushed out) to a platform so that it can be served to end users. How the solution is architected is completely dependent on the particular project, and no two headless implementations will be the same. Some implementations are heavily static, pre-rendering the majority (or all) front-facing pages, and only requesting small amounts of data in real-time (such as stock levels, account details, etc). Others might use a pretty "live" approach, where the decoupled frontend "pings" the backend(s) (sources data from Shopify, a CMS, and/or other apps via API requests) more frequently.

Those requests could be made on each page load, though that might not be the most efficient use of resources. There are alternative implementation approaches, such as hybrid rendering and Incremental Static Regeneration, which allow the build to serve pre-rendered pages and request updated data in the background. This kind of approach works well to ensure consistent response times, and can reduce the amount of wastage in API calls.

Therefore, depending on how the headless storefront has been architected, the "build & deploy" process, its frequency, and how involved you are with it could look fairly different depending on the project's approach!

For instance: With a primarily static storefront (see Shopify static site generation), the storefront will need to be rebuilt on each change to the content. That's to say that the codebase will re-fetch any changed data, pre-render the pages that've changed since the previous build, and then compile and bundle the code.

Subsequently, this will be deployed automatically to a CDN or cloud platform through a CI/CD pipeline (some well-known movers in this space are Vercel & Netlify for fully-managed cloud platforms, CircleCI and Jenkins for CI/CD alone, and Cloudflare as a CDN). Which combination of tools and platforms your build uses heavily depends on the type of technology used for the storefront itself and how it's been implemented (the tools chosen for a static site will be different from one that uses incremental static regeneration, for example).

In contrast to a static headless Shopify storefront, one that relies heavily on server-side rendering at client request time (essentially, pages are generated for the user upon request, rather than ahead of time) will not require rebuilding anywhere near as often. With this setup, you'll likely only need to rebuild the site on changes to the codebase, as pages aren't generated statically, and users always see the most fresh, up-to-date content.