Current State-of-the-Art for LAMP Workflows?
Benny Powers 🇮🇱🇨🇦

Benny Powers 🇮🇱🇨🇦 @bennypowers

About: Coding is as much a matter of personal growth as it is of logic and control-flow. I keep patience, curiosity, & exuberance in the same toolbox as vim and git. *Opinions posted are my own*

Location:
Jerusalem
Joined:
May 22, 2018

Current State-of-the-Art for LAMP Workflows?

Publish Date: Nov 15 '18
17 14

Hey There, Dev!

What's the current state-of-the-art for LAMP workflows? My client has a small team, and they're currently just uploading files via FTP to a GoDaddy shared server - No source control, no tests, no deployment, just FTP 🤷‍♂️. They also don't have any sort of local development workflow, so no XAMPP/MAMP, vagrant, docker, etc.

In order to open the door to more modern workflows, I want to get them pushing feature branches and opening merge requests on GitLab and have some CI/CD running. I also want to set up some local-development facility so that we don't have to wait for FTP to sync, then fetch static resources from GoDaddy's ahem somewhat under-performing servers on each load.

My present thinking is something along the lines of:

  • Apache or NGINX in docker serving static files and running PHP
  • A separate MySQL container running the database.
    • We'll either instantiate a new DB for each user's local dev box or point the development containers to a development DB server.
  • Docker for Mac / Docker for Windows for local dev
    • Or is there some GUI wrapper around docker that would make this a less painful process? I tried Local by Flywheel once and it wasn't half bad.
  • GitLab CI to run deployments either to GoDaddy (docker on GoDaddy?) or to one of the cloud providers.

Orchestrating the DB across multiple instances is not a priority at the moment, but if we're going to invest in a more sophisticated workflow than uploading over FTP, we ought to have future orchestration in mind, so what are some common gotchas?

If you were doing this, would you take this approach or another?

Comments 14 total

  • Grzegorz Ziemonski
    Grzegorz ZiemonskiNov 15, 2018

    In my experience, Docker is a great way to enhance your local development workflow, but... you need a strong understanding of the basics. Hence, I'd opt for starting without any GUI wrappers and advanced tools (e.g. docker-compose), at least until the team understands Docker well enough to know what these tools are doing for them, other than "magically making it work".

    Can't say anything clever about the other points, so I'll end here ;)

  • David J Eddy
    David J EddyNov 15, 2018

    Before you do ANYTHING, you MUST have buy in from both the business operators and the dev team. If anyone doubts the the positive impact this updating will do, the effort will sour. This is the part of 'DevOps' that is often overlooked. Culture and faith are just as important as tools and process.

    As the Agile Manifesto states it:

    • Individuals and interactions over processes and tools
    • Working software over comprehensive documentation
    • Customer collaboration over contract negotiation
    • Responding to change over following a plan

    That being said. I have done exactly what you are talking about. I would take it a step further and deploy the application images to DEV, then Stage, then Production. I am a big supporter of environmental parity. Deployment to Dev is the same as Stage is the same as Prod.

    Also, 100% agree with @goyo ; the team has to understand what the tech is doing being using fancy GUI's. Learn the tool, master the tool, abstract the tool.

    If you would like any assistance, I am looking for some gig work ;).

  • Aarav Mehta
    Aarav MehtaMar 12, 2025

    Give ServBay a try to effortlessly tackle all your development needs—it's fantastic!

Add comment