migration concepts for enterprise php applications

Migration concepts for enterprise PHP applications

International PHP Conference 2008 – Spring EditionThorsten Rinne

© MAYFLOWER GmbH 2008 2

„Migration concepts for enterprisePHP applications“

Introduction

❙ Thorsten Rinne

❙ 31 years old

❙ Graduated in computer science

❙ Project manager at Mayflower GmbH, Munich

❙ Reporting applications

❙ Critical bank applications

❙ PHP Consulting

❙ PHP software development since 1999

❙ Founder and main developer of Open Source FAQ-management software phpMyFAQ since 2001

❙ Zend Certified Engineer (PHP 5)



Summary

❙ Introduction

❙ Why upgrade?

❙ Process model

❙ MySQL upgrade process

❙ PHP upgrade process

❙ Migration

❙ Conclusion

❙ Questions and answers



Introduction: Why upgrade?

❙ MySQL 4 support will end

❙ Active support already ended by the end of 2006

❙ Only extended support until 2008 for MySQL 4.0 and 2009 for MySQL 4.1

❙ MySQL 5 has more and advanced features like storedprocedures, trigger, better SQL support

❙ PHP 4 support will end

❙ PHP 4 is dead, dead, dead

❙ Only security relevant fixes until 2008-08-08

❙ PHP 5.2 is faster and more stable than every PHP 4 version



Introduction: Requirements

❙ No qualitative changes like new features

❙ No technical changes like

❙ new database layer

❙ new template engine

❙ Using new PHP 5 features

❙ No influences for productive services like

❙ External systems

❙ End user frontends

❙ Minimization of time and effort



Introduction: What is porting?

❙ Reasons

❙ Most simple form of migration

❙ Manageble risks

❙ Small complexity because of the lack of qualitive and technical changes

❙ Requirement

❙ Minor differences betweencurrent and futureapplication platform

Rewrite

Reengineering

Porting

complexity

Innovation potential

posit

ive

nega

tive



Process model

❙ Reducing of complexity with a planned procedure

❙ Coverage of the complete porting

❙ Methodical description of the process

❙ Tool support



Process model: Preparations

❙ Targets

❙ Porting without any technical or qualitative changes

❙ Recovery of support (MySQL/PHP)

❙ Minimizing the interferences of services and reductionof change times

❙ Interferences

❙ Porting problems between MySQL and PHP versions

❙ Application complexity

❙ missing documentation and missing contact persons

❙ Communication between all team members



Process modell: Upgrading MySQL

❙ Upgrade in two steps❙ MySQL 4.0 to MySQL 4.1❙ MySQL 4.1 to MySQL 5.0

❙ Why two steps?❙ Big changes between 4.0 and 4.1❙ Password changes❙ Character sets❙ Collations❙ Many minor BC breaks



Upgrade path for MySQL

❙ First dump your current database, if it‘s InnoDB. If you useMyISAM, just backup everything.

❙ upgrade your development machine

❙ Reload your tables

❙ Test, test, test with MySQL 5.0

❙ Fix your queries and application if you have problems

❙ Use the STRICT MODE in MySQL 5.0

❙ Test, test, test with MySQL 5.0

❙ Upgrade your production machine

❙ Reload your production database



How to dump MySQL?

❙ Use the MySQL 4.1 mysqldump binary!shell> mysqldump –uroot -p

–-database mydatabase--single-transaction--default-character-set=utf-8--disable-keys--extended-insert| bzip2 –c > backup.sql.bz2

Warning: This can lock all tables!

❙ Fix the password column in the MySQL user tableshell> mysql_fix_privilege_tables

--password=root_password



MySQL Pitfalls

❙ Rebuild your TIMESTAMPs, check this also in your application

❙ TIMESTAMP now has the format'YYYY-MM-DD HH:MM:SS'

❙ DECIMAL(14,2) in MySQL 4.0 is not the same as DECIMAL(14,2) in MySQL 4.1/5.0

❙ using DECIMAL(10,5): 100000 will be 99999.99999

❙ using DECIMAL(11,5): 100000 will be 100000.00000

❙ New reserved words

❙ SQL2003 standard for your SQL queries with natural JOINsand JOINs with USING may produce different results

❙ http://dev.mysql.com/doc/refman/5.0/en/upgrading-from-4-1.html



After MySQL upgrade

❙ Release the current combination

❙ PHP 4 / MySQL 5

❙ Why?

❙ You never find all problems during your tests

❙ PHP porting may took longer than the MySQL porting

❙ Increase your experience with MySQL 5

❙ Prepare the PHP 5 update



Process model: Upgrading PHP

❙ Which PHP version?

