Creating a staging environment is specific to your production environment. There is no magic solution that works in every situation. But most cases follow a similar pattern, and I'll cover all the key points as we go along. It's fair to assume that most people deploy their apps with some kind of versioning tool (like GIT). [...] Besides GIT, you have to think about the languages, software, and "special" features your production servers offer.

All of the commands and configuration files you'll need to make the automatic setup work are included in the article. It's based on a Debian (Squeeze) base image and uses packages to install the needed software. They also install other PHP extensions like mycrypt, GD, curl, APC and database support (MySQL, SQLite and Postgres). They help you get Apache set up to serve the application and work with git and its hooks to push the code and run Composer.

This article targets new developers and developers which never had the chance working with multi versioned websites before. If this fit's you: Read it. Staging is a good tool in your belt you won't regret to know. [...] You, your co-developers, authors and whatnot using [staging] to prepare and test stuff which is to be released into production. In short: you do not perform open-heart surgery by coding directly on the production website.

He talks about the "stages" part of the "multi-stage" structure, mentioning the separation of purpose they provide and an example of a three level configuration (dev, staging, production). An optional fourth level can be added as well for testing purposes. There are some downsides to this approach, though: data synchronization, code deployment delay and complexity. There's also a mention of gitflow and how it could help make this environment easier to set up for your applications.

This [move from svn to git] left a bit of a gap in my process where I could no longer test on a remote server without updating it manually by S/FTP or opening terminal and manually calling a git pull. Open terminal and manually git pull it did break up the work flow a bit so using the Dingo framework I created a very simple Git helper and gave it its own URL something like git/pull.

He added a post-receive hook to his git server that calls this "git/pull" URL on the staging server and updates the code on the server. This provides an easy asynchronous way to update things on another server. Note, though, that this should never be done on a publicly accessible server - it's a pretty large security hole (or at the very least made secure somehow). He used Dingo to create his interface, but something like the Slim micro-framework could have worked just as well. You can view his code on github.

This system allows you to make changes to a website and preview them before actually going live. It can be implemented with any website, we will show the necessary requirements and steps to implement with symfony and Apostrophe CMS, but you can also take parts of the tutorial and implement them without these applications. We have found this workflow suitable in a number of projects and wanted to share it.

The process can be modified to fit the needs of your symfony application (or really any app with enough tweaking) since it uses several "off the shelf" tools like Apache, PHP, symfony, Gearman and Supervisord. The sfSyncContentPlugin plugin is a bit more specific to Apostrophe, though. They walk you through the integration of all of the tools - starting up Gearman and Supervisord, making a worker and setting up your symfony configuration to have a "publish" route to set things in motion.