Development environments & source control

One thing that I see asked repeatedly online is how people manage their development, either for a small & simple project or a large and complex project. The setup obviously depends on the project and the requirements. However, personally I have 3 development environments, whereas at work we have 4:

  • Local environment
  • Staging environment
  • Live environment

Local Environment

For this, I either run MAMP or XAMPP depending on the OS that I am using. My XAMPP install normally is configured to run two different MySQL servers, and run two different codebases for each virtual host that is set up.
Also, ensuring that database names, usernames and passwords are consistent on my local environment as on the live environment reduces the edits to code that I need to do before going live.

Staging Environment

Ultimatley, there’s not a huge amount of difference between this & the live server. The main difference being that the database used within the staging environment is completely different to that of the live environment. Normally a command is ran to update the staging database with a complete copy of the live database, normally ran at the least trafficed time of the site.

Live Environment

This is what the users see, and is what is live on the site. What with the clue being in the name.

How does source control fit in?

Currently, I use SVN for the source control of my projects, the reason being that it is what we use at work & what I know. I use Beanstalk to host the repository, and use their integrated deployment functionality to push the code from the repository to live.

I commit … Staging gets touched

The way that the deployments are configured, if ever a commit is made the code is automatically uploaded to the staging server. This means that the staging server is a complete copy of the repository where everyone can play around & test each other’s code etc.

To push live, the wonders of Beanstalk mean that if I name the live server Pikachu all I have to do is ensure that within my commit message I have put [deploy: Pikachu]. This will then do to the live server, what is done to the staging server, all of the code is pushed live.

Versions, Tortoise or CLI

One thing you’ll find is that I’m inherently lazy in what I do. People question why I do something one way, instead of another way. I for one, rarely (or ever) use command line for any sort of committing, or source control. The main reason being that if there is a nice GUI out there to do it for you, why not embrace it, use it and push your experience to the limit.

On Windows, I find that TortoiseSVN is the best option out there at the moment. Integrating amazingly well with the context menu, as well as deep integration with explorer to highlight the current state of a file, or directory.

When dabbling away on my Mac, I forked out for the amazing app that is Versions, whether that’s down to the student discount that I got on it, or whether it’s simply because it’s a suggested app by the fine folk at Beanstalk. Either way, it’s easily one of the best (if not the best) for SVN & Mac.