My team of developers are currently working at a client who has required us to move away from SVN and begin using their native workflow program. (Source tree by Atlassian). We are data warehouse developers and utilise primarily the Microsoft SQL stack for development.
The stack is commonly:
- SQL Server Analysis Services (SSAS)
- SQL Server Integration Services (SSIS)
- SQL Server Management Studio (SSMS)
We also utilise a data-visualization tool named Tableau Server.
At the client these tools are used to develop simultaneously across four subject areas, for the purpose of this we will call them Subjects Areas; W, X, Y and Z.
Each subject area gets its own lot of solutions in all three SS programs as well as some files associated to tableau.
Since switching to sourcetree we have had a workflow of a master branch which reflects the work that will be migrated to the production environment. As well as a development branch which all developers commit to on a frequent basis.
After a large bug was detected in one of our subject areas we needed to revert back to the last good commit for the production environment. This was nearly impossible due to the large number of commits and merges and our disorganised gitflow.
This leads me to the question:
What is the ideal way to manage in effect the development of four subject areas across four programs simultaneously using github?
From my reading it would seem that 18 branches (4subject x 4 programs + Master + Dev) is a solution however this seems to be overkill.
Points to note:
- All subject areas are developed simultaneously.
- Programs (SSMS/SSIS) are developed by multiple developers simultaneously in different subject areas.
- We have changed our master branch to be a sole reflection of our production environment with no extra commits already.
- We only have access to a single repository.
- Some work on some programs (SSIS for Subject X) are developed but never merged to production. This work needs to be maintained though.
As this is a subjective question, any opinions or further clarification is welcomed.