Deployment Best Practices #3 – Using Environment Deployment Branches
I think that most of you (at least those, who are using or considering switching to Git) are aware of the concept of topic branches. The concept is also applicable to Subversion too. We tend to use these a lot during our process. In addition to those temporary branches, we maintain three permanent ones, named after our environments: development, staging, and production.
Why not just deploy from trunk for production?
There are a bunch of articles about using branches in day-to-day development. Benefits are numerous, but the biggest and most obvious advantage for me at least is that you always have a reference to the state of your production environment. Should a bug arise, you can always switch branches, fix it, and deploy it without worrying about deploying half-baked features.
Deploying by Merging, while relying on Automatic Settings
Instead of using manual deployment for production and staging, you may setup an automatic one. The setup will look something like this:
- Development server is set to automatic deployment from
/trunk; - Staging server is set to automatic deployment from
/branches/staging; - Production server is set to automatic deployment from
/branches/production.
Any time you wish to deploy to the staging environment, you can merge from trunk (or the respective branch) into branches/staging and commit – Beanstalk will take care of the rest from here.
As I wrote this article, I realized that the practice described will result in a bunch of “empty” releases, where release is executed, but nothing is actually deployed. This happens when you commit to /trunk, but deployment is setup from, say, branches/staging. These empty releases are harmless, but why not optimize that? So I took some time and fixed that. This optimization is currently in its testing phase, and should be deployed soon.
As our support grows, I am amazed to learn the various creative workflows people have developed utilizing the releases features. Don’t hesitate to comment and share some of them with us – we are here to help!
