The AppManager help you manage your application. You can have multiple versions of an application online (for tests and rollback purpose), the App Manager allow you to choose which one is the one in production.
This application is really useful in mutual hosting, where you can't go with SSH to launch Symfony2 commands. You are able to clear/warmup cache, dump assets, install assetics directly from the web interface.
AppManager is based on semantic versioning. An application has a directory (for example : myApp) and every version has his corresponding subdirectory. The version 1.0.0 is located in
myApp/1.0.0. When you want to add the version 1.0.1 on the server, you have to create a new
1.0.1 directory where you will upload your application. You can create a zip archive containing the
1.0.1 directory and upload it into your
myApp directory, the AppManager will allow you to unzip the archive.
/apps | /myApp | /1.0.0 | /web | /app.php | /... | /app | ... | /1.0.1 => unarchived version of 1.0.1.zip | /web | /app.php | /... | /app | ... | /1.0.1.zip
All recognized versions are available in the AppManager and you will have access to every versions directly. You can remove an uploaded archive, remove a specific version and set a specific version as public application.
You can also execute commands on every versions separately and access different environments on every version (like dev, preprod, prod environment).
A lot of useful features with Symfony2's bundles are available through the CLI. But what about mutual hosting ? You can't access your server through SSH so you can't execute commands. The AppManager allow you to execute the commands through it's web interface.
On execution, the AppManager use the
php app/console list --raw command on app versions. This command return every available commands in the specified application's version. The available commands are shown in the web interface when the AppManager has been able to launch this command and get the results back. Sometimes, the default PHP binary is less than PHP 5.3. In this case you are able to specify a PHP binary path into your configuration.
When an application version is considered as stable enough to go in production, you can publish it. The directory containing the application (and its versions) isn't the same as the publication directory.
There is many ways to publish a specific version. The actual implemented manner is a symbolic link : the
publishedPath in the example below is a symbolic link to a specific version's web directory.
A simple example:
/apps | /CurrentApp | /1.0.0 | /web | /app.php | /... | /app | ... | /1.0.1 | /web | /app.php | /... | /app | ... /publishedPath | /app.php | /...
The main advantage of this behavior is when you decide to publish a specific version and it doesn't work as espected, you can publish the previous version back in production. You have access to every version too, allowing you testing the new versions before it's published in production.
More options will be added, like copying web directory into
app.php with a simple php file including the real
app.php, or using
Multiple applications management
Authors and Contributors