Ezmigrationbundle Laravel Package

Product Decisions This Supports

• Legacy System Modernization: Enables controlled, versioned migrations for eZPlatform 1/2 or eZPublish 5, reducing manual intervention and risk during upgrades or schema/content changes.
• Build vs. Buy: Avoids reinventing migration logic for eZ-specific workflows (e.g., content types, locations, roles) while leveraging Symfony’s mature migration ecosystem.
• Data Governance: Supports compliance requirements (e.g., GDPR) via structured content/attribute updates, deletions, or auditable SQL/process steps.
• Feature Roadmap:
  • Phase 1: Replace ad-hoc migration scripts with versioned, rollback-capable workflows.
  • Phase 2: Integrate with CI/CD pipelines to automate post-deploy migrations (e.g., trigger kaliop:migration:migrate after deploy).
  • Phase 3: Extend for A/B testing by branching migrations (e.g., conditional steps via event listeners).
• Use Cases:
  • Content Restructuring: Bulk updates to content types, sections, or permissions (e.g., migrating from "Article" to "Blog Post").
  • Data Cleanup: Purging orphaned content/versions or fixing corrupted metadata.
  • Feature Flags: Dynamic content activation/deactivation via migrations tied to release cycles.
  • Third-Party Integrations: Syncing eZ data with external systems (e.g., HTTP calls to APIs, email notifications).

When to Consider This Package

• Adopt When:
  • Your stack includes eZPlatform 1/2 or eZPublish 5 (not Ibexa DXP 3/4; use alternatives like tanoconsulting/ezmigrationbundle2).
  • You need repeatable, auditable migrations for database schema and content (vs. pure schema tools like DoctrineMigrations).
  • Your team lacks deep eZ API expertise but requires low-code migration DSL (YAML/SQL/PHP) with validation.
  • You prioritize safety over speed: Transactions and rollback snapshots mitigate risks of failed migrations.
  • You’re migrating from legacy ezxmlinstaller or manual scripts to a modernized workflow.
• Look Elsewhere If:
  • You’re on Ibexa DXP 3/4: Use tanoconsulting/ezmigrationbundle2 or ibexa-migration-bundle.
  • You need real-time migrations (this is batch-oriented; consider event-driven approaches for live systems).
  • Your migrations require complex business logic not expressible in YAML/SQL (use custom PHP migrations or event listeners).
  • You lack PHP 5.6+ or Symfony/eZPublish 5 compatibility.
  • Your team prefers GUI tools (e.g., eZ Platform Admin UI extensions) over CLI-driven migrations.

How to Pitch It (Stakeholders)

For Executives:

*"This package replaces error-prone, undocumented migration scripts with a structured, version-controlled system—like Git for database/content changes. For eZPlatform 1/2 or eZPublish 5, it lets us:

• Automate risky upgrades (e.g., schema/content changes) with rollback safety.
• Reduce manual work by 80% for tasks like bulk content updates or permission fixes.
• Audit every change via timestamped migration files and database logs.
• Integrate with CI/CD to enforce migrations post-deploy, cutting post-launch fires. Think of it as ‘migration as code’—just like we treat infrastructure with Terraform or Kubernetes. The cost? Minimal (open-source, PHP 5.6+). The upside? Fewer outages and faster feature rollouts."

For Engineering:

*"This is DoctrineMigrationsBundle for eZ-specific workflows, with superpowers:

• DSL for eZ entities: YAML/SQL/PHP to manipulate content types, locations, users, and even run HTTP calls or emails—no custom API code needed.
• Atomic safety: Transactions auto-rollback on failure; snapshots enable true rollback.
• Extensible: Hook into migration steps via Symfony events (e.g., log changes, validate data pre-execution).
• DevOps-friendly: CLI commands fit into scripts (e.g., kaliop:migration:migrate --path=my_bundle/Migrations/2023*) or CI pipelines. Downside: PHP 5.6+ only; not for Ibexa DXP 3/4. But if you’re stuck on eZPlatform 1/2, this is the only mature migration tool that handles both schema and content."*

For Developers:

*"Key wins:

1. No more ‘oops’ migrations: Transactions + snapshots mean failed steps don’t corrupt your DB.
2. Reusable templates: Generate skeletons (kaliop:migration:generate) and fill in YAML/SQL/PHP—no boilerplate.
3. eZ-specific shortcuts: DSL for content/locations/users/roles (e.g., mode: create type: content content_type: folder).
4. Debugging: kaliop:migration:status shows applied/failed migrations; --dry-run mode tests changes. Example workflow:

# Generate a migration for adding a 'Blog' content type
php bin/console kaliop:migration:generate --format=yml MyBundle AddBlogContentType

# Edit the YAML, then apply:
php bin/console kaliop:migration:migrate --path=src/MyBundle/MigrationVersions/20230616_*

Pro tip: Use event listeners to add pre/post-step logic (e.g., notify Slack on failure)."*