Deploying the code: from the virtual development studio in the cloud(s)
Posted on March 14, 2012 by richard
Complex projects call for complex deployment methodologies. Not only that, complex Magento developer teams that aren’t necessarily sat in the same studio together or working the same hours need a flexible methodology where they don’t have to depend on each other too heavily. Here I will discuss one such methodology that I have used on several Magento based projects. I look at the basic network layout then at version control using Git and its numerous fringe benefits when you place this wonderful tool at the centre of your Magento developers studio.
Magento is a complex beast and Magento development mustn’t be carried out on a mission critical machine. If any of the features that you need to build for your project involve updating lots of records in Magento’s EAV tables then you’re going to need a dev server for development. Further, you’re going to want to make changes after you go live and making these changes directly in the live environment means you can’t get approval before you deploy. I recommend local development using a virtualised instance of Debian. I use VirtualBox to handle the virtualisation which is free and open source and in constant, active development. You don’t have to use Debian, by using virtualisation you can replicate exactly the conditions on your production (live) server, whatever they may be.
Local Magento development is fine when you just want a couple of developers that work in close geographical proximity to you to see it. What about when you need to show the client? In this instance you need a staging server. Again, Debian is my preferred OS. You need as much control as possible on the staging server so you should get a box in a data centre somewhere at a good rate. This box should never have to handle lots of requests as it should only ever be you, your Magento developers and your clients that look at anything on it. Hence, it doesn’t have to be super beefy and cost the earth.
Lets say you have three Magento developers working on a project in your studio. They’re all developing locally in your studio and then you also have the staging server. That’s 4 instances of your project, not to mention the live environment. Version control sits at the centre of the dev studio and brings it all together. Git is much more than mere version control, it’s a deployment and backup tool as well. Git is distributed version control. This means that there is no central code repository, every instance of the project is complete and self contained and does not depend on any connection with any other version of the repository to work properly. Obviously you want to maintain links between instances of the repository to keep them all up to date.
While Git is distributed and not dependant on the ‘master repo’ you will naturally nominate one particular instance as the notional ‘master’. That’s the one you all push to and pull from. Github provide Git repository hosting and I like to use one of their repos as my notional master. You have to pay to get private repos (public repos are free, ideal for open source projects) but if you’re charging a sensible enough figure for your highly sought after Magento development skills then this is a cost that you can afford. Once your studio has this in place, all your Magento developers, working locally, can be pushing to and pulling from the Github central repo. When you’re ready show the client, from the staging server you pull the repo from Github (ensuring that your devs have all pushed to the repo) to get the latest version and do the same on the live server when you’re ready to go live.
Github provide a few other features like a nice GUI to browse your repo and rudimentary ticket tracking. However, you don’t have to use Github. You can use your own server as a Github style repo manager and replicate pretty much all the tools that Github offer. Using Github does give your studio the added security of offsite backup but you can get that by housing your own repo manager on yet another external box.
In actual fact the possibilities are endless and you could use exactly the same tools that I have talked about here but in a totally different configuration. There is no correct way to do any of this stuff, just some ways that are more well reasoned than others.