till's blog

Moving our PHP application into the cloud, means for us that we are leaving FreeBSD for Linux. Not the best move (IMHO), but I shall elaborate on this in a future blog post.

Once we decided on Ubuntu as the Linux of our choice, I started by moving our development server to an instance on Slicehost. Point taken, Slicehost is not the cloud (as in Amazon EC2, Rackspace, Flexiscale or GoGrid) yet, but Linux on Slicehost and Linux on Amazon EC2 will be alike (or so I hope :-)) and a getting a small slice versus getting a small EC2 instance is an economical decision in the end.

Introduction

The following is the start script for my php-cgi processes, which I ported from FreeBSD (I previously blogged about it here).

The advantages of this script are:

1. php-cgi runs on a unix domain socket — no need for tcp/ip on localhost.
2. No need for the infamous spawn-fcgi script, which never worked for me anyway, and on Ubuntu requires you to install lighttpd (if you don't happen to be on Karmic Koala).
3. You can setup different websites with different instances of php-cgi. This is great for virtual hosting, especially on a development server where the different workspaces may have different PHP settings and you want to run versions in parallel without sharing settings and therefore maybe affecting each other.
4. Icing on the cake: we could even add a custom php.ini to the start call for each instance (-c option) to customize it even further.

I'm a big fan of capistrano for my deployment and generally also prefer the command line (vs. nifty web interfaces).

Recently, I realized that it would be better to give up some responsibility to others on a project and it seems the easiest in terms of capistrano is webistrano — by the Berlin-based Peritor.

Gimme a port!

Because FreeBSD is and always will be my favorite operating system, I created a small port for webistrano on FreeBSD. The idea of a port is to have a command to install and remove software, generally, to keep your software installations manageable.

The 1.0 of my webistrano port is already on Github.

Usage

All required steps are listed in the README on Github, but in case you don't have ports on your FreeBSD, please follow these steps (assuming a more or less recent install, FreeBSD 6+):

• Get a port tree and install it to /usr/ports: portsnap fetch extract
• Install GIT: cd /usr/ports/devel/git && make install distclean
• Get the webistrano port:
  • cd (change to your home directory)
  • git clone git://github.com/till/webistrano-freebsd.git
  • cd webistrano-freebsd
  • ...

In case you want to skip on git, just download the webistrano-freebsd tar-ball from github:

• http://github.com/till/webistrano-freebsd/tarball/1.0

What's next?

I've got a small TODO (see README) and want to get that done ASAP, and send in a PR. I'd appreciate some feedback, if you got any.

UPDATE: #136108

Disclaimer: I've been doing mostly PHP and Zend Framework based projects in the past two years, but the information from this article is general and should be applicable to most setups — even to non PHP-based projects (to a certain extent).

Inspired by Padraic's posting spree the other week, here's another attempt to provide you with some hands-on usefulness. I'm all open for all feedback, and sorry for the length!

What is deployment and how do you manage deployments?

Wikipedia says:

Software deployment is all of the activities that make a software system available for use.

... and goes on:

The general deployment process consists of several interrelated activities with possible transitions between them. These activities can occur at the producer site or at the consumer site or both. Because every software system is unique, the precise processes or procedures within each activity can hardly be defined.

In general, there are different approaches to software deployment. Most people are probably not aware of a deployment process at all. They edit files and push it live. In most cases, live (sometimes referred to as production environment) is the webhosting account — for consistency, the environments setup for larger projects also includes a development and staging environment.

Taking the facts into account, we can summarize those efforts into three cases:

1. Deploym..? I'm a skilled surgeon and shell ninja! I like to edit all my files online!
2. I have a local WAMP, MAMP or LAMP and then FTP the files online.
3. We have a defined process and use SVN, PEAR, phing or similar.

Why should I manage deployments?

There are a few reasons as to why it's good for you^TM to come up with a release schedule to manage your deployments.

1. Establishing a release schedule allows you to project the time necessary to implement and test new features and items.
2. Planning in advance also helps to meet the plan.
3. A schedule enables code testing (and other QA measures) before it's live. For example, assuming the schedule says to release a new version every two weeks, the net time (ten business days) could be divided up into eight business days for development, and two business days for testing. (Adjust as needed!) Take note — the schedule excludes weekends!
4. A release schedule helps the development team to avoid all those extra last-minute changes which break things and cause grey hair without feeling bad or guilty. The established practice and process has to be used by all people involved, and developers are not to blame if someone else forgets that.