Hello!
I'm currently writing the backend for a new (Laravel + Vue) project. After the initial planning, we started with a fresh Laravel 5.6 installation as our initial commit. Unfortunately, as the title states, we've had a hard time getting all of our devs (especially the frontend devs who aren't familiar with Laravel) to setup a working copy of our master branch. .env issues, database conflicts, etc.. which I presume is because of OS differences (Windows and *buntu, mostly).
I was wondering how your team is setup to minimize / eliminate these problems so we can focus on the code itself. Share your tricks!
Top comments (16)
This is exactly how you get "works on my machine" from your devs.
As others have stated:
Vagrant
Docker
Dev servers provisioned automagically on AWS/Azure/GCE
Pretty much anything but polluting your own machines with "working code".
The only code I run on my machine is literally static things without a build system or installation steps needed. Or me mucking around with stuff for fun (even then I stay away from polluting my machine with dependencies).
Keep those dev machines clean!
Docker looks promising the more I look into it.
Even if you don't dive deep down the Docker rabbit hole and integrate it into your overall deployments and architecture, you should definitely look at it for development reasons and keeping those dev machines clean.
Gitignore really well configured and/or docker.
This may be a little bit archaic but we rely heavily on gitignore, configured differently on each machine so they don't mix or alter the main branch. Also docker-compose is a must on all db and server configs.
Interesting, what exactly do you mean by this? Like, you pretty much ignore any files that aren't critical to the business code?
Pretty much, also for config files or clases that contain code specially for that developer. Sometimes depending or your IDE and OS, there are files that are created that need to be ignored or they will cause trouble.
TL; DR: docker and docker-compose
Not especially for laravel, but this is how I develop my express + nuxt app:
I have a root that contains server and client folders. Inside each folder I have a dockerfile containing the build process. At root level I have a docker-compose file with db, volumes, server and client. For the .env you either push an example file, or pass it around with docker-compose at build time.
I'm developing in a windows 10 machine now, but I run linux containers inside docker. I hope this helps.
Generally speaking you should not push your .env file, instead a .env.example and make your proper .env file per dev machine. Can you tell us more about db conflicts?
Wow, Docker is pretty hard to setup. Is it really that complicated to get started? I can't even get the example to get running without permission issues lol.
It shouldn't be hard to set up. The only tricky stuff to do is permissions as you mentioned.
In windows under shared drives you have to enable your drive with username, password pairs, after that restart docker. To test run the example command shown.
In unix systems you have to add yourself to docker group.
If you still have problems feel free to send a DM on twitter
Am I going crazy or is there a required step to logout your current session for Docker to install and run correctly? I was able to make it work(?) after a quick login/logout lmao
"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!
I was working on a team where the developers was working on Windows and Ubuntu, but the difference was that we all agree to work using virtual machines, since we were using Laravel we decided to work using the Homestead virtual machine, which is the official Laravel environment to work with virtual machines, give it a try
Vagrant is really nice. It provisions a full VM locally for you to work in so that your app is always running on the same platform. If you set up your local machine to have the same exact environment as your production environment, it will go a long way in helping you identify environment-specific issues before deployment.
I've found Vagrant to be particularly helpful if you have multiple environments it needs to run in, as you can just maintain a separate copy of the repo for each environment, and you can start/stop any single one as needed. In my case, it was actually the same environment, but different branches of the same app where the 'maintenance' branch was far enough behind the 'master' branch that the database had a different schema. I didn't want to keep clearing my local database and re-running all migrations, so I just keep the maintenance branch in a different vagrant machine so that they each have their own databases.
Our small team all works on Mac at the moment so I don't have a lot to add myself, but this thread is an auto-bookmark for me. I'm always looking for improvements and solutions in this regard.
Oh, what an awesome infancy dev.to has in regards to these setup. Hopefully you don't shotgun your future devs onto Macs when your team grows :D