❙ Latest PHP 5.2 release for production, if you build byyourself or current PHP 5.2 package from yourLinux/Unix/*BSD/Solaris distribution

❙ Testing with PHP 5.3-dev if you have time and money

❙ Please don‘t use

❙ PHP 5.0.x

❙ PHP 5.1.x

❙ PHP 6.0.0-dev



Upgrade path for PHP

❙ upgrade your development machine to latest PHP 5.2 release

❙ Test, test, test

❙ Fix your code if you have problems

❙ register_globals = off

❙ error_reporting = E_ALL & E_STRICT

❙ display_errors = on

❙ log_errors = on

❙ Test, test, test

❙ Upgrade your production machine

❙ Release your ported application



Migrate configuration files

❙ httpd.conf

❙ change this line:LoadModule php4_module php/sapi/php4apache2.dll

❙ with this one:LoadModule php5_module /php/php5apache2.dll

❙ php.ini

❙ You should use the php.ini-recommended file, but check, ifyou need magic quotes on…. Otherwise your application couldbe insecure!



PHP 5 Pitfalls:New reserved keyords

❙ abstract

❙ catch

❙ clone

❙ extends

❙ final

❙ implements

❙ instanceof

❙ interface

❙ goto

❙ private

❙ protected

❙ public

❙ throw

❙ try

❙ use

❙ namespace



PHP 5 PitfallsConstructor / Destructor

❙ PHP 4

❙ construct method has the name of the class

❙ No destruct method

❙ PHP 5

❙ construct method: __construct()

❙ If not available, fallback to PHP4 handling

❙ destruct method: __destruct()

❙ Executed at the end of the request



PHP 5 PitfallsMagic methods

❙ __autoload()

❙ __call(), __callStatic() (only PHP 5.3)

❙ __construct()

❙ __destruct()

❙ __get()

❙ __isset()

❙ __set()

❙ __set_state()

❙ __sleep()

❙ __toString()

❙ __unset()

❙ __wakeup()



PHP 5 Pitfalls

❙ get_class(), get_parent_class() and get_class_methods() now case-sensitive

❙ __CLASS__, __METHOD__, and __FUNCTION__ are also case-sensitive

❙ Objects are referenced by handle, and not by value

❙ Objects aren’t primitive types like in PHP 4

❙ If you need a copy of a object, use __clone()

❙ Re-declaration of $this isn’t allowed anymore

❙ === operator is more strict than it was in PHP 4

❙ __call()/__set()/__get() are different in PHP 4

❙ Don’t use zend.ze1.compatibility_mode!

❙ Use instanceof instead of is_a()



Migration strategies

❙ After the release of the PHP 5 ported applicationREFACTORING!

❙ Strategies for

❙ „Spaghetti code“

❙ Half procedural – half object-orientated

❙ PHP 4 OOP

❙ Please don‘t try a complete rewrite

❙ Too expensive

❙ Takes too long

❙ Joel on software: „Things You Should Never Do “



Migration„Spaghetti Code“

❙ Very old code, maybe developed in the last PHP 3 century

❙ No or just minor separation of code and layout

❙ No use of libraries like PEAR, Zend Framework or eZcomponents

❙ No documentation

❙ No tests



Migration„Spaghetti Code“: Strategy

❙ Identify recurring code parts and implement classes

❙ Use of standard libraries like Zend Framework, eZcomponents or PEAR

❙ Add inline documentation

❙ Fix your coding styles

❙ Add unittests for the new, refactored backend

❙ Add Selenium tests for the frontend



Migration„Half procedual – halb object-orientated“

❙ Code with differend quality

❙ Just a few documentation

❙ Maybe some tests

❙ „the typical current PHP 4 project“ ☺



Migration„ Half procedual – halb object-orientated“: Strategy

❙ Add inline documentation for all classes and methods

❙ Improve the re-using of duplicate code

❙ Add unittests and Selenium tests

❙ Improve every code part with PHP 5 functions, for exampleusing file_put_contents() instead of fopen(), fwrite(), and fclose().



MigrationPHP 4 OOP

❙ Application was developed object-orientated in PHP 4

❙ Using of

❙ PHP 4 references

❙ Re-declaration of $this



MigrationPHP 4 OOP: Strategy

❙ Maybe you‘re lucky and there are no problems. Maybe.

❙ If you see problems, they are fatal errors like

❙ Objects are referenced by value

❙ $foo =& new Foo();

❙ Solution:

❙ Implement unittests

❙ Use standard APIs

❙ Fix the PHP 5 problems



Conclusion

❙ Migration is always possible

❙ Migration can be hard, but usually it isn‘t! ☺

❙ Don‘t shoot yourself in the foot with the migration

❙ First upgrade MySQL

❙ Then upgrade PHP and fix your application

❙ Then do the cleanup for a better future ☺

❙ Stay current in the future and do always small steps

❙ Keep PHP 5.3 and PHP 5.4 in mind!



Questions and answers

Thank you very much!

Thorsten Rinne, Dipl.-Inf. (FH)Mayflower GmbHMannhardtstraße 6D-80538 MünchenGermany+49 (89) 24 20 54 – [email protected]

migration concepts for enterprise php applications

Technology

new php

steps mysql

better sql support php

effort migration concepts

answersmigration concepts

versionmigration concepts

zend certified engineer

process modell