Be Simple Deployment Bundle Laravel Package

Getting Started

Verify before you invest. This bundle has zero stars and zero dependents, which for a Symfony2-era package usually means it never reached a stable, widely-used state. Before wiring it into anything, clone the repository and check three things in order:

1. composer.json — the require block tells you the supported Symfony version (symfony/framework-bundle, symfony/console) and the PHP constraint. Anything pinned to ~2.3–~2.8 and PHP >=5.3 is EOL territory.
2. Command/ and DependencyInjection/ — the console commands are the actual product surface; the DI extension tells you what is configurable.
3. README/Resources/doc — deployment bundles of this vintage typically document a YAML config block plus one or two commands. If the README is a stub, treat the source as the documentation.

Minimal install (Symfony2 project):

composer require ibrows/be-simple-deployment-bundle

Register in app/AppKernel.php:

$bundles = array(
    // ...
    new Ibrows\BeSimpleDeploymentBundle\BeSimpleDeploymentBundle(),
);

Then look for the bundle's config key in DependencyInjection/Configuration.php and add it under that key in app/config/config.yml.

First use case: a "release directory + symlink swap" deploy to a single staging host. That is the pattern these bundles exist to solve — build a timestamped release folder, run the app's warmup steps (cache clear, asset install, migrations), then repoint a current symlink. Confirm the bundle actually does this by reading the command before assuming it does.

Implementation Patterns

Treat it as a thin wrapper around shell commands. Packages in this niche almost always shell out to rsync, ssh, git, or tar. Your day-to-day work is therefore configuration of paths, hosts, and hooks, not writing PHP against an API.

Environment-scoped config. Keep one block per target (staging, production) with:

• local source path and remote target path
• remote host/user (prefer delegating credentials to ~/.ssh/config rather than inlining them)
• the release/current/shared layout if supported
• an ordered list of post-deploy tasks

Hook ordering is the whole game. Typical sequence:

1. create release directory
2. transfer or check out code
3. symlink shared resources (app/config/parameters.yml, web/uploads, var/logs)
4. install dependencies (composer install --no-dev --optimize-autoloader)
5. warm the cache for the correct environment (cache:clear --env=prod --no-debug)
6. install assets (assets:install web --symlink, assetic:dump --env=prod)
7. run migrations (doctrine:migrations:migrate --no-interaction)
8. swap the current symlink
9. reload PHP-FPM / opcache invalidate

If the bundle exposes hooks as config, enumerate them explicitly rather than relying on defaults — defaults are the first thing to drift when a package is unmaintained.

Wrap it in your own script. Put the invocation behind a small bin/deploy.sh or a Composer script so the exact flags, environment, and pre-flight checks live in your repo, not in tribal knowledge. This also gives you a one-line swap to Capistrano/Deployer/Ansible later without retraining the team.

Integration with CI: if the command is deterministic and non-interactive, it can run from a CI job with an SSH key mounted as a secret. If it prompts for confirmation, add a --no-interaction-style flag check first; if none exists, that is a hard blocker for automation.

Gotchas and Tips

Symfony2 is end-of-life. Symfony 2.8 lost security support in 2018. Any bundle in this ecosystem should be considered a liability on a modern codebase. If you are on Symfony 3/4+, the bundle will not autoload against the current Kernel contract and there is no upgrade path unless you fork it.

Zero stars / zero dependents means unvetted. There is no community signal that this code has ever run in production. Audit the command classes for: unquoted shell concatenation (command injection through config values), exec() without exit-code checks (silent failed deploys), and destructive operations (rm -rf on a path derived from config) without guards.

Failed deploys leave partial state. Check whether the symlink swap is the last step. If the release directory is created and populated before the swap, a failure is recoverable; if files deploy in place, a failure is a half-deployed app. Prefer the former and keep the last N releases for rollback.

Cache and opcache are the classic trap. cache:clear in a release directory writes absolute paths into the container. If your current symlink path differs from the release path used during warmup, you will ship a cache built against the wrong directory. Warm the cache after the swap, or use a fixed current path in the command.

Permissions bite on shared dirs. var/logs, var/cache, and web/uploads must survive the swap and be writable by the web user. Verify the shared-symlink step exists; if the bundle does not support it, do it manually in your wrapper script.

Rollback is not free. A symlink repoint is instant, but the database migration is not. Keep migrations backward-compatible for one release, and know whether the bundle keeps old release directories — if it prunes aggressively, your rollback window is shorter than you think.

Debugging approach: run the deploy command with -vvv first. If output is opaque, add temporary echo in the command classes (you are already forking-or-vendoring an unmaintained package, so local patching is expected) or run each underlying shell step by hand to isolate which one fails.

Extension point: the DI extension and the command's configure() method are the only realistic extension surfaces. If you need custom behavior, subclass the command and register it as a service with a distinct name rather than modifying vendor code.

Recommendation: for a new project, use Deployer, Capistrano, or Ansible. Consider this bundle only if you are maintaining an existing Symfony2 app that already uses it, and even then, budget time to vendor the code into your repo so a future composer update cannot silently remove it.