PHP Auto-Deployment & Version Control Using BitBucket & BaseCamp

PHP Auto-Deployment & Version Control Using BitBucket & BaseCampIn this article I’ll explain how we can use auto-deployment and also incorporate BitBucket into BaseCamp. First, I will explain what they are and why we need them.

What we will achieve:

  • A project controlled by Version Control System
  • Auto-Deployment to the testing server/domain automatically on Pushing changes
  • Send revisioning information into BaseCamp Messages/Discussions
  • Notify any person directly

Jargon

VCS: Version Control System
DVCS: Distributed Version Control System (Git, in our case)
Pushing: sending modifications of files to the Git server
Pulling: getting modifications from the VCS server and merging it with local copy
Commit: same as push for Subversion VCS
Repository: The place where you Push your changes. Generally every project should be a separate repository.

Version (Revision) Control System (VCS)

In the development cycle, project files always change, as they should. The problem arises when we need a removed information / code block from a file or when we need a completely removed file. Version Control Systems keep track of the history, of all the changes made, so that we can view the old version of the file any time. This allows us to see which lines are affected on the next revision.

BitBucket

It is obvious that GitHub is the giant in Git-based Version Controlling. However, the pricing is substantial and not appropriate for our business.

GitHub limits the number of repositories, saying “You can only have this many of them.” At Optimum7 we have many projects, large and small. We want all of them in VCS.

BitBucket limits the number of users and provides unlimited repositories. That’s what we want; we are small in number but big in project count. BitBucket’s pricing suits us.

Version Control Software: Subversion vs. Git

I have experience with both Subversion and Git. However, there are other nice VCS’s out there like Mercurial and CVS. While an in-depth comparison would be redundant due to the number of accurate comparisons available on the internet, I will summarize the basics.

Git is DVCS (Distributed VCS) while Subversion is VCS. Basically, Git allows you to send changes to your local repository and make sure everything is satisfactory before sending to the main VCS server. With Subversion you must send the changes directly to the server each time you make them.

Unless you have used both Subversion and Git, it may be difficult to understand the differences between them. If you have not used them both, I suggest that you choose Git and skip the time spent researching, “Which VCS should I use?”

Development Environment

Because using a remote server, remote FTP or even a computer on a local network is slow; our own computer should be the development environment. Setting up a local web server for development will speed up the process, especially when working with a large quantity of files.

Note: If you think local networks are not slow, think about IDEs that must parse all files to be able to give you code auto-completion. Parsing all files, even over local network is slow. File permissions may also quickly become a problem.

Testing Environment

The best testing environment is on a server. You can purchase another domain used solely for this purpose, such as YourSite.info, or you can create a subdomain and use that for all testing. When you push your changes, it should automatically Pull them to update the local copy.

The most critical functionality is the ability to execute Git binaries from PHP. The exec() command is available, but it won’t work on shared hostings. This causes an additional permission problem. PHP files are run by Apache Web Server’s httpd executable, which are executed by Apache’s user when PHP has been installed as a module. However, shared hostings use suExec, where files run with your own user, causing a permissions problem. Git must be able to make any necessary changes to the files, so they must be set up with the same user. The best way to do this is to purchase a VPS (Virtual Private Server). Because it will be the testing server, the cheapest one will suffice. You should be able to find a VPS for around six dollars a month.

Tools We Need

Those tools are my recommendations.

For Windows: TortoiseGit
For Mac: SourceTree (from the owner of BitBucket itself)
A local development webserver: XAMPP (for Win + Mac + Linux)

Setting up the Auto-Deployment

I will not dive into Apache/PHP configuration. If you don’t know how to set up a web server or don’t have enough Linux knowledge, you should consult a professional.

First, we need to set the Git public/private keys for our local Git executable to work without a password. You may find tutorials by searching “linux ssh keys.” Generate a public/private key pair; put your public key into BitBucket (in your user account’s settings) and the private key into your server.

After that comes your BitBucket project. Click on the setting icon at the right, click Services, and add a POST service by putting the link of a PHP file on your testing server, which you may name git-auto-deploy.php.

The important command that you need to call in git-auto-deploy.php is:

shell_exec(“cd /home/user/public_html/ && git reset –hard HEAD && git pull origin master && chmod -R og-rx .git”);

Now this will change the current active directory to website’s root directory. Reset changes if there are any (otherwise a pull will fail), make the pull and hide the .git folder so people cannot publicly access it through their browser.

BaseCamp Integration

The BitBucket Services page offers a BaseCamp service, but it did not work for me. Instead, I use BitBucket’s Email Service and reply to BaseCamp Discussions through email, since BaseCamp has that functionality, which I find useful.

You can also send emails to other people who want to be notified immediately after a Push.

Note: I personally couldn’t be able to get a BaseCamp Discussion’s reply email address directly, instead I replied through another user, and BaseCamp emailed me the notification with the reply address. There may be a better way, but this works for me.

A Few Tricks
  • Keep your development and testing environment’s database users and passwords the same; it will make things easier.
  • Use relative paths, not absolute paths (not just for links but also for the file inclusions, etc.)
  • Never change a file through FTP, always change them through VCS.

Let us know if you need assistance with this process. We can help! Contact us today.

Editorial by Lisa Sherman.

October 1, 2013

Written by Ata Sasmaz

This entry was posted in Design and tagged , , . Bookmark the permalink. Post a comment or leave a trackback: Trackback URL.

2 Comments

  1. Elijen
    Posted February 26, 2013 at 1:32 pm | Permalink

    Helpful article, thanks.

    What about the last step (testing -> production)? git reset –hard HEAD && git pull origin master might not be the best way to deploy on production.

  2. ata
    Posted February 26, 2013 at 2:05 pm | Permalink

    For production I’d suggest logging into the server’s console and update manually. If there would be an error you will spot it immediately.

Post a Comment

Your email is never published nor shared. Required fields are marked *

*
*

You may use these HTML tags and attributes <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>