- What is dragon-code/laravel-migration-actions used for?
- It lets you define action classes with up() and down() methods and run them during deployment alongside schema changes, so data backfills, cache flushes, lookup-table seeding, and config migrations become versioned, once-only deploy steps. Actions are tracked similarly to migrations, so they do not re-run unintentionally. The package is additive and does not replace Laravel's migration runner.
- How do I install laravel-migration-actions in a Laravel app?
- Install it with composer require dragon-code/laravel-migration-actions. The package uses PSR-4 autoloading and service provider auto-discovery, so manual provider registration is normally unnecessary. Generate an action class with the provided artisan generator command, commit it, and add the package command to your deploy pipeline.
- Does laravel-migration-actions support queued actions?
- Yes. Release 7.3.0 added the ability to dispatch actions as queued jobs, with a configurable job class and uniqueness-lock duration. Inline execution remains available for short deploy-time tasks. For queued actions, you need a working queue connection, worker capacity, retry and timeout policy, and a shared lock store.
- How does laravel-migration-actions track which actions have run?
- The package keeps an execution record in a database table, similar to how Laravel tracks migrations, so an action is not executed again after it has been recorded. This makes actions reviewable, versioned deploy steps. Treat that table as part of your deployment state and include it in backups and restores.
- What is the --isolated option in laravel-migration-actions?
- The --isolated option uses Laravel's Isolatable behaviour, backed by an atomic cache lock, to prevent the same action from running concurrently. It provides real isolation only when the lock store is genuinely shared and atomic across all deploy containers, such as Redis, memcached, or the database cache driver. Array or per-container file cache in a rolling Kubernetes deploy can make isolation ineffective.
- How should I configure the queued action lock TTL?
- Set the uniqueness-lock duration comfortably above your p99 queue wait time plus the job runtime. If the lock expires before the job finishes or starts, a second dispatch can run the same operation concurrently. Monitor and alert on operations that exceed the configured TTL, and adjust the TTL as queue latency changes.
- What Laravel and PHP versions does laravel-migration-actions support?
- The package is maintained on an established 7.x release line and follows standard Laravel package conventions, including PSR-4 autoloading and service provider auto-discovery. Exact Laravel and PHP version constraints are defined in the package composer.json. Check those constraints against your application before upgrading, especially if you are on an older Laravel release.
- Can queued migration actions cause deploy ordering problems?
- Yes. With inline execution, a finished deploy implied finished operations; with queued execution, the release can complete while an action is still pending or stalled behind a backlog, so new code may run against old data. You need a deliberate strategy: wait on the job, gate on the execution record table, or design around the skew. This is a genuine ordering hazard for data-dependent releases.
- How do I test laravel-migration-actions in local development?
- Use a local database and a queue connection you control, and run the action command against a disposable database to verify up() and down() behavior. For queued actions, test with a real shared lock store or an equivalent test double so isolation and TTL behavior are exercised. Keep action classes small and idempotent where possible to make tests and retries safer.
- What are alternatives to laravel-migration-actions for deploy-time data tasks?
- Teams often use one-off artisan commands, raw SQL scripts, seeders, or Laravel migrations with data operations, but those lack once-only action tracking and can become ad-hoc deploy hacks. Laravel Migration Actions organizes those tasks as versioned classes with up() and down() methods and execution records. If you only need simple schema changes, Laravel migrations alone may be sufficient.