You’ve heard about it – Subversion, Git, Mercurial, there’s a ton of them. They’re all version control systems. Version control is great, and all the big guys use it, but what is it for? More importantly, why do you need it?
Let’s say you’re doing your development work old-school style. You jump into Dreamweaver, download a file, upload the file, go to the website and see your work.
Wait – the site crashed.
How did that happen? You realize that the download didn’t work. Either that or you forgot, and now you’re up that old creek without a paddle. It’s OK, you’ll just grab a backup copy of the file. Actually you won’t, because you don’t have one. Why don’t you have one? It’s because you weren’t using a version control system.
If you take it to its simplest form, version control works like this:
• Developer (let’s call him Bob) creates a file.
• Bob checks that file into a repository
• Later on, Bob (or someone else) wants to make changes to that file, so they checkout the file.
• When these changes are done, Bob (or that someone else) commits the file to the code repository. The file is given a new version number.
Your old version is kept in history so if you mess anything up you can always put it back. This is only the beginning, though.
Here are some other cool features of version control:
Branching allows you to create new features or versions of a product. You can work in a branch and not affect your trunk (stable area).
Merging allows you to get code from one place into another. This is often used once a development branch becomes ready for release. You would at that time merge that branch into the trunk. You can also merge revisions. This is an excellent way to do feature development. When doing more advanced versioning, you can also merge files together – for example, Bob and Someone else edited the same file at the same time.
Tagging is generally used for creating a snapshot for a release. You may tag releases as 1.0, 2.0, 3.0, etc. This is a great way to do it and is easy no matter which version control system you use.
While these are only the very basics, it should give you an overview of why code versioning is important. If the gears aren’t turning yet, think of these positives:
• You have a history of all your code changes
• Many people (in many places) can work on a project together, without stepping on toes
• If something is broken, you can hold someone accountable. On the other hand, if something is wonderful you can also hold that person accountable
• Roll back to earlier versions
How does this all come back to Magento? First of all, if you’re developing on a platform this big and you’re not using version control your life will become easier.
Here are a couple of use cases to think about:
Upgrading Magento can go very smoothly. It can also have a few roadbumps. If you use a lot of modules or the theme structure needs to change, you’ll need to proceed with caution. Version control will make this super easy. First, tag your trunk into a version 1.0 (or however you prefer your tags). Then you can create a branch of your site and upload all the new core files. Deploy those files to staging and see how everything goes. If there are things to fix, you can add those to the branch. Once everything is going well, merge that branch into your trunk, tag, and deploy.
Magento themes can be very complex, and a little change can go a long way. Using version control purely to know what you’ve changed and when can be a real life saver if something goes wrong – and that’s what it’s all about. You always have a backup, of a backup, of a backup.
Branching is great for building features. If you’re primarily a shop that builds modules, you could plan out months worth of features and put each feature into a branch. If people are doing bug fixes in your trunk, then do daily or weekly merges of the trunk into your branches. This will ensure that you’re working on the best base possible.
Remember that any version control is better than no version control. Try out a few. Many people find Subversion to be the easiest to use with PHP. It’s a central repository that everyone commits to. Many people now are using Git and Mercurial as well. They have a lot of benefits over Subversion. The first is speed. They are blazingly fast. The other advantage is that you work in a local repository and then push your changes up to the main repository. At first it can be overwhelming but once you get the hang of it, you’ll find that you have much more flexibility. I figure it’s worth mentioning that Magento, Inc. officially uses JIRA and Subversion. Personally, I use a mix depending on the size and project and management style of a particular project.
Here’s a few great we recommend to get you started:
Beanstalk is a great product by Wildbit that hosts your repository (svn or git). They also have an excellent deployment system that allows you to have multiple servers set up behind different environments. For example, you might have one staging server but four production servers. It gets even better in that you can set up automatic or manual deployments, so staging may be set up to automatically deploy but for production you might want to push a button. There are also integrations with other systems, such as project management and ticketing systems. These integrations allow for you to post commits to Basecamp or change ticket statuses from your commit message. It’s a well-made product with great customer support.
Github has gained a lot of attention over the past few years, partly due to Git being the version control system of choice for Ruby on Rails developers (Ruby is the #2 language on Github). We’ve had great success using Git with Magento, and Github has over 50 integrations!
JIRA has been around for years. It’s a product for ticketing that’s released by Atlassian. JIRA runs on a Java stack, and there are many plugins for it. There are also other products that Atlassian has released that work side-by-side with JIRA. If you’re not familiar with maintaining a Java stack, this may not be for you. BUT – this is where JIRA Studio comes in. Studio comes with the following products:
• JIRA: Ticketing
• FishEye: Source code browsing
• Confluence: Wiki
• Bamboo: Continuous Integration
• Crucible: Peer code review
The price point isn’t bad, but definitely has a learning curve. It’s great product, and their ticketing process is open to the public so you can always find our what’s coming up. We’ve been investigating using Bamboo to run PHPUnit tests, and it’s pretty cool stuff. The biggest downfalls are these: There’s no Git or Mercurial hosting (for now), and there’s no custom post-commit hooks (to call a url after you’ve committed). Also remember that this is not a deployment system.
DeployHQ is a simple hosted product that works great. Let’s say you’re on a system that doesn’t deploy, but you need to get your files out there easily. DeployHQ will connect to your repo and deploy for you. It works with svn and Git, and works well. You can deploy two ways:
• Manually: Enter beginning and ending revisions, then click a button
• Automatically: Have your post-commit hook pointed at a custom URL that will trigger a deployment
That’s about it for now. Have fun trying this stuff out and as always feel free to contact us for pointers.