PHP Deployment: Application considerations and process

It's been a while since I've posted anything of any real significance.  Part of that is because I have been working pretty hard on a webinar for Zend regarding deployment.  Deployment is no small subject and testing your deployment options is no small undertaking.  Then add other responsibilities and you end hav…. blah blah blah.

So, I have a lot to write about and with some of the things coming up I don't know how much of what I want to write will be written.  But let's start with the basics.  If you want to see the slides from the webinar here they are for your enjoyment.

Process

The first thing to look at when considering deployment is not to look at deployment.  The first thing you want to do is look at process.  Adherence to process, even bad process, is better than no process at all.  This is because if you have a bad process you at least have some idea of where things are.  If you have no process you have no idea where things are because you have no idea of who did what.

In traditional development/deployment shops there are 4 stages of getting your software from the developer to the production environment.  It's probably one of the few traditions that has mostly stood the test of time in IT, though a lot of people are trying to automate it pretty significantly, speaking about Continuous Deployment.  I haven't personally made up my mind on it yet.  What Continous Deployment is is that if source code checked into your repository passes all of its tests then it is immediately deployed into production.  Sounds nice but one of the things that things like TDD or Selenium do is make repeatable tests.  Having humans in the process means that there will be entropy.  Entropy is good for testing.  But so is predictability.  That's why I'm on the fence about Continuous Deployment.

In terms of the 4 stages, here they are, more or less copied and pasted from my slide deck, because I'm lazy.

• Development
  • Purpose
    • To provide developers an environment to write their code
  • Characteristics
    • Should be similar to production, though it usually isn’t
    • Often more open security
    • Usually local to the developer, though not required
• Testing
  • Purpose
    • To provide a non-programming environment to test functionality
  • Characteristics
    • Continuous Integration could be included
    • Generally no development occurs, only testing
    • Developers should not do the testing, if possible
    • Restricted outbound networking
      • Use Zend Server Monitoring and Code Tracing to help reproduce errors

One of the things that developers are going to be tempted to do is to fix what is wrong in testing.  Instead, even if the developers themselves are testing the app, issues should be registered in an issue tracker so that it can be replicated, opened, closed and checked off the list.

• Staging
  • Purpose
    • To test your deployment process/scripting (not your code)
  • Characteristics
    • Developers generally do not have access, unless they are also the sysadmin
    • Very restricted outbound networking
    • Mirrors production as best as possible

To re-iterate, staging is only about testing to make sure that your deployment process will work when you go to production. If there is a bug it will need to be determined if it is a show stopper or if you can live with it until the next iteration.

• Pre-Production (Optional)
  • Purpose
    • Test the code in the production environment without impacting customers
  • Characteristics
    • Not likely to have use in the cloud or large scale deployments
    • Deployed in production immediately prior to making it live
    • Test the application with production settings without customer interaction

Some additional notes on pre-production.  I really want to highlight me saying that it's optional.  I personally like the ability to put the application somewhere and be able to interact with it prior to making my customers touch it.  That said, it's completely redundant with a properly set up staging environment.

• Production
  • Purpose
    • Do whatever it is that it’s supposed to be doing
  • Characteristics
    • Developers do not have access (as they might be tempted to fix something)
    • Deployment should be done without requiring developer input
    • Very limited inbound traffic – generally only the service that is being served. i.e. HTTP

Application Considerations

Having looked, quite briefly, at the process we need to look at the application.  Again, briefly.  Since we've already talked about the process I would like to show you how you should make your application aware of the different environments.

One of the things that developers have sometimes done is hard coded their environment logic into their application.  So something like this:

$env = 'production';
if (substr($_SERVER['HTTP_HOST'], -6) == '.local') {
    $env = 'development';
} else if (substr($_SERVER['HTTP_HOST'], -8) == '.testing') {
    $env = 'testing';
}
define('APPLICATION_ENV', $env);

or even worse

if (strpos(__FILE__, '/home/kevin') === 0) {
    $env = 'development';
} else if (strpos(__FILE__, '/home/bob') === 0) {
    $env = 'development';
} else {
    $env = 'production';
}
define('APPLICATION_ENV', $env);

One of the problems with the second one is that you need to modify your code to have someone else work on it, or when someone else leaves the company.  The problem with the first one is that you can't always trust $_SERVER['HTTP_HOST'].  Plus what if you have to change your domain name for some reason.  Then you have to refactor.

What you can trust is your server configuration.  Usually.  So in my httpd.conf file I put the following line.

SetEnv APPLICATION_ENV testing

And then in my application

define('APPLICATION_ENV', (getenv('APPLICATION_ENV'));

The reason I like this is because rather than having the application guess which environment it's supposed to be in, the web server tells it which environment it's supposed to be in.

Well, that's it for now.  In the webinar there were 4 different types of deployment options I looked at, which we will cover in the upcoming days.  So I have plenty more to write about but I'm hungry.  Later all.