Skip to content

Using Git: Taking the Pain Out of Version Control

By GRAYBOX Alumni
Technology

I love elegance, purity and simplicity

In the 90's as a rookie developer, I spun my wheels… a lot. With no true version control, we would update the production server directly. Then, weeks or months into the project, we would spend the time to set up a dev server. Our team would do their best to wrangle the process of developing locally, updating a dev server, and when everything was tested we would update everything on the production server and pray everything was put into place correctly. But we often wrote over each other's code and our only saving grace was a nightly server tape backup. I would keep local copies of different versions of folders and files: index.php.bak1, index.php.bak, index.php.final, index.php.final2 (how many times did I think this was going to be the final version of this page? Too many to count.) These were dangerous times, and had some dire consequences, and I wasted a lot of resources.

Along came SVN and it made my life less stressful. I created our repositories for the team and loaded everything into TortoiseSVN. I tolerated the .svn files and directories created throughout our project. And before pressing the button, we would lay an offering at the altar of "merge"‚ hoping the gods would smile down on us. More often than not, a bolt of lightning would strike us down and we would have to back out, make changes, and try again.

We were never fully successful at setting up deployments to the production server. I'm smart about some things, but with so many layers of complexity it was just easier to ftp files into place.

Today's process is so much simpler, safer and elegant.

We now use Beanstalk, a version repository hosting service. They still support svn if you need it, but Git has taken over as everyone's version control of choice and for good reason.Git gives us the simple elegance of editing locally and pushing to development or production when your code is ready for prime-time.

How does it work? (source)

In Beanstalk, FTP/SFTP deployments work as a synchronization tool. After the first deployment Beanstalk will check for changes in the most recent revision of your repository to the one on the remote server. It will then upload those changes to the remote server, which makes it extremely fast to keep everything up to date. Beanstalk will add, edit and remove files as they were added, edited and removed in the repository.

You can trigger a deployment in three ways:

  1. Automatically each time a commit or push is made in the repository.
  2. Manually in your Beanstalk account.
  3. Adding a tag to any commit or push comment like [Deploy: Staging]

If you are deploying manually, Beanstalk allows you to select any revision in the repository. This way, you can choose an older one to rollback in case of any problems introduced in a recent deployment. If you are using SSH deployment, we'll simply run the shell command you enter on your settings page whenever a deployment is triggered. These can be triggered in the same three methods as FTP/SFTP deployments.

Beanstalk

What Beanstalk has done better than anyone else I'm aware of is make the deployment to your development and production servers painlessly simple. After you push changes to your repository, it can SFTP into your site, update the files that change, and even execute other commands or post back to a web hook when complete. We have it clear the cache directory after every push - a lifesaver for heavily cached systems like Magento. It takes a few minutes to set up, and will save you tons of time and resources. Resources:

Blog & Events

Featured Work