PHP is today the world’s most popular open source web development language. It is used by millions of websites, most often via applications like WordPress and Drupal. Deploying a PHP website is straightforward and supported by nearly every web hosting provider.
There are limits to how much load a single web server can take though. For your website to scale, you will sooner or later need to a transition to a multi-server deployment, and this can be hard. It requires thinking about web development in entirely new ways.
The exciting new world of cloud computing promises to make all this much better. “Cloud computing” is an umbrella term for a range of tools and techniques that make scalability possible. Scaling PHP in the Cloud is a one day conference on what it takes to make the leap from single server to multi-server deployments, and of making sense of the new world beyond.
Sessions are for 45 minutes each (30 talking + 15 Q&A). If you’d like to do a smaller session, please indicate so in the description.
To attend this event, buy your ticket from http://phpcloud.doattend.com/
On the benefits of using
Git or other version control software to deploy software, instead of traditional
This is a brief discussion (~15 minutes) on using Git, Mercurial or other distributed version control software to deploy software to servers. It works when you have one or two servers and rapid iterations.
Traditionally, software is deployed by simply copying it to the server over FTP or SFTP. More clued-in developers use rsync for its ability to update only changed files. There are two problems with this approach:
No version control for deployments. You may have versioning in your development environment, but you’re missing it in your deployment. It’s not easy to roll back if something breaks.
You have to separate your development configuration files from your production configuration files. You could accidentally overwrite production config with development config, breaking the site.
Distributed version control systems provide a better way to manage deployments. They already understand how to ignore certain files (specified in
.hgignore) an allow committing a change and pushing it to a remote location that isn’t necessarily the central repository. You can commit a change and push it to a test server. On the production server, you can pull changes from the repository and Git/Mercurial will automatically ensure that config files are not clobbered.
This approach is trivial to setup and makes for much peace of mind when deploying rapid iterations.
During the session I’ll present on how I manage my deployments and then we’ll discuss how you do yours.