Months ago I wrote an article about Enterprise Flex apps and their build process. Recently I have been working on much more HTML / JS application development. I have noticed that there is no really easy way to make JS libraries and HTML common fragments or partials easily shared amongst enterprise projects.
The first step in this is organization in source management and Git allows for a great feature of organization called Submodules. Some of the reasons you should look into Submodules are:
1) Security of libraries and implementation projects (permissioning granularly projects)
2) Versioning of the libraries and dependencies can be managed on a project by project basis
3) Core feature development can be released independently of it dependent needs
Let me first start by pointing to the example project which is completely trivial but non-language specific to elaborate on what I want to advocate. In this example we have a Super Project with two children Project A and Project B. The cool thing here is that your build scripts for building all of your enterprise code can live in the Super Project. Then each project A and B can have their own independent build scripts. They should not depend on each other at least not for now.
When you run git clone on the super project you end up with:
$ git clone firstname.lastname@example.org:neosavvy/super-project.git super-project-test Cloning into super-project-test... remote: Counting objects: 6, done. remote: Compressing objects: 100% (4/4), done. remote: Total 6 (delta 0), reused 3 (delta 0) Receiving objects: 100% (6/6), done.
Now when you change directories into this project you will see that you only have anything checked into the Super Project with two empty directories.
$ cd super-project-test/ super-project-test $ ls README.md project-a project-b super-project-test $ ls -l total 8 -rw-r--r-- 1 waparrish wheel 27 Oct 18 23:02 README.md drwxr-xr-x 2 waparrish wheel 68 Oct 18 23:02 project-a drwxr-xr-x 2 waparrish wheel 68 Oct 18 23:02 project-b super-project-test $ tree . . ├── README.md ├── project-a └── project-b 2 directories, 1 file
super-project-test $ git submodule init Submodule 'project-a' (email@example.com:neosavvy/project-a.git) registered for path 'project-a' Submodule 'project-b' (firstname.lastname@example.org:neosavvy/project-b.git) registered for path 'project-b' super-project-test $ git submodule update Cloning into project-a... remote: Counting objects: 3, done. remote: Total 3 (delta 0), reused 3 (delta 0) Receiving objects: 100% (3/3), done. Submodule path 'project-a': checked out '7f46e630acca29d4f3f99f61c7c990aad54f5fbe' Cloning into project-b... remote: Counting objects: 3, done. remote: Total 3 (delta 0), reused 3 (delta 0) Receiving objects: 100% (3/3), done. Submodule path 'project-b': checked out '5c95c3db092f12e293c82d29ef519603979685e6'
Finally just look here to see that the repositories code is now populated in the directories.
/NEOSAVVY/work/test/super-project-test super-project-test $ tree . . ├── README.md ├── project-a │ └── projectAFile └── project-b └── projectBFile 2 directories, 3 files
Just to circle back to the original three points here, governance can be accomplished due to the fact that all of the repositories are separate. Everyone on your team can have read access to them, but you can lock down core dependencies to those developers you trust to work on them. Versioning again can be separate since each one of them has their own master and branches / remotes to represent different stable code (if need be). The core dependencies of a framework can also be managed on their own roadmap and also the roadmap of Project A if it is vastly different from Project B can be handled independently of each other.