Source
r/PHP•
RuneAlpha

Discussion on what dev environment people use and prefer

Hi all,

The company I work at is currently looking at starting to get external PHP devs working on some of the various PHP applications that we have - potentially anything from our ecommerce platform or one of a couple dozen of systems written internally. I'm the only full time PHP dev we have, so it's come down to me to sort things out and I'm aware that I need to get each external dev their own development stack.

What I'm interested to find out is what people would consider a decent and professional environment if you were freelancing? For example would you expect a Docker stack running on your own PC, or would you expect to VPN in and have some kind of stack available to you? Or is there something else you'd expect or prefer?

Posted Apr 29, 2022, 10:41 AM UTC

2030
matad2k•

I think docker is standard for current days, you can have multiple versions PHP, databases and server environments and docker isn't resource heavy opposite to vm solutions (vargant, vm). Downside of docker is that setup can be tricky but you can find lot of docker compose files and tweak to own needs. With docker you can keep your dev environment in one folder with project files

9
zimzat•

I still prefer using Vagrant and Ansible for development. The same, or very similar, Ansible scripts (using things like Packer) can be used for production [assuming you're not running containers in production].

At my current job they've migrated most things to Docker. It's actually okay-ish on Linux (minus host file permission problems) but has absolutely terrible performance on Mac, doesn't play well with the M1 ARM architecture, and all the same downsides as running Virtualbox in Vagrant on Mac would.

Basically, to echo u/tuupola, if you're using containers in production then you should use containers locally, if you're using standard EC2 instances in production then you should use Vagrant and Virtualbox in development and Ansible in both.

5
z01d•

ditto

2
chumbaz•

I’m in exactly this same boat. I have an M1 laptop that’s just collecting dust as I couldn’t find any functional solution (yet). So frustrating.

2
zimzat•

We've had to use a lot of creative solutions for many things since every new developer is only getting M1. The first solution is usually adding platform: linux/x86_64 to docker compose for each service that doesn't have a ARM image (by which it emulates away the performance benefit of ARM). The next solution is to find an alternate image that does support arm and then put that in a docker compose override file (mysql-server vs mysql, but only for v8). If all else fails adding a Dockerfile with custom builds to install it via Ubuntu might work? I think that's how our cypress service is being done? :shrug:

1
doedifur•

"standard EC2 instances"

Not everyone uses AWS as their VPS provider.

0
zimzat•
s/EC2/compute/
1
chevereto•

+1 for containers. It is a massive ecosystem of software and not just Docker but the container initiative. There's k8s, podman, buildah, tons of managers, etc.

I spawn my own custom images depending on the use context, I build them multiarch so it runs in my old x86, M1, etc. I've one of my dev setups here: https://github.com/chevereto/v4-docker

In that one I have added Makefile for dynamic command resolution. I've the need for multiple php versions, for each version of my software.

What you should really pay attention when developing software is to isolate the dev environment from your local system. You don't want to bind Docker mounts to a path containing your in-development files, you want to run the app in its own sandbox. You can easily achieve that by using a one way mirror sync. Check the observe.sh file: https://github.com/chevereto/v4-docker/blob/4.0/scripts/observe.sh

5
RuneAlphaOP•

Thanks for the reply and information 😊 I've are various challenges as we've a number of different environments running PHP code here - we've small one-off systems running on IIS (with MSSQL), our main website which currently runs on AWS (with MySQL/Aurora) and I've a few docker based consumers relating to the message broker system we've recently implemented.

The trickiest bit is that pretty much everything we want a third party to work on requires connecting to a pretty sizable databases, which is why one suggestion somebody put to me was that we host a server or docker stack for the dev and allow them to connect via VPN into that isolated environment. That was really the reason why I popped up this discussion as I was curious what environments people used and come across.

2
_pgl•

Lots of recs for containers already in this thread so I'll try to voice another point of view.

I'd honestly want some degree of flexibility in my dev environment. As long as I can locally replicate the exact PHP version and run a database server that mimics production, I don't see why I couldn't just work on my own machine. PRs still have to be made and code review would catch anything out of the ordinary. Open-source projects show that many developers can work on the same codebase without identical systems.

Clear instructions on how to set up, run, debug and test the application(s) are essential. Docs/wiki too. Paid licenses to every piece of software used in the stack (or by other members of the team) would be nice. To me, contribution guidelines, Git etiquette, task management, etc.. are all more important to freelance work than replicating the exact production env.

5
leftnode•

We're moving back to this method as work now that the new MacBook M1's don't support VirtualBox and we don't have time to play around with VMWare Fusion to get Vagrant working properly.

We have a monolithic application requiring only a single build script, and once it's set up, at most you're just destroying or rebuilding a local database (which is easy to do due to our migrations).

2
RuneAlphaOP•

Thanks. You're absolutely right on the contribution guidelines and it's certainly something that we've not got here if I'm honest!

1
Open-Honey-9198•

I prefer a docker-compose, it's easy to make and run everywhere. Some dev prefer to use windows, some prefer linux and other a mac.

I suggest to only create a docker-compose file and give it to the dev, don't enforced it! There is no need, because some would prefer to install the stack directly on their computer, other would prefer vagrant and other will prefer to make something more custom.

Just don't forget the config file like apache, ngnix, php and any other that you use.

4
zschuessler•

Consider me old I guess, I still use a LinuxMint virtual machine and setup projects locally the old-fashioned way. This setup has never failed me in the past 20 years. I'm fast and efficient.

Containers on the other hand.. I've only ever had brief moments of time where they completely worked and much longer stints of time where they were headaches. The maintenance and upkeep itself feels like a job, and when in a team based environment with different machines it feels like a significant amount of time goes into addressing issues.

That's been my experience and I've worked on many different teams. No one team was able to avoid the headaches. I've seen Docker, Vagrant, and packages built on top of them to simplify the process. All had their issues that distracted teams from normal work.

These days when I see container issues arise I stay quiet and breathe a sigh of relief I don't have to deal with them.

For your specific case if you have a larger team I would look into GitHub Codespaces or an alternative - offload all the headache to someone else if you can. It's definitely worth the price.

If it were me running a team I would consider Ansible, since you still get your own environment in the end.

I'd even consider a team-curated guide on how to create a local development environment, with playbooks/sh scripts automating processes. It's not sexy or cool but it's never failed me and gets engineers familiar with environment creation. It's not a crazy idea to ask devs be familiar with environment setup IMO.

4
via-via-gekregen•

I share your frustrations with docker, and the few times where it did work flawlessly the performance was noticeably worse then it would be if I just ran everything 'natively'. But I should mention I work on a mac which is a factor and I also have the luxury of only having to work on one code base (so I don't have to switch php versions like others mention in this thread)

3
systematical•

Mac is terrible for containers. At work I am running full blown k8s on my desktop to mimic prod and need 32 GB of RAM. Its night and day when I close my work laptop and open up my home laptop running Linux. I don't know how people like developing in Mac, home brew is garbage compared to Apt and I find the OS has too many bugs in it for what you pay. I can get the same amount of less bugs out of my FOSS OS.

3
chevereto•

For speed issues check that you are using the virtufs. Also, check that the images you are using are compatible with your processor. To give an example: MySQL ran awful slow in my M1 setup because the storage driver runs emulated. I had to switch to MariaDB.

This happened some time ago, perhaps Oracle already fix this issue.

1
chevereto•

could you elaborate which specific issues you had?

1
Hirnhamster•

Docker is imho the way to go. Only downside for me is the file system performance on Mac and Windows compared to Linux. I've documented "our" setup in https://www.pascallandau.com/blog/docker-from-scratch-for-php-applications-in-2022/ which is part of a multi-part tutorial on "all things docker" for PHP devs => https://github.com/paslandau/docker-php-tutorial

3
cabbagepenetrator•

I've found file system on Windows to be very close to native Linux using WSL2.

You have to make sure that you're mounting your project files in your WSL /home directory, doing this made my local dev with Docker much faster.

1
sam-sung•

Vagrant + Visual Studio

3
tuupola•

I expect to be able to run the development environment on my own laptop. To me Docker makes sense only if production also uses Docker. If production is is a VPS or baremetal server then Vagrant virtual machine which is as identical copy as possible of the production environment.

2†
punkpang•

Containers.

​

Never VPN or some kind of remote solution. Unless you're on optical fiber on both ends, it'll lag.

​

Why containers? Because of Kubernetes and Docker. With docker-compose you can spin up multiple services (php-fpm, redis, mysql) and keep them in the same network, each one being able to resolve others via DNS (i.e. you can refer to services by a name rather than IP). It makes it easier to add more services and to deploy with K8.

​

The prime example of what I'm referring to is: https://github.com/laradock/laradock

I read the rest of the comments and I'm not sure why people have problems with containers. The only OS where I experienced problems with containers was MacOS with M1 chip. I don't use Mac so I didn't bother to research further than trying Docker out on M1 and realizing it didn't work instantly like it did on Linux/WSL2.

​

Having tried virtual machines and being extremely frustrated with them, I can't recommend Laradock enough. I could go into lengths what's frustrating with VM's, but it doesn't mean they're bad solution.

​

Any solution that allows creating the same environment, running the same services and being capable to replicate that in testing/production environments is a good solution. It depends how experienced and skilled people are when it comes to setting each one up. In the end, you'll end up using bash / some kind of YAML-y configuration to make several services work together.

2
RuneAlphaOP•

Out of curiosity, how would you consider handling large database's? One of the challenges I have is that most projects will require access to at least 2 years worth of customer/order data (obfuscated for gdpr & business reasons). You're looking at around 4 Gb for our main website for example - it's not huge, but certainly not something that I'd want to source control.

1
punkpang•

I'd use one of managed database services. AWS's or Azure's or Google's or Oracle's - Oracle's offering (if you use MySQL) is great, it's extremely fast, scales well and it's the cheapest offering among all the cloud providers.

If you don't want to use a cloud solution, I'd get a physical server (say, Hetzner), install what I need there and use it (taking into account practices relating to backups and restoring).

For local development, if you need or want everyone to have a local copy of the database - I'd distribute that huge DB dump as a text file, go through pain of importing it (you'll do it once, presumably) and then use it.

​

I'm answering without having all the info you have at your disposal. 4GB isn't humongous, today's PC's and servers handle that amount of data with ease. It depends on what you do with it of course and what your tasks are. You know that better than anyone.

​

For comparison, I use Laradock that I mentioned due to simplicity of setup, each developer runs a local copy of a DB that's currently 11GB in size. We import it once and work with it for that particular project.

​

I'm not sure if it answers your question, if you can spare more details such as what the challenges you're having are and what performance or developer experience problems are - I might add further info.

2
RuneAlphaOP•

The dev server I personally use at work is a centos machine set up with all the components the main website uses (it's an ecommerce site with a basic lamp stack, redis, elasticsearch etc). It's probably 7 years old now and has been used for all sorts of stuff over that period (i.e. it's a mess). It contains a complete copy of our database - around 30gb in total. Every now and again I'll dump a copy of the live server over to the dev one - we may have a customer with an issue with an order placed last week for example (we do huge amounts of analytical reports so this isn't uncommon). For me and the chap who occasionally helps me out, this is fine - a bit rough around the edges, but works fine. The main website code is source controlled in GitHub and I have automatic deployment to AWS via CodeDeploy

We've grown to the point where we need more dev support. Trying to find permanent in-house devs has come up blank so we're looking at casting the net further afield (i.e. outside the UK) and using freelancers to fill in the gaps with specific projects (we're in the same situation with C#/MSSQL devs too :). That's pretty much where we're at now. I know that each dev will need their own development environment, isolated from everyone else. I also know that I can't pass them a copy of our live data - it contains not only swathes of personal information, but loads of business confidential items that competitors would love to get their hands on. We're also trying to standardise a huge amount, we've been very reactive over the past 4 or 5 years, but now have the opportunity to rehash things and get a decent set up in place - long term this includes containerising things and we're moving towards a more microservice approach too.

The beginning of the year we found a dev who was prepared to do some work for us on one of the PHP tools running on IIS. In short it was a nightmare, we provided a VM of a MSSQL/IIS server for them to use which they basically butchered and their own preference would have been to run entirely on an inhouse server here. This is probably one of the main reasons I'm asking what other people view as a good and known set up

2
punkpang•

We're in similar situations.

There's a database you can't share with new devs, that's the problem.

Second problem is that each dev needs *a* database.

Solution, which you're aware of, is to have a development database (no customer data, no identifiable data, nothing that dev might abuse or leak and damage you or customer).

The choices are:

  1. Dev database on dev workstation
  2. Dev database on <server>, shared with all devs

​

I went with choice 1, each dev runs literal copy of testing/production environments but database contains fake data. The copy of environment = containers, connected in an internal network (handled by Docker).

Challenge I had to deal with was "How the hell do I give a dev all the software we use". I used VM's for a long time. I used Vagrant to automate it. VM's aren't the problems, it's the devs who can't use them. Shut a VM down forcibly, it'll corrupt. People also claim they're devs yet they know fuck all about operating systems or how services like Redis/*SQL/Web server actually work.

Second challenge was "How do I add <service-name> to dev environment and testing/production environments". I dealt with this manually, then automation via puppet/chef/ansible and ultimately via Kubernetes.

What proved to work were containers. I use self-hosted GitLab which serves as container/package registry. I can build containers and push them to the registry. I can use those containers to distribute them to devs and I can use the same containers to push to testing/production, naturally with different app configuration and all that goes with it.

​

End result is this:

Dev env is quick to start up. Here's the services used:

  1. PHP-FPM (v8.1)
  2. PHP CLI(v8.1)
  3. MySQL 8
  4. Nginx
  5. Node.js / Nuxt.js / Vite (1 container for these)
  6. Clickhouse
  7. dnsmasq
  8. Redis
  9. Hashicorp Vault

It takes several seconds to start these up on my PC (32 gigs, Ryzen 4800, Samsung SSD)

Out of these, I also build target containers that are handled by k8 for deployment.

I've been using this for ~12 months, it wasn't easy to start with but after a period of adjustment from everyone it turned out to be the best option so far.

To start up the project we're working on, dev clones the repo with these containers, runs make start in the terminal, script boots the containers, sets the Laravel/Node app up, pulls the db, exposes local dev url for them to work on and off we go.

Hope this helps, if you got any other questions don't hesitate to ask and best of luck!

2
[deleted]•

[deleted]

1
Radiant_Juggernaut56•

If you can't use xampp as your dev environment then you are wasting your life

1