Maintenance and support

The final part of the application lifecycle is to provide maintenance and support for the product you just created, which may take the form of continuing development by way of producing patches and updates, but also includes providing technical support for users.

Thanks to the fact that PHP is executed uncompiled, unlike other languages such as C++ and Java, altering functionality after you have deployed your solution is generally just a case of replacing the files that have been updated. However, there are two particular cases you need to be aware of when planning your maintenance: file versioning and forward compatibility.

By "file versioning" I mean that you need to take into account the fact that no matter how idiot-proof you make your maintenance solution, the universe is hard at work designing better idiots! Because PHP allows old, potentially buggy files to be updated with newer files simply by replacing them wholesale, you may get in the situation where a user has an inconsistent installation - they have installed file_a.php v1.1, the patched version, but not file_b.php v1.1, which may render their deployment broken because it is possible that file_b.php v1.0 does not include a new function or the like.

The way to work around this is to make sure that you include version numbers in each file, then have that version checked wherever appropriate in your code. Generally speaking you do not need to use version numbers like v1.1, as these are computationally expensive to check in code.

A better way is to use YYYYMMDDBBB as your version number, that is a four-digit number for the year, a two-digit number for the month, a two-digit number for the day, and a three-digit build number that you can increment each time you produce a new code build for that day. Using this method you can, for example, make file_a.php check that file_b.php's version number is greater than or equal to 20040108009, which would be equal to "the ninth build made on the eighth of January 2004"

When it comes to handling technical support queries from your end users, you have two options: outputting specific errors to the screen, or creating a log file and writing information to that when there is a problem, and asking users with problems to mail that fail to your support team for inspection. The first solution is generally preferred by most programmers, however the second solution is actually a great deal better for reasons I shall explain.

While it might make sense to display errors as and when they happen, you need to be very careful about how much information you give away - give away too little and the error report is useless, but give away too much and you are simply making the job of hackers a great deal easier. On the other hand, if you write error information out to a log file you can be as detailed as you want without running the risk of it getting into the wrong hands. Furthermore, for the purposes of support, the file can simply be sent across to your support team and will automatically contain a list of all errors the application has encountered, which allows you to track previous instances of the error as well as any other potential errors out there.

Copyright ©2015 Paul Hudson. Follow me: @twostraws.