-1

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.

  • If I would create common repo for both backend and frontend, then frontend sources will be also included in the repo and I don't need them on production server.
  • If I would create two separate repos for frontend and backend, then how would I syncronize actual frontend bundle and actual version of backend code and how would I return to specific version of my project?

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.

dajnz
  • 1,178
  • 1
  • 8
  • 20

1 Answers1

2

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).

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
  • Thank you for your answer, but since I'm not very proficient in git can you clarify to me, if I need only assembled bundle, but not whole frontend repo from frontend project for my backend and even a part of this bundle (only assembled styles and scripts), will submodules help me in this case? You see, there are two aspects of my problem: 1) on each rebuilding of my frontend I need only fresh build bundle for my backend and I don't want to copy bundle manually each time after rebuilding, 2) I want easy deploy of my backend with no manual copying of frontend bundle. – dajnz Jul 23 '16 at 13:53
  • 1
    @dajnz you are correct, that (submodule) would not be idea: a submodule is a git repo, a *all* git repo (not just a part of it). If you can divide your code base into independent modules, then the submodule approach is for you. – VonC Jul 23 '16 at 13:57