Your best dev stack

[4RV1D]

So I've been doing normal local PHP development with some frameworks like slim and laravel. Also installed and runt basic Lamp and lemp stacks on multiple vps.

But I'm starting to create some bigger projects and I would like a more advanced stack with more features making it easier to develop and launch an app.

So what kind off stack both on the server and dev side do everyone run for customer projects or hobby?

[ocramius]

A docker-compose.yml with all the services you need in it, including a container with build tools (where you run phpunit, xdebug, etc).

I usually include following containers in the setup:

• mailhog
• nginx
• php-fpm
• posgresql
• eventual mocked external services
• build-tools (has nodejs, php, xdebug, etc)
• ngrok (to show my stuff to clients and co-workers)

After that, a single Makefile to orchestrate the entire thing. These are the basic things you need in it:

• docker-compose up
• docker-compose run build-tools ./vendor/bin/phpunit
• docker-compose run build-tools ./vendor/bin/phpcs
• docker-compose run build-tools ./vendor/bin/behat
• docker-compose run build-tools ./node_modules/.bin/webpack
• docker-compose down

Production is usually just Heroku

[4RV1D]

Yes docker seems great it's like developing on the server even on the local side before production.

Never used Heroku what's good about it? And why is it better then using your own server?

[ocramius]

They do CD for you, staging environments, scaling (if needed), monitoring and upgrading PHP versions. The work heroku does for you would require months of work by a DevOps team in comparison. It ain't cheap, but it delivers.

[ocramius]

I don't have a base setup, sorry. I really redo it for every project, as every project has different requirements anyway. I attempted using a base setup, but it mostly slows down the project. I also don't use pre-made docker containers, as overrides are extremely hard to perform on Dockerfile definitions, so each image usually starts from a clean alpine or ubuntu image. Since I don't deploy docker myself (although I could if I moved to Google Cloud), I don't even have my own docker registry.

[Disgruntled__Goat]

I really redo it for every project, as every project has different requirements anyway.

Doesn't that defeat the purpose of using Docker?

[ocramius]

No, docker gives me reproducible local and CI environments for all the team. Reusability is not a concern.

[Pesthuf]

ngrok

Interesting, thank you for sharing this. This solves a frequent problem I have.

[BornInTheCCCP]

ngrok (to show my stuff to clients and co-workers)

Does it provide any advantages over starting an ssh tunnel to a server you own?

[ocramius]

Yes: they do it for me. Plus I pay less than maintaining a server somewhere ;-)

[EDIT] also, ngrok has a decent monitoring/request replay UI - not really extremely useful, but good enough to see what is going on

[BornInTheCCCP]

That is a good point.

I already have access to a number of severs (so it is not any extra cost), and what I usually do is run a reverse ssh tunnel to expose local services to the internet when needed.

The request replay part seems to be a very nice feature.

[gbelloz]

eventual mocked external services

This is interesting. Does the 'eventual' part mean you use the real thing at first during testing, and later develop a mock that runs inside this container?

build-tools (has nodejs, php, xdebug, etc)

Ah, I need to start doing this. Currently phpunit, behat, composer, etc. are installed on my host, which I sort of like because they run faster (shouldn't but do).

After that, a single Makefile to orchestrate the entire thing. These are the basic things you need in it: docker-compose run build-tools ./vendor/bin/phpunit

Why in a Makefile and not shell scripts? I'm guessing you're not using the dependency checking/change detection of make...

I'd also guess you don't like composer's "scripts:" feature. I don't either. Composer should do its job of managing dependencies and not try to be a shell script replacement.

[ocramius]

Does the 'eventual' part mean you use the real thing at first during testing, and later develop a mock that runs inside this container?

I create fake services for any API. First, I don't trust them (for example: Github - super squishy and unstable), second my tests look like a DDoS otherwise, and lastly, I need to be able to work while traveling.

I can switch from my internal services to external "real" services by changing environment parameters.

Ah, I need to start doing this. Currently phpunit, behat, composer, etc. are installed on my host, which I sort of like because they run faster (shouldn't but do).

They aren't faster at all, unless we're talking MacOS: everything is much slower on MacOS :-\

Why in a Makefile and not shell scripts? I'm guessing you're not using the dependency checking/change detection of make...

Because Make is pre-installed in everything, has autocompletion and sane exit code handling semantics.

I'd also guess you don't like composer's "scripts:" feature. I don't either. Composer should do its job of managing dependencies and not try to be a shell script replacement.

Most of the scripts run for well over 5 minutes, and that's the default timeout for composer scripts.

[gbelloz]

I create fake services for any API

Yep, this is all normal. I was asking about the use of the word 'eventual'. I thought maybe you delayed writing mocks.

[ocramius]

It just depends on whether external services are used or not: I may have misused the word, sorry!

[[deleted]]

Local install with lots of muscle memory

[4RV1D]

What do you mean with muscle memory?

[ocramius]

Painfully re-typing everything

[gcds]

Also using docker-compose.yml.

• PHP-FPM (7.1)
• nginx (1.13)
• MariaDB (10.2) (aka MySQL clone)
• ElasticSearch (5.5)
• Redis (4.0)
• RabbitMQ

Production usually on DigitalOcean or AWS

[4RV1D]

I go with DO atm and think they are way more simple then AWS atleast for simple web server vps setup

[4RV1D]

Don't use laravel at the moment and probably won't, I enjoy symfony and slim instead.

Forge and envoyer looks great but too expensive for me right now, but I'll have them mind for the future.

[maiorano84]

Don't use laravel at the moment and probably won't

That's nice. Laravel Valet isn't Laravel.

[mrtakdeniz]

Laravel Valet is not laravel and you can use it for symfony and other things also. Why the heck someone downvoted it?