// customer case study - PHP upgrades

Modernizing a legacy PHP application

Latent security vulnerabilities and ISO27001 compliance were looming over a legacy PHP application that was that was providing customers with a valuable service. How do you employ AI to help maintain mission critical legacy software without burdening senior engineers with overly large code reviews or contributions that miss compliance targets?

Objectives

  • Security resilience Full compliance with industry cyber security standards for security patches and use of actively maintained and supported dependencies means the organization is more resilient and agile in face of the increasing pressure of the cyber security landscape.
  • Senior engineer focus Reduced burden on senior engineers means the team has greater focus on the core product, new features and customer satisfaction.

Background

Around a decade ago a business intelligence company decided to move the core of their service stack from PHP to Go. Being pragmatic they did not port their entire product at once, but with the lessons from their original product built the most important features into a new architecture. This operation was a great success and in the decade that followed the Go codebase became the majority of their service and focus of the development teams.

A smaller but not insignificant amount of customers however are still using the long tail of features in the PHP service. That means a small number of the company most senior engineers had to be distracted with maintaining the aging codebase. Initially the PHP codebase was frozen in time, with only the occasional small bug or customer feature request being implemented in the matured codebase. However a thorough evaluation of their security practices through the lens of ISO27001 compliance showed that to conform to the industry standard of cyber security the company should take a more proactive take in making sure the latest security patches were installed in a timely fashion.

This is where the company turned to Bosun. Could Bosun help reduce the load on the companies most senior engineers? Deploy agentic workflows in their complex and aging code environment? To prove the value of Bosun we initiated a pilot project where a Bosun engineer deployed the Bosun platform on premise, integrated it with their private Gitlab instance, established the environment for working on the legacy PHP codebase and with a regular feedback loop with the company developed a set of workflows that would gradually upgrade the PHP codebase.

Challenges and constraints

  • Gradual upgrades Gradually upgrade a legacy PHP application
  • Repository coordination The application is spread over multiple repositories, with an asynchronous package release process
  • Bounded change Each upgrade sequence should result in a pull request of only single bump major version upgrades
  • Review clarity Pull requests should be easy to inspect, with accurate impact assessments and clear explanation of decisions being made

Implementation

The company was in the fortunate but rare circumstance that their legacy codebase actually has reliable test coverage and the team agreed for the purposes of this proof of value we would rely on the test suite and the intimate knowledge of the codebase possesed by the senior engineer for approving the merge requests. That means that in the workflows we deployed we did not need to first establish a ground truth, which in other situations could be a project in and of itself.

  • Reliable test coverage
  • Senior engineer approval
  • Existing ground truth
Workflow 01 Deterministic dependency routing

Workflow 1: Deciding what to upgrade

The first workflow actually involves no AI at all. Because the project consists of many libraries spread over a number of repositories, upgrading the application is not as simple as bumping its dependencies. Instead, the workflow identifies which internal packages are blocking the upgrade of external packages. If there are any internal packages to upgrade, a recursive dispatch of workflow 1 is triggered for those packages. If the package upgrades are all external, or a PHP version bump is needed, the second workflow is triggered for executing the upgrade on the current repository.

Workflow 02 Agent-guided upgrade execution

Workflow 2: Executing package upgrades

The second workflow guides a sequence of agents through the process of performing a major version package upgrade smoothly. From determining the specific versions, researching upgrade guides and preparing the pull request to executing the upgrade, resolving conflicts and ensuring the lints and tests still pass. Notable here are extra steps like ensuring the upgrade is constrained to package versions that have no current security vulnerabilities, updating the project metadata and the CI. These sort of steps often go skipped when an agent is instructed through a simple prompt, even when assisted by skills especially when performing the actual upgrade was a long and arduous process. Capturing these steps in a static workflow ensures not only that they are executed but also gives us a chance to call back to their outputs in later steps, for example when constructing the final pull request description where we carefully document the impact of the upgrade and any decisions that were made that might need extra human attention.

Integrating into the SDLC

To truly make the dependency progress a seamless cooperation between the workflow and the senior engineer reviewing the pull requests, we integrate Bosun into the software development lifecycle. Whenever a package is released Bosun is automatically notified and re-runs the first workflow, which decides whether it is time for the next set of package upgrades or to wait for another package to be released. When a package is upgraded, Bosun marks the pull request as ready for review and assigns the senior engineer to review it.

  1. Package released
  2. Re-run workflow 1
  3. Upgrade or wait

Next steps

Upgrading the packages is the first step in automating the repetitive maintenance tasks in the software development lifecycle for this project. Possibilities for the next step include automatic remediations for CVE announcements of dependency vulnerabilities, custom code reviews and compliance impact reporting and integration with the ticket board so Bosun workflows become full members of the team.

  • CVE remediation
  • Code review + compliance impact
  • Ticket board integration