The Deployment Sequence for a Module This Large

The deploy sequence from CLAUDE.md - build CSS, delete view_preprocessed/pub/static, deploy static content, flush the cache - is enough for a normal frontend update. Mironsoft_Loyalty brings twelve data patches, a new cache type, its own cron group, a new configuration type, and admin Knockout components with it - enough extra moving parts to extend the standard sequence by three upstream steps and one downstream step.

The extended sequence

# 1. Maintenance mode (recommended for a schema change this large)
bin/magento maintenance:enable

# 2. Apply database schema and data patches
bin/magento setup:upgrade

# 3. DI compile - REQUIRED because of new preferences, virtual types, and the configuration type
bin/magento setup:di:compile

# 4. Rebuild CSS (new templates from blocks 6/7/8/9)
bin/npm --prefix app/design/frontend/Mironsoft/default/web/tailwind run build

# 5. Delete static files (IMPORTANT: always first, before deploying)
cd src && rm -rf var/view_preprocessed/* pub/static/frontend/* pub/static/adminhtml/*

# 6. Deploy static content (storefront AND admin - block 7 ships admin JS too)
bin/magento setup:static-content:deploy de_DE en_US -t Mironsoft/default -f
bin/magento setup:static-content:deploy de_DE en_US --area adminhtml -f

# 7. Flush the full cache (includes the custom mironsoft_loyalty_catalog type)
bin/magento cache:flush

# 8. Verify cron activation
bin/magento cron:run
bin/mysql -e "SELECT job_code, status, scheduled_at FROM cron_schedule WHERE job_code = 'mironsoft_loyalty_expire_points' ORDER BY schedule_id DESC LIMIT 5;"

# 9. Disable maintenance mode again
bin/magento maintenance:disable

Step 2: the twelve data patches in dependency order

setup:upgrade doesn't run data patches in file or chapter order, but in the topological order computed from getDependencies(). Twelve patches accumulated across the series - here's their actual execution graph:

Execution graph of all twelve data patches (roots run in parallel, children only after their parent)

InstallRewardEntityType                          (chapter 11, no dependency)
  `-- InstallRewardAttributes                    (chapter 13)

InstallProductLoyaltyAttribute                   (chapter 19, no dependency)
  `-- UpdateProductLoyaltyAttributeScope          (chapter 25)

InstallCategoryLoyaltyAttribute                  (chapter 20, no dependency)

InstallCustomerLoyaltyAttributes                 (chapter 21, no dependency)
  `-- UpdateCustomerLoyaltyTierBackend            (chapter 26)

InstallSalesLoyaltyAttributes                    (chapter 23, no dependency)
  |-- InstallSalesLoyaltyRedeemedAttribute        (chapter 63)
  `-- InstallSalesLoyaltyPointsPackageCreditedAttribute (chapter 76)

InstallPointsPackageAttributeSet                 (chapter 74, no dependency)
  `-- InstallPointsPackageAmountAttribute         (chapter 74)

Tipp: Six of the twelve patches have no dependency at all and could run first in any order - Magento only guarantees the partial ordering that getDependencies() actually demands, not one fully deterministic sequence across all twelve.

Step 3: why setup:di:compile isn't optional here

In developer mode, a lot works even without an explicit compile run, because Magento auto-generates missing generated classes on demand. That doesn't hold consistently for this module: the new configuration type (LoyaltyFeatureFlagsConfigType, chapter 88) adds itself as an extra entry to the types argument array of Magento\Framework\App\Config - an array merge in di.xml that, per this project's own recorded experience (feedback_di_xml_compile_gotcha), can be silently ignored even in developer mode without a compile run, and should be run twice when in doubt.

bin/magento setup:di:compile
# for stubborn cases (the configuration type doesn't show up):
bin/magento setup:di:compile

Achtung: On a production system in production mode, setup:di:compile is mandatory regardless - Magento doesn't auto-generate missing classes there. A forgotten compile run doesn't show up as a silently ignored setting there, but as a hard 500.

Step 6: why deploy both areas

Block 7 brings Knockout admin components for the Page Builder preview (chapter 60), block 8 a Knockout payment-method component in the storefront checkout (chapter 65) - both live under view/adminhtml/web/ and view/frontend/web/ respectively, and so the setup:static-content:deploy run must cover both areas, not just the storefront the way a pure theme update would.

Step 8: verifying cron activation

The custom cron group mironsoft_loyalty (chapter 32) doesn't become active through a dedicated installation command, but automatically, as soon as the config cache (already flushed by cache:flush in step 7) re-reads crontab.xml and Magento's generic ProcessCronQueueObserver generates new entries for every active group on the next regular cron tick. bin/magento cron:run triggers that generation immediately instead of waiting for the next system cron tick - handy for verifying right after a deploy.

With a successful deployment, basic functionality is confirmed - chapter 100 looks at how the module behaves under load.