Chapter 5 already introduced the four-step deploy sequence. Now that we've actually deployed a few times, building the team page (block 5) and working through the practical topics (block 6), it's worth taking a closer look at why each individual step is necessary - not just that it is.

The four steps again, with reasons

# 1. Rebuild CSS
bin/npm --prefix app/design/frontend/Mironsoft/default/web/tailwind run build

# 2. Delete static files (IMPORTANT: always first!)
cd src && rm -rf var/view_preprocessed/* pub/static/frontend/*

# 3. Deploy static content
bin/magento setup:static-content:deploy de_DE -t Mironsoft/default -f

# 4. Flush cache
bin/magento cache:flush

1. Build CSS - produces the current, minified styles.css from every Tailwind class used in the project. Without this step, step 3 would deploy a stale CSS file.
2. Delete static files - Magento caches processed view files in var/view_preprocessed/ and shipped assets in pub/static/frontend/. If old versions linger there, setup:static-content:deploy may end up serving from the cache instead of the fresh source files.
3. Deploy static content - copies/compiles all frontend assets (CSS, images, template pre-processing) from module/theme source directories into pub/static/, where they're actually served from.
4. Flush cache - Magento's internal caches (layout, block HTML, configuration) can hold old references to now-outdated static content files, and so must be cleared last.

Why exactly this order - not a different one

If step 2 (delete) ran after step 3 (deploy), the freshly deployed files would get deleted right along with it - the result would be a page with no styling at all. If step 2 were skipped entirely, setup:static-content:deploy might (depending on internal caching behavior) not redeploy all changed files, because some are still marked "current" in the preprocessed cache, even though the source code changed.

Developer workflow vs. the full deploy sequence

During local development with the watcher running (bin/start, see chapter 5), a simple bin/cache-clean is usually enough to see changes - the view_preprocessed cache plays a smaller role in developer mode. The full, four-step sequence with a production build is mandatory above all for every deployment to an environment running production or default mode.

A quick deploy check after every deployment

1. Open the browser console (F12) - any 404 errors for CSS/JS files?
2. Hard reload (Ctrl/Cmd + Shift + R) to rule out browser caching.
3. Visually check a recently changed Tailwind class specifically.
4. For Hyvä CSP themes: check the console for CSP violation messages (chapter 28).