Console Laravel Package

Product Decisions This Supports

• Admin-Driven DevOps Workflows: Enable non-technical stakeholders (e.g., QA, support, or product teams) to trigger critical backend operations (e.g., cache clearing, search reindexing) via a familiar UI (Sonata Admin) without CLI access.
• Auditability & Debugging: Centralize command execution logs in the database to track operational changes, troubleshoot failures, and comply with audit requirements (e.g., "Who cleared the cache and when?").
• Reduced CLI Dependency: Eliminate manual CLI usage for routine tasks, lowering friction for teams unfamiliar with command-line tools while maintaining consistency.
• Roadmap for Self-Service Operations: Build toward a "no-code" operations portal where teams can trigger predefined workflows (e.g., "Reset test data," "Regenerate thumbnails") without engineering intervention.
• Build vs. Buy: Justify custom development if the package’s limitations (e.g., no argument support, rigid ignored-command list) conflict with your roadmap. Otherwise, adopt to avoid reinventing logging/auditability for CLI commands.

When to Consider This Package

• Adopt if:

  • You use Sonata Admin and need to expose CLI commands to non-developers.
  • Your team lacks a centralized way to log and audit command executions (e.g., for compliance or debugging).
  • You prioritize simplicity over flexibility (e.g., no need for dynamic command arguments or complex inputs).
  • Your ignored-command list aligns with the defaults (or you can tolerate the limitation until it’s addressed).

• Look elsewhere if:

  • You don’t use Sonata Admin (the package is tightly coupled to it).
  • You need dynamic command arguments (e.g., passing --env=prod or custom parameters).
  • You require fine-grained control over logged commands (e.g., excluding specific commands beyond the defaults).
  • Your stack uses non-PHP/Laravel tools (e.g., Symfony-only features may not translate).
  • You prefer existing solutions like Laravel Horizon (for queues) or custom scripts with logging middleware.

How to Pitch It (Stakeholders)

For Executives: "This package lets us turn manual, error-prone CLI tasks—like clearing caches or reindexing search—into clickable buttons in our admin panel. Non-technical teams (e.g., support, QA) can now trigger these safely without asking engineers, cutting downtime and dependency bottlenecks. Every action is logged in the database for audits or debugging, so we’ll never lose track of who did what and when. It’s a low-code way to automate routine ops, reducing toil and improving reliability."

For Engineering: *"This is a lightweight way to expose Symfony/Laravel commands via Sonata Admin with built-in logging. Key tradeoffs:

• Pros: Zero CLI dependency for common tasks, audit trails out of the box, minimal setup.
• Cons: Limited to Sonata, no dynamic args (yet), and ignored-command list is hardcoded. If we adopt, we’ll need to:

1. Test logging accuracy for our critical commands.
2. Decide if we can live without args or need to fork/extend it.
3. Document the new workflow for teams. Alternative: Build a custom solution if we need more flexibility, but this saves ~2–4 weeks of dev time."*