Jump to content

Best environments to debug a PHP, and it doesn't have to be the best for developing an app.


IT_Architect
 Share

Recommended Posts

Situation:  A very large app that barely made the transition to PHP 5.3 and the change to POSIX that is loaded with REGEX.  I'm not that familiar with its code.  It looks like the original author was had excellent skills but a lot of people have worked on it over the years so data access methods vary from ADO to MySQL to MySQLi.  I have it currently running very well on UNIX/FreeBSD 11.2, Apache 2.4, PHP 5.3 FPM, and MySQL 5.6.

Mission:  Move the app to Apache 2.4, PHP 8 FPM, and MySQL 8, and Linux.  This is a perfect time to me evaluate after some years whether Linux has evolved to the point where it is capable of handling the loads which in the past it has not.  Linux is the Windows of the web server world, and can do a better desktop when required than FreeBSD, which enables it to be more developer-friendly which plays out in development tools and expertise, and where people throw code at.  If Linux turns out to not be there yet, moving it to a new FreeBSD 13 VM would be trivial.

Resources:  I have high-end bare metal servers in SoftLayer data centers where I install and maintain our own ESXi infrastructure and have been 100% virtual since 2008 with about every OS.  Like everyone else, I assumed CENTOS would forever be the Windows of the web server world, but as we've seen, that all changed in one day.  So I've spun up what I determined to be the solidest heir-apparent at this time, AlmaLinux, with Apache 2.4, PHP 8 FPM, MySQL 8, no GUI, and the DirectAdmin control panel.  However, I'll do what makes the most sense.  If you say for this transition, spin up Window 10 VM, I'll do that.  The key thing is it needs to be in a data center where I have a public interface because there are services from around the world where their license is tied to the IPs. 

As for me personally, I may be the most technical person you could ever meet, have been tapped to work for people whose names you might recognize, and been featured in nation-wide publications.  I've been the CTO for two different Tier-1 automotive suppliers and wrote their ERP systems, which included their EDI, SPC, and designed and built the electronics for automation.  I've written drivers, compilers, debuggers, and RDBMSs.  The last IDE I worked in was 10 years ago, PHPEd by NuSphere, but it isn't buzzword today.  It has server modules so I can run and trace code on a server from Windows remotely.  While I help developers with PHP off and on, it is not my job and I would guess that I can't hold a candle to most of the people here.

What I'm asking from you is your opinion on the best current strategies from for hardware and software perspective to make this update go as efficiently as possible.  Problem number one will be I will be dropping it into an environment where there will be hundreds of reasons why it is not working, and finding out where those places are.  Problem number two will come after they are identified, I will be able to fix them, but what is also needed is something with the intelligence to tell me what I'm doing will slated to disappear from PHP at some point in the future and recommend a better way, as well as critique code already present that may fall into that category.

Thanks!

Link to comment
Share on other sites

You'll need a local environment for testing that is identical to the live environment. If it's running on "Linux", which is far more capable than you seem to think it is, then that's what you should have too.

Learn the codebase inside and out, then check the PHP migration guides for 5.3 -> 5.4 -> 5.5 -> 5.6 -> 7.0 -> 7.1 -> 7.2 -> 7.3 -> 8.0, since that's where you're starting and where you're going. There have been a lot of changes over the few years and you're lagging behind by a lot. Decide what is obviously relevant and address it now.

Make sure that your PHP reports everything wrong. E_ALL is not everything but the things you should commonly care about. Set error_reporting to -1 and make sure nothing reverts that, then double-check you have errors being logged as they need to be.

Deploy the application locally and see what happens. However long it took you to get to this point, take at least that much more time with testing.

Link to comment
Share on other sites

  • 2 weeks later...

The biggest changes in the PHP world:

  • Additions to the PHP language
  • Deprecation of MySQL_
  • Addition of namespaces and PSR-1/Now PSR-4 
  • Creation of Composer and packagist
  • Ascension of git to standard (Github, Bitbucket, Gitlab)
  • Big 2 MVC frameworks (Symfony/Laravel)
  • Vast improvement and adoption of Component libraries, installed via composer
  • Explosion of cloud computing/hosting

The biggest changes to methodology:

  • Move to using Docker & Docker-compose for development
  • Use of Git

For editors, most pro developers are using phpStorm.  It's the best PHP IDE, and the one you most commonly see being used.  Visual Studio Code is pretty competent, and is free.  There are a few PHP extensions that make it quite competitive to phpStorm, but you have to do some work in getting it setup.  Both editors have great support for docker and git, although I tend to be a cli person, and feel more comfortable having a terminal open and multiple displays.  They both have integrated terminals and you can basically stay in the IDE window 99% of the time, when iterating. 

As a long time user/early adopter of virtualization (Xen, Virtuozzo, VMware, Parallels, Virtualbox, Vagrant)  I have used nearly all the virtualization and development orchestration options at one time or another,  but at this point, Containers have proven to be superior for development, when compared to full OS virtualization, and have become the primary platform for deployment at scale.    

Given your stack requirements, Docker is a great solution, because you can easily iterate through the various versions and combinations of the stack under Docker, without having to build full virtualized OS's or install any packages.  Just use the Official Docker images for PHP and MySQL.   The PHP container already has versions of apache, simplifying your setup. 

Git is a great facilitator for an upward migration process, as you can make a new branch each time you go up a PHP version, fixing things you need to fix as you go, and allowing you to switch back and forth between branches or have multiple git clones where you could conceivably be running an older version of the app against an older stack, while simultaneously running a newer version that is in the development process. 

For getting bootstrapped into Docker, there are projects like Devilbox, Laradock, or even my relatively new project docker4lamp.  These can all provide a basis for you to get comfortable with Docker and how to orchestrate containers together.  I'd promote Docker4lamp more in terms of its stack matching your target, but the purpose of the project is to have a latest/greatest stack for someone relatively new, but with a solution to all the various problems that new developers confront at some point.  Being far simpler in scope than either devilbox or laradock, it might be easier to learn from, as you may want to have your own docker images and docker-compose added to your source.  Needless to say there is an incredible amount of information you can find to help you jumpstart your understanding and use of Docker.  Of the 2 "kitchen sink" packages I mentioned, probably laradock (which despite the name, will give you a complete set of containers to work with) is going to be easier to get up and running with.  Quality documentation exists for both projects.

Once you have done all the porting work you need to do, you can decide if you want to deploy onto an OS with packages as you have been in the past, or use Docker in production under Kubernetes or docker-compose on linux.   I also have been a longtime Centos user, and recently setup a hosted vps under Alma.  The main thing I learned is that you want to use dnf and not yum, but otherwise it looks like Centos.  I will say that for a long time, the Centos official packages had to be worked around, and people were using epel and remi to get anything close to current.  It's really a pain, and yet another reason to consider just running containers instead.  

For a reverse proxy, one relatively recent option that has emerged is traefik.  It's a really nice option, and far less complex to get going than nginx or squid or ha.

With that said, usually scalability involves substantial architectural decisions and the avoidance of building in things that require a monolithic infrastructure.  Step 1 would be getting your app current to a supported version of PHP.  You might also want to upgrade your MySQL version to something fresher.  Step 2. would be looking at performance/scalability, if there are any significant issues.   Full disclosure, most of the projects I've worked on in the last 10 years have been deployed within AWS.

 

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.