Skip to main content
ShumoulShumoul Developer Portalplatform.shumoul.com
Version: Latest

12. Production Readiness and Adding Future Packages Safely

12.1 Migration status​

No migration was required or created. Every entity used already existed (SubscriptionPackage/SubscriptionPlan/SubscriptionPlanPackage/SubscriptionFeature/ SubscriptionPackageFeature/SubscriptionFeatureSettingsGroup/SubscriptionPackageFeatureRule/ SubscriptionFeatureReportAction/AppReportNameAction) — this task only added seed data through five new ICustomSeeder classes and one additive JSON row, plus Shumoul.Framework.MultiTenancy.Api's version bump (1.0.116 → 1.0.117) and the corresponding BackEnd PackageReference update.

12.2 Deployment​

The five new seeders run automatically at Shumoul.Api startup (same CustomSeederRunner pipeline as every existing seeder) — no manual production step is required beyond the normal package release + deploy. First startup after this deploy inserts the 4 packages/8 plan-packages/14 package-features/5 rules/21 report-action links; every subsequent startup is a confirmed no-op.

12.3 How to add a future package safely​

  1. Add a package entry to Packages/ShumoulSubscriptionPackages.json (or a new, similarly-scoped JSON
    • seeder if it's a genuinely different product line) — never edit the original, gated SubscriptionPackages.json/SubscriptionPackageSeeder.
  2. Decide the package's feature set from the already-existing SubscriptionFeature catalog first (Chapter 3) — only add a new SubscriptionFeature if no existing key fits, and only through the admin API (never invent one in a seeder).
  3. Add (PackageFName, FeatureKey) rows to Packages/ShumoulPackageFeatures.json.
  4. If the package needs limits, add (PackageFName, FeatureKey, EntityName, RowCounter, ApplyPeriod) rows to a rules JSON, attaching each rule to the single most relevant feature the package includes. Remember: seeding a rule only makes it queryable/displayable — enforcement is a separate step, see Chapter 13 for the enforcement mechanism now in place for Shumoul Starter's five rules.
  5. Add (FeatureKey, ReportNameActionKey) rows to FeatureReportActions/ShumoulFeatureReportActions.json, using only ActionKey strings already derivable from Reports.json/ReportActions.json (Chapter 8) — never invent a report or numeric Id.
  6. Never reuse the gated legacy seeders (SubscriptionPackageSeeder, PlanPackagesSeeder, Starter/ Basic/AdvancedPackageFeaturesSeeder, SubscriptionFeatureReportActionSeeder) as a template for new work — they only run once, ever, per environment (Chapter 4). Always follow the gate-free ComputeSeedPlan pattern this guide's seeders use.
  7. Add a ComputeSeedPlan unit test suite and an "only references known-safe features"/"never references Administrative/platform reports" regression test, mirroring Chapter 11, before considering the package done.
  8. Confirm on GET api/Subscription/Packages/pricing that the package appears correctly before registering any real or test tenant against it.

12.4 Read-only production checks (if this work is deployed)​

Since no migration or destructive change is involved, the only recommended production check after deploy is confirming the seeders ran cleanly (search production logs for "Completed seeding Shumoul subscription packages" with the expected Inserted=4 on first deploy, Inserted=0 thereafter) and that GET api/Subscription/Packages/pricing returns all four new packages alongside the three existing ones with no duplicates.