<?xml version="1.0"?>
<rss version="2.0">
  <channel>
    <title>PHPDeveloper.org</title>
    <link>http://www.phpdeveloper.org</link>
    <description>Up-to-the Minute PHP News, views and community</description>
    <language>en-us</language>
    <pubDate>Fri, 24 May 2013 10:07:59 -0500</pubDate>
    <ttl>30</ttl>
    <item>
      <title><![CDATA[Fortrabbit.com: Multi Stage Deployment for Website Development]]></title>
      <guid>http://www.phpdeveloper.org/news/18538</guid>
      <link>http://www.phpdeveloper.org/news/18538</link>
      <description><![CDATA[<p>
On the Fortrabbit.com blog, there's a new post looking at a system for <a href="http://blog.fortrabbit.com/multi-stage-deployment-for-website-development/">multi-stage deployment</a> at a high level, applicable to most of the tools out there.
</p>
<blockquote>
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. 
</blockquote>
<p>
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 <a href="https://github.com/nvie/gitflow">gitflow</a> and how it could help make this environment easier to set up for your applications.
</p>
]]></description>
      <pubDate>Mon, 01 Oct 2012 12:11:35 -0500</pubDate>
    </item>
  </channel>
</rss>
