Here at Facebook, the HipHop team constantly strives to improve the efficiency of PHP execution and increase productivity for our PHP developers. In late 2011 we announced that we were pursuing a just-in-time (JIT) compilation approach called HipHop VM (HHVM) as a successor to the HipHop PHP-to-C++ compiler (HPHPc). The goals of the HHVM project are two-fold: build a production-ready virtual machine that delivers superior performance, and unify our production and development environments.
Below is an update on the state of HipHop VM, followed by a deep dive into some details on HHVM’s architecture and optimization strategies.
How do you keep your development work from interfering with testing new features and providing a stable application to your users? Create a dev to staging to production chain.
You’ve worked for months on a Web application, you launch and all is fine. Now you need to add a new feature that will take you at least a few hours to get right. Do you subject your users to the errors that will intermittently appear if you code directly on the site? No, of course not. You make a completely separate installation that only you’re looking at. When the feature seems solid, push the changes to the production version. You are using a source code repository, aren’t you? So, just perform a svn update on the live site and you’re all good.
This diagram shows the relationship between development, staging and production servers.
Following is the method I’ve found works best for smallish teams working on LAMP Web apps where you can’t afford to introduce bugs to the production version. This method has worked for me on teams of 5-10 coders, each working on different features at once. There’s a balance to be struck between not getting in the way of development work and getting updates out promptly. It’s a drag when you can’t release one feature because its code is all mixed in with another, half-finished feature.
The main idea to have one checkout for your production version, one for a staging and testing version, and multiple servers for various developers and/or projects. Changes that are ready to be tested are checked into the repository. When you want to release, you freeze checkins and test the staging server. When you’re convinced it’s all good, you run an update on the live server and allow checkins again. You’ll want at least three different databases, one each for live, staging and development.
For relatively short-term work, developers should usually check in frequently. For long-term projects, checkins should be held back. Yes, this is what branches are for, and that’s the right choice for more senior coders. In practice, branches don’t seem to be something that the junior members can grok. I might have junior developers working on big changes to copy over many weeks. I simply rely on backups to make sure they don’t lose work in case of disaster.
Here’s a set of steps I might take to set up a new development system.
Create a subversion repository.
Create three virtual hosts: www, stage, and dev.
Create three databases.
Checkout the app once each for www and stage. You’d view these sites as www.example.com and stage.example.com.
Make an open directory for the dev subdomain and make a checkout for each developer. You’d view these sites as dev.example.com/coder1/htdocs. Allow all the dev versions to share a database.
Protect the dev server from the public with basic authentication. You don’t want Web robots indexing everything, and you don’t want to expose scripts that would be outside of the apache webroot in production.
This system will allow you to quickly make a new checkout without hassling with making new subdomains and tweaking the apache config.
