"Works on my machine", oh how many time have I heard it.
I have worked in 4 kinds of environments:
everyone for himself
shared development machine
vagrant
docker
Shared development machine
One machine that fully mirros production environment and everyone mounts one volume where they put their code (obviously a bit more is involved but I am not going into details).
This is relatively easy to setup but suffers one problem - you can not really try new things, e.g. increase PHP version without affecting the others.
Vagrant
Vagrant is great when everyone is developing on the same platform. In our case it was PHP 5.3 and python 2.7 with no option of updating. So I created a base box that mirrored the production server, installed basic utilities that everyone was familiar with and it worked without any problem for 15 developers. Additional important updates were then handled by vagrant provision.
Once you install the box you can personalize it any way you want, even try new things without affecting others.
Docker
Two years ago I started working on a project in small team of 5 people, whith old projects of their own and quickly realized the problem. Multiple projects on multiple versions of PHP, python, etc. Everyone was flying solo and the infamous "Works on my machine" was the buzz word.
And this is exactly the kind of place where I prefer Docker over Vagrant. Vagrant is great, but a bit heavy and running 2 or 3 machines on 8GB of ram is not pretty. Containers come in handy here, because if you want to run different version of PHP, you just take down 1-2 containers and spin up new ones in matter of seconds.
E.g. we use 3 PHP containers respectively with version from 5.6 to 7.2 and you can just pull the version you need. Same can be done with databases, node, etc. Containers can be pre-provisioned (migrations, seeds, etc.).
Every project should also contain an init script that will ensure the project will run - create/copy correct .env, install all dependencies, database is up to date, etc.
After having experience with all three, I strongly believe that new member of the team should never spend days preparing his machine, but only install his favorite editor and he is good to go.
Of course the initial setup cost can be huge (Vagrant on 15 Windows machines few years back was hell of a ride). But its worth it in the long run.
I would recommend to move to one of the above. If that could be a problem then start with an init script that every system can run.
"Works on my machine", oh how many time have I heard it.
I have worked in 4 kinds of environments:
Shared development machine
One machine that fully mirros production environment and everyone mounts one volume where they put their code (obviously a bit more is involved but I am not going into details).
This is relatively easy to setup but suffers one problem - you can not really try new things, e.g. increase PHP version without affecting the others.
Vagrant
Vagrant is great when everyone is developing on the same platform. In our case it was PHP 5.3 and python 2.7 with no option of updating. So I created a base box that mirrored the production server, installed basic utilities that everyone was familiar with and it worked without any problem for 15 developers. Additional important updates were then handled by vagrant provision.
Once you install the box you can personalize it any way you want, even try new things without affecting others.
Docker
Two years ago I started working on a project in small team of 5 people, whith old projects of their own and quickly realized the problem. Multiple projects on multiple versions of PHP, python, etc. Everyone was flying solo and the infamous "Works on my machine" was the buzz word.
And this is exactly the kind of place where I prefer Docker over Vagrant. Vagrant is great, but a bit heavy and running 2 or 3 machines on 8GB of ram is not pretty. Containers come in handy here, because if you want to run different version of PHP, you just take down 1-2 containers and spin up new ones in matter of seconds.
E.g. we use 3 PHP containers respectively with version from 5.6 to 7.2 and you can just pull the version you need. Same can be done with databases, node, etc. Containers can be pre-provisioned (migrations, seeds, etc.).
Every project should also contain an init script that will ensure the project will run - create/copy correct .env, install all dependencies, database is up to date, etc.
After having experience with all three, I strongly believe that new member of the team should never spend days preparing his machine, but only install his favorite editor and he is good to go.
Of course the initial setup cost can be huge (Vagrant on 15 Windows machines few years back was hell of a ride). But its worth it in the long run.
I would recommend to move to one of the above. If that could be a problem then start with an init script that every system can run.
Thanks for the writeup!