Summer '10 is almost upon us, but I have been recently working a lot with a feature initially introduced in Winter '10: Deployment Connections. At a high level, Deployment Connections allow the establishment of connections between orgs affiliated with a production org (for example, any sandboxes created that are associated with the production org.) Deployment Connections are used to push Change Sets between orgs for updating or adding new functionality. But there is an additional step when creating Deployment Connections which makes this feature even more compelling: authorization.
However, just establishing a Deployment Connection between related orgs is not sufficient to push a Change Set. You must explicitly authorize the 'direction' of the Deployment Connection. At first, this step may appear superfluous—why authorize a connection I know I want? But when we look at the purpose of authorization, the power of Deployment Connections and Change Sets becomes increasingly important.
Authorization of Deployment Connections is used to enforce code promotion paths. In my experience, developers often forget the best practices around code promotion that they learnt during their time in 'traditional' programming models vs. could computing. Deployment, regression testing, iterative development, and a clean test environment are just as critical as ever!
Take the following diagram as an example of a typical customer's production environment in Salesforce.com. The customer may have custom cloud components, or perhaps focused more on Sales Cloud functionality; it doesn't really matter. What does matter, however, is that Production is tested, clean, and can be replicated into Development as needed (so developers have the most recent code and data to work with).
Notice the one way arrow between Production and Dev? This indicates the Deployment Connection is only authorized to send Change Sets from Production to Dev. Makes perfect sense doesn't it? Of course you don't want to push code directly from Dev into Production (we have all done this in the past and know the problems it can cause — I suspect this the real reason why I am loosing my hair and it is turning grey already!).
Just as we want to prevent undesirable behavior, we also want to reinforce the good. Iterative development is a good practice, and the environment must support this. In our diagram above, this iterative development is indicated by the bi-directional arrow between Dev and Test: the Deployment Connection is authorization to push both ways. I find the push from Test to Dev particularly useful when I want the latest branch of code which is tested but not promoted to Production yet.
Although Deployment Connections and Change Sets have been available in the platform for some time now, I suspect many developers have not tried that out. The reason for this may be that the majority of developers sign up for a Developer Edition (DE) org. DE orgs are great for developing, but they do have a major drawback—you can't promote your code to Test or Production. The result is that you have no access to a sandbox, and therefore no ability to try out Deployment Connections and Sandboxes. Thankfully, there is another org—the Force.com Free Edition (FFE)—that let's you build a single Custom Cloud app, and push it to production for a up to 100 users.
Even you are not intending to build a production app from FFE, I highly recommend signing up for an org (it's free!) and trying out Deployment Connections and Change Sets to help enforce some more software development lifecycle practices. Once you start, who knows you might be hooked :)