No matter how hard you try to test your PHP applications before putting them in production, you will always ship code to your server that has bugs.
Some of those bugs will be very serious and need to be fixed before they cause greater damages to your application data that may be too hard to recover.
Contents
1. Test as Much as Possible Before in your Development Environment
2. Test in a Staging server Before you Send it to the Production Server
3. Separate your Code from Environment Configuration files
1. Test as Much as Possible Before in your Development Environment
This one should be obvious but it is amazing how many PHP developers do not do it.
The worst case is of those developers that do not use a development environment at all for their PHP applications. If you are not sure what is a development environment, that is your case.
A development environment is a setup that you should have in your local computer on which you do your PHP development as if you were in your production environment.
The development environment should be as much as possible like the production server. So you should run the same Web server and if possible the same operational system.
If there are differences between your development and production environments, these differences may cover bugs in your application that only show up in the production server.
In the ideal world you should have test scripts that test every aspect of your application. However, in the real world it is very hard or even impossible to test everything.
Furthermore, elaborating tests for all your code makes your development take much more time to finish. A good compromise is to elaborate tests for those 20% of your code that are responsible for the 80% of the features that cannot fail.
Anyway, regardless how much you test your code, there will always exist bugs in your code that will slip into production. This is why you need to add more safeguards to your development and deployment practices like those that follow.
2. Test in a Staging server Before you Send it to the Production Server
If your development environment cannot be similar enough to your production server, you can create a staging environment that is more similar to your production server.
A staging environment is often separate machine that replicates the production server but it runs on its own database and its own domain.
If you cannot afford setting up a separate machine, you may try creating a staging environment on the same machine as the production server, as long as it runs on the separate database and domain.
You may deploy your application updates to your production server only after you have tested your application in the staging environment . Chances are that you may have caught some bugs in your staging environment, so less bugs will ship in the version deployed in the production environment.
3. Separate your Code from Environment Configuration files
Having multiple environments to test your application is great but you may wonder, how will my application know in which environment it is running and how do I deal with different databases and site host names?
Those details that may be different in each environment should be defined in configuration files. One practical way to implement this is to create a configuration class for your application. It should have variables that define the values that vary from environment to environment.
class configuration
{
/*
* store error messages in case an error happens
*/
public $error = ”;
/*
* Path of the main application relative to the current directory
*/
public $application_path = ‘.’;
/*
* Host name of the site to compose absolute URLs
*/
public $host = ‘www.mysite.com’;
/*
* name of the site database
*/
public $database_name = ‘production-database’;
/*
* name of the account to access the database
*/
public $database_user = ”;
/*
* password of the account to access the database
*/
public $database_password = ”;
/*
* Initialize the configuration loading options from a local script
*/
function Initialize()
{
$local_options = $this >application_path .
‘/configuration/local_options.php’;
if(!file_exists($local_options))
{
$this->error = ‘the application configuration file ‘.
$local_options.’does not exist’;
return false;
}
require($local_options);
return true
}
function Fail()
{
error_log(‘Error: ‘.$this->error);
exit;
}
};
Your application scripts may start like this. They will make the configuration class load option values from a script named configuration/local.php that is inside your application directory.
$options = new configuration;
/*
* Adjust the application path relative to the current script directory
*/
$options->application_path = ‘.’;
if(!$options->Initialize())
$options->Fail();
Now you can define different scripts for each of the environments (development, staging or production) setting the application options accordingly.
The configuration script path should be configuration/local.php . Each environment should have a different configuration script, which should look like this:
$this->host = ‘www.mysite.com’;
$this->database_host = ‘some database host’;
$this->database_name = ‘some database name’;
$this->database_user = ‘some database user’;
$this->database_password = ‘some database password’;
Source from http://www.phpclasses.org