gitdeploymentfrontendbackendcode-organization

What is right way to organize structure of SPA project with respect of convenient deploy and version control?

Prerequisites:

I need to ogranize Single Page Application (SPA) project development, and frontend should be based on one of popuplar frontend js frameworks, and this means use of frontend building system based on gulp/webpack for building final bundle from let's say Es2015 js sources, Sass styles and Jade markup. Backend should be based on Laravel 5.x.

So finally I've frontend bundle which should be work with backend code. and on each stage of development I have certain frontend bundle and certain backend code which can work together correctly.

Questions:

  1. How most correctly place all my source code under version control (let's say with use of Git)? Do I need to create one repo for all project of two separate repos for backend and frontend parts? Why?

  2. How to organize version control for most convenient and simple deployment of current release version of project to production server?

Here is my thoughts: it looks like a good idea to have actual version of both frontend bundle and backend code + migrations in one repo, but my dilemma is: for production I need only frontend bundle but not initial frontend source code (sass, jade etc files). My frontend bundle constantly rebulds with my building system on each changes in frontend source code/styles/makrup, so output bundle is different after each build.

I hope this was written quite clear to understand me and I ask any sort of advice or links for some docs which can clarify such quiestions for me.

Solution

  • If I would create two separate repos for frontend and backend, then how would I synchronize actual frontend bundle and actual version of backend code and how would I return to specific version of my project?

    That is usually done through a parent repo whose task is to record the right version of the frontend and backend declared as submodules.

    Each time frontend and backend change, your parent repo git status mentions the SHA1 of those repo has changed (ie their gitlinks, special entries in the index of the main parent repo)

    By pushing that parent repo (in addition of pushing frontend and backend repos), you keep track of which version of frontend goes with which version of backend, and you can return to a specific version of the project (through the parent repo history).