Feedback on Best Practice for Deploying Software Patches
Posted: Tue Mar 27, 2007 2:18 pm
Do you know the applications SugarCRM/OpenCRM, vTiger, vBulletin, and phpBB? If you were to write a software application like that, where it is intended that you would customize it by changing the PHP, what do you think is the best practice for deploying software patches to it?
For instance, this year or next, I plan to release a kind of mini-CRM product, FOSS-based. However, as I work out all the business plans, I'm trying to think up what is the best software patch deployment model when my patches, if rolled out, could overwrite developer-customized PHP code.
What would you do in my shoes?
I will have these kinds of patches to roll out:
* Critical security patches -- both on the new release and at least on the last 3 major and minor version releases.
* Critical business rules patches -- new releases + last 3 releases. This is for break/fix situations.
* Code improvements/enhancements -- on the latest stable and unstable release, only.
* Minor security improvements -- on the latest stable and unstable release only.
* Minor business rule patches -- on the latest stable and unstable release only.
I could, for instance, release these updates two ways. One way is blindly, where I imagine that the customer has not customized the PHP. This could be of great use to them so that they could run a DIFF and find out what's different, then consider the change. The other could be a DIFF report showing them what code changes were made so that they could consider it.
Luckily I was smart from the get-go and used a fairly OOP design. All database calls are funneled through a DB class. All page display calls (well, mostly all) are funneled through a Page class. And so on. The only thing left are the business rule pages that call all the class objects to do the work. What this affords me in this kind of coding is the power to offer an update to the DB class without having a major impact on a customized application.
I'm hoping that you can share your opinion. It would help me a lot.
For instance, this year or next, I plan to release a kind of mini-CRM product, FOSS-based. However, as I work out all the business plans, I'm trying to think up what is the best software patch deployment model when my patches, if rolled out, could overwrite developer-customized PHP code.
What would you do in my shoes?
I will have these kinds of patches to roll out:
* Critical security patches -- both on the new release and at least on the last 3 major and minor version releases.
* Critical business rules patches -- new releases + last 3 releases. This is for break/fix situations.
* Code improvements/enhancements -- on the latest stable and unstable release, only.
* Minor security improvements -- on the latest stable and unstable release only.
* Minor business rule patches -- on the latest stable and unstable release only.
I could, for instance, release these updates two ways. One way is blindly, where I imagine that the customer has not customized the PHP. This could be of great use to them so that they could run a DIFF and find out what's different, then consider the change. The other could be a DIFF report showing them what code changes were made so that they could consider it.
Luckily I was smart from the get-go and used a fairly OOP design. All database calls are funneled through a DB class. All page display calls (well, mostly all) are funneled through a Page class. And so on. The only thing left are the business rule pages that call all the class objects to do the work. What this affords me in this kind of coding is the power to offer an update to the DB class without having a major impact on a customized application.
I'm hoping that you can share your opinion. It would help me a lot.