Deployment Bundle Laravel Package

Getting Started

This bundle is a Symfony 2-era console-based deployment orchestrator. It centralizes release steps (git pull, composer install, cache warmup, asset dump, migrations, permission fixes) into named, configurable task lists you run from the CLI instead of hand-maintaining a shell script.

First steps:

1. Install via Composer — it targets Symfony ~2.x, so it will only autoload cleanly on a legacy app. On anything Symfony 3+ or PHP 7.2+, expect friction before you've written a line of code.
2. Register the bundle in app/AppKernel.php for the environments you deploy from (typically prod and a staging env).
3. Read the config reference first, not the commands. Everything meaningful lives under presta_deployment: in app/config/config.yml — this is where you declare the task sequences you'll actually run. Look at the bundle's DependencyInjection/Configuration.php if the README has drifted (it has, given its age).
4. Run the help output — app/console list presta — to see the exposed deployment commands on your specific version. Command names and options shifted across the 2013–2015 releases, so trust the binary over the docs.
5. Wire one trivial task first: a config block that runs git pull on a staging checkout. Confirm the command executes and logs before you add cache clears or migrations.

The first genuinely useful use case: replacing an ad-hoc deploy.sh with a config-declared task list per environment (staging vs prod), invoked identically from CI or a shell.

Implementation Patterns

Task-list-as-config. The core pattern is declaring tasks in YAML and letting the bundle sequence them. Each deployment "scenario" is a named list; a developer runs presta:deployment:<scenario> rather than remembering order. Keep scenarios small and composable rather than one monolithic deploy.

Environment-scoped scenarios. Define separate task lists per environment (staging, prod) so that risky steps (migrations, cache clears) are gated explicitly rather than inherited. This is the main reason to use the bundle over a bash script — the diff between staging and prod deployment becomes reviewable YAML.

Chaining custom tasks. For project-specific steps, register a service implementing the bundle's task interface and reference it by service id from the config. This keeps bespoke logic (feature-flag flips, cache purges on CDN, symlink swaps) testable and out of the deploy config's inline shell strings.

CI integration. Invoke the deployment command from your CI job after a build artifact is in place. Because output is console-formatted, capture it as build logs; many teams wrap the invocation so a failed task stops the pipeline (verify the command's exit-code behavior on your version — see Gotchas).

Idempotency discipline. Design each task to be re-runnable: composer install --no-dev over a cached vendor dir, cache:clear regardless of state, migrations that are safe to re-attempt. The bundle executes tasks in order without rollback, so idempotency is your only safety net.

Local reproduction. Run the same scenario against a staging checkout from your laptop before trusting it in CI. Because tasks are just configured commands, this is cheap and catches ordering bugs early.

Gotchas and Tips

• It's archived and from 2015. Treat it as frozen. There will be no fixes for PHP 7.2+ deprecations, Symfony 3/4/5 incompatibilities, or Composer 2 issues. Budget time to vendor-patch or plan a migration to Deployer/Envoy rather than expecting upstream support.
• Symfony 2 only. Do not attempt to install alongside a modern Symfony app — the service definitions and console command signatures assume ~2.x. A fresh composer require on a current project will either fail resolution or produce a bundle that never boots.
• Exit codes and failure semantics. Older console commands in this era sometimes swallowed task failures and returned 0. If you drive deployments from CI, wrap the invocation and grep output, or patch the command to propagate non-zero exits — otherwise a failed cache clear looks like a green build.
• Config cache is a footgun. Changing deployment YAML requires clearing the Symfony config cache in the environment you're deploying from. A stale cached config is the single most common cause of "my new task didn't run."
• No rollback. Tasks run forward only. Keep releases directory-based (symlink swap) so rollback is a symlink flip, not a task the bundle reverse-executes for you.
• Secret handling. Credentials (DB, git remotes) must come from environment variables or Symfony parameters — never inline in the deployment config, which frequently lands in version control and CI logs.
• Extension point: the task interface is where you should live. Every project-specific need becomes a registered service task, not a growing inline shell command string. This is the only sane way to keep the config readable once you exceed a handful of steps.
• Logging verbosity. Bump console verbosity in CI (-v/--verbose on the command) so task output is actually retained; default verbosity often discards the one line you need when a deploy half-fails.
• If you're starting fresh today, skip it. For new work, reach for Deployer (PHP-native, actively maintained) or a plain Envoy/Ansible setup. Only adopt this bundle if you're maintaining an inherited Symfony 2 codebase where it's already in place.