How to handle backend (laravel) and frontend (angular) dependencies in different git repos

Question

We're building our first webproject with laravel and angularjs and trying to figure out how to setup our development environment. Our current approach looks like this:

• Backend git repo with laravel file structure
• Frontend git repo with angularjs file structure

So some of us could work on the backend/frontend without the need of messing around with the frontend/backend files. Now, if there is a new version of e.g. a dev branch on the backend repo and I am working on the frontend, I want the frontend repo to automatically pull this new backend version from the git server and copy it into the development environment of the developer (on his workstation). That should guarantee that we can use the latest api routes in our frontend development.

The questions are:

• Is there a way to automate this scenario?
• Is it at all the best approach to seperate laravel and angularjs in two different repos? We also want to use some kind of task runner (like gulp) to build/package/minimize our frontend files (e.g. sass, less).

Answer 1

This answer is just one of the many ways to accomplish this and defining a "best approach" is quite relative.

1. Create separated virtual hosts to different branches (dev, release, master..)

In your Apache or Nginx, create different hostnames for different branches and, in each root directory (like public_html) pull the specific branch.

This way you allow your frontend devs to test multiple branches without compromising other devs.

2. Create a cron job to execute git pull periodically

This is not an optimized option but it is simple. Many complex solutions exist to auto pulling (like here and here) but, as I said, they are complex.

You can define an extremely short period to your cron job (like 5 or 10 minutes) since there are no problems when you pull and there aren't updates.

3. Establish a branching model

Probably you have one but, if not, define a branching model with your co-workers, like the old but gold Git branching model by Vincent Driessen.

One key aspect is that you allow your devs (both front and back) to work with their changes without affecting the others.

Usually each dev will only merge its local branch with the upper level after some tests (local to dev, dev to release, release to master), avoiding undesired error propagation.

This way each one can test its own code, including frontend devs using one of the backend virtual hosts to complete the test.