The DevOps Approach to Updating PHP

Regularly updating PHP can be time-consuming, but ultimately it needs to be prioritized. There are strategies, however, that companies can lean on to make the PHP update process faster and more streamlined. One of those ways is through applying a DevOps approach to updating PHP.

In this blog, we walk through the basics of PHP updates, with background on the PHP release cadence and the benefits of frequent PHP version upgrades, followed by details on the DevOps methodology and how it can apply to PHP updates. Lastly, we talk through how companies that aren't DevOps ready can make strides toward more efficient and more frequent PHP updates.

Can a DevOps Methodology Apply to PHP Updates?

Having a safe, repetitive and streamlined deployment procedure is the ultimate objective when envisioning applications deployment. PHP engine updates must be part of such procedural approach, as an integral part of an application lifecycle (for security and performance reasons).

While the golden ideal of a fully-automated CI/CD pipeline that can perform PHP updates without incident is a distant dream for companies deploying complex PHP applications, building the foundational elements of that approach — making the update process documented, repeatable, and streamlined — can lead to much better, and scalable, outcomes.

PHP Release Cadence

The first thing to consider in applying a DevOps mindset to PHP updates is that PHP moves fast, but predictably.  

Community PHP follows a rigid process in terms of releases, with each release branch of PHP (e.g. 8.2 or 7.4) fully supported for two years from its initial stable release.  During this period, bugs and security issues that have been reported are fixed and are released in regular point releases. 

After a two years period of active support, each branch is then supported for an additional year for critical security issues only. Releases during this period are made on an as-needed basis: there may be multiple point releases, or none, depending on the number of reports. Once the three years of support are completed, the branch reaches its end of life and is no longer supported.

Extending the PHP Release Cadence With PHP

Zend LTS program will extend the security support of a PHP branch for an additional 3 years (at least). For example PHP 7.4, which reached end of life in Nov 22, will be supported by Zend until the end of 2026.

 

See LTS Options

Patches and Minor Updates

You may ask yourself now ‘why do I see a third and sometimes a fourth number like 7.4.33-7’ in my ‘phpinfo’ output? 

The third number, usually referred as the point release, indicates the number of patches applied to a PHP branch. Typically PHP only adds new features to major and minor releases, and fixes bugs in point releases. The fourth number will show only when using Zend LTS products, it indicates the number of security fixes released by Zend since a specific version of PHP was declared EOL (see more in our PHP Security Center).

The Benefits of Frequent PHP Version Upgrades

There are obvious benefits in regularly updating PHP versions of the engine gearing your critical applications. Here are the most important ones (in order of importance):

1. Security - Guarantee that your PHP is fully supported and regularly updated for security threats.
2. Performance - Every major or minor PHP release introduce performance enhancements. 
3. DX – Important new features are introduced in every major or minor release to improve the language solidity and productivity when developing code.

There are compelling reasons to have PHP upgraded with every minor release; unfortunately it is not an easy process — especially from a project management perspective.

In order to be always on the latest version of PHP, a company needs to factor in migration cycles every couple of years, as PHP usually introduces backward incompatibilities and default configurations changes that may break applications.

For critical (often large) applications, focusing on a fast-paced release of new features, with a suboptimal testing safety net, the risk of decreasing the overall stability and robustness of the final product is extremely high.

Updating PHP With CI/CD Pipelines

As mentioned above, the process of constantly updating PHP requires a lot of effort with very little value for an application’s end user. The end benefits, though, are too important from a business perspective — the application lifecycle simply must include it.

A methodology that drastically help minimizing the risks of introducing such a process is CI/CD. Continuous Integration (CI) is the practice of automating the build and testing of code every time a change is made — and committing that code back to a central repository. 

A process like migrating code to the latest PHP version, being a very fuzzy and unstructured one (find deprecations and incompatibilities across a project with no logical connection), can truly succeed only when such code modifications are thoroughly tested as soon as they are made.

Pipelines can be created for any type of application, but their complexity and effectiveness are heavily conditioned by the application’s architecture. The prerequisites for successful CI/CD pipelines have been synthesized in an architecture called the ‘12 factor application’.

It is a triangulation on ideal practices for app development, paying particular attention to the dynamics of the organic growth of an app over time, the dynamics of collaboration between developers working on the app’s codebase, and avoiding the cost of software erosion.

In terms of tooling, the open source software ecosystem offers myriad solutions; our suggestion is to choose the one that best suits your internal knowledge and developer experience.

The five core requirements of a CI system are the ability to automatically: 

1. Detect code that has been committed either by monitoring the repository for commits or accepting some external stimulus, usually from the source code repository. 
2. Checkout code from the repository onto a machine equipped with all the necessary build and testing tools available. 
3. Build the code. 
4. Run all the tests on the resulting build(s). 
5. Report the results of the build and test to the appropriate team member(s). 

CD is used once changes are committed and tested. The ultimate aim of CD is to always have validated and verified build(s) in a release repository — or version control system — ready for production use. 

In order to achieve all the above requirements, the simplest approach is using containerized workloads. These containerized workloads allow for the necessary agility and are simple to place in any repository your processes dictate. With containerized applications, it is very simple to be on the latest PHP version as the base images are available from the community and from Zend products in our proprietary ‘container registry’.

Embracing the DevOps Mindset for PHP Updates for Non-Container Based Applications

Unfortunately the software world is full of legacy applications, which are difficult to re-architect or even adept in order to implement all the methodologies above described. There are still several things that can be done though to ease to burden of keeping the engine running an application updated, secure and performant.

We’ll try to emphasize these things below, both from the project management and the engineering perspectives.

Ensure Complete Test Coverage

Strive to have your testing suit in the best condition possible, possibly reaching the 100% coverage.
Unit testing, mutation testing and behavioral testing should be present (can be done in parallel), with the latter being the most important one.

Coding your testing elements resides in the engineering realm, but also pertains to the PM realm (developing the testing code must be factored in), to the point pure PM practices like TDD (test driven development) can be adopted.

Perform Regular Engine Upgrades

Document and prioritize regular code migrations in order to be on the safest version of PHP consistently, as part of the application lifecycle. Ultimately, the company leadership needs to understand the consequences of running end of life software in production.

This is mostly a product management exercise, backed up via the engineering practices noted in the previous point. It requires a safety net that allows unstructured and fuzzy code modifications to be assessed as close as possible to the developer implementing them.

Create a Software Bill of Materials

As soon as possible in the process, create a Software Bill of Materials reflecting everything your application depends on. It is quite unpredictable to foresee what will go wrong with an upgrade/migration, especially if your code depends on third party libraries and their ability to be migrated to the latest version of the engine.

Having a secure engine does not mean your entire application stack is secure, all dependencies must be scanned and kept updated.

Final Thoughts

While the golden path of automatically testing and deploying PHP updates might not be possible for most companies, there are certainly ways in which teams can and should apply a DevOps mindset to update PHP. And, as noted above, keeping PHP updated to the latest version can bring a variety of benefits.

However, for companies with complex, mission-critical PHP-based applications, upgrading to the latest minor version might not be realistic. Even then, applying full-coverage, automated testing can help to dramatically speed up the deployment process when upgrading. Even for teams with monolithic applications, there are ways to make updating PHP a less painful process, but it will take some work to get there.

The good news is that, no matter where you're at in your DevOps journey, there are companies like Zend that can help.

Explore Zend PHP LTS and Professional Service Options

From LTS, to modernization and migration services, Zend can help take your PHP-based applications to the next level. Learn more about our LTS and professional services options below.

See LTS OptionsExplore Professional Services

Additional Resources

• White Paper - Planning Your Next PHP Migration
• Resource Collection - PHP Version Comparisons
• White Paper - The Costs of Building PHP In-House
• White Paper - The Hidden Costs of PHP Upgrades
• Solution - Zend PHP Migration Services
• Solution - Zend PHP Consulting Services
• Blog - The Importance of Easy-To-Use PHP Linux Images
• Blog - Everything You Need to Know About Maintaining PHP Compliance
• Blog - Using Containers to Improve PHP Application Security
• Blog - Building a Modern Web Application: Top Architectures and Methodologies
• Case Study - Zend Performs Bark.com PHP Migration