Team development with Laravel

regarding the database: http://laravel.com/docs/5.1/migrations

regarding the staging environment: just copy your production environment, make a new branch called staging and deploy to the new environment with this branch. as soon you want to test out the new code from everyone in a production like environment, just merge into the staging branch and deploy.

One of things is you can make migrations and seeders also you can make own 'Install script' and run it with artisan. That all works great in theory but some projects that are mature, have a lot of real data and settings that are in database do not work that way... for example I may work on a new feature that assumes I insert some settings in database and my thing is loaded once that record is in... sure you can do it with seeder etc but it is real pain to keep it all in sync. The other way is to have prod_database; beta_database; whatever_database ... on some mysql server and you all can access to it... or make mysqldump from time to time to sync database.

@MHertel Every one should have their own isolated development version of the website to run on their machine, that works without a network connection. Sharing a database isn’t really practical as it gets out of date very quickly. When you’re testing filling out forms and adding data to your database, that is the database getting out of sync and the problem will only multiple the more people that join the project. Instead, to simulate data in your application, use seed data.

As for staging, you should have a server set up and pointing to a development branch in your code repository. The staging site would have its own version of the database. When you finish a feature, you would merge the code from your feature branch to the development branch, and then trigger a deploy to the staging server. Every one would then see the same site. If you’re worried about data getting “dirty” with multiple people filling out forms and whatnot, then you could have a scheduled task that maybe “resets” the data every 24 hours. Could be something as simple as running php artisan migrate:refresh && php artisan db:seed at midnight every day.

Hi guys,

thanks for your replies!

The DB problem isn't the structure, I know what migration are, the problem is the actual data stored on it, for instance while developing chances are that we'll need to show progress to a manager or supervisor so if we have out of sync data in different machines everything will get messy.

Based on your replies I think the bast way to tackle this is set everybody up for local development and push to the staging environment when we need to show features to managers/clients and then push to production

Do you think that's a good set up?

Thanks

@MHertel Yes, that’s what a staging environment’s for. You don’t want managers hanging over your shoulders looking at your in-progress local versions.

Thanks @martinbean all that is completely different from our current workflow I really hope it will work well

Cheers