In part 1 of this series, I discussed the decisions behind not throwing the code away entirely and getting the app running. In part 2, I broke down the steps to understanding your application logic so you can start documenting follow-ups. . In this part, I will continue to explain the technical refinements for a stable working environment that you can consistently dig into everyday.

Docker-IZE

You now have the app up-and-running locally! …But if you change your hosts entries or have another project that requires Apache with mod_rewrite specifically OFF, that’s not going to be fun to figure out. Containerization is a great option and Docker is the primary technology. If you took decent notes when you set this thing up, you should be able to easily figure out your little Docker cookbook. I’m all about docker-compose. My web container and MySQL container need to talk to each other and this is easily configurable in docker-compose. I can attest that containers works great for both new and legacy systems. It’s a great way to isolate your coding work from your personal work and it feels great to know that it’s almost impossible to break your dev environment by making unrelated changes.

From just a few Google searches, I was able to find Dockerfile and docker-compose.yml combinations that gave me everything I needed with the added benefit of a phpmyadmin installation. See the simplicity of the Dockerfile below:

Dockerfile

Now I am able to start up and shut down my dev environment with the ease of executing docker-compose up (or down). If you’ve ever taken a break from a project and tried to return to it again, then you know about the pain of getting your local dev environment up and running after a few months of using your personal computer. With the Docker-based solution, you’ll never run into this problem again. Believe me, I disliked Docker at first. Before the days of docker-compose, it was really hard to figure out how multiple containers can use the network to talk to each other. It’s also really cool to have developer set up directions that are a single line!

Set up a remote test environment

For you, For your team, for your client

Your client might be ok with seeing changes directly in Production but for the sake of your own sanity and not destroying everything all at once, why don’t you set up a remote test environment so you can deploy your local work there and do some QA testing. Besides, if you are going to end up doing the massive amount of refactoring you think this charming, older web app will need, you will want a remote test environment up and running for your client, your eventual outsourced remote dev in Bulgaria, or anyone else to tinker with as they QA your work. I, personally, like to QA my work on my local machine and also on the test environment. I regularly refresh the test environment with production data and production content as it’s much easier to copy it all over because they are hosted on the same machine from different docroots. Besides, at this point you’ve already set up a database on your local dev environment so you know the ins-and-outs of database exports and imports and you know which tables give you trouble. The test and production databases are completely separate and have no visibility to each other.

The remote test environment quickly became a great place to integrate the work that I did with the work I selectively assigned to my Bulgarian teammate. I hired him from Upwork and gave him a few technical tasks to assess his skills. When I opened bug reports for him, I gave a URL and reproducible test case from our test environment. When we had Production issues, I would reproduce them in the test environment to be sure. This would help ensure that both of us would stay away from the Production docroot on the web server.

Conclusion

If you’ve made it this far, you have a well-running local dev environment and a remote test environment. You have GitHub set up as your source control with a technical wiki and a collection of issues documenting your next steps. This concludes the second part of this guide. In following installments, I’ll document setting up the PHP Remote Debugger to enhance your debugging experience and I’ll further discuss some methodology to slowly but surely modernize the application architecture. I’m looking forward to your feedback on this article! Do let me know about your trials and tribulations with older, less structured web apps!