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?
Top comments (2)
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:
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 ;).
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 ;)
Some comments have been hidden by the post's author - find out more