Remote repository and workspace structure

Repository Design

• One workspace per stack
• If all repositories grouped together only need one project, same name as workspace
• If have areas within stack
• web service = one final project, eg: Izara Market

Workspaces

Izara Core - Libraries

• npm modules that can be used by any web service
• one project per subject or grouping of functions

Izara Core - xxxx

• Any stacks that can be used by multiple web services prefixed by Izara Core
• eg: Media

Izara Frontend - Core

• Group all frontends for to core services in this workspace
• Separate projects for each stack
• Izara Frontends - Core project is for foundation microfrontends like rootConfig and auth

Izara Frontend - xxxx

• can split groupings of frontends into workspaces
• eg all Market frontends are in Izara Frontend - Market, one project per stack

Izara xxx - yyy

• Each stack has its own workspace
• prefixed by the web service's name, then the stack, eg: Izara Market - Products

Developers

• When working on a workspace, developer creates a workspace with the same name suffixed with their name in brackets
• That developer forks the repositories they are working on into this workspace, name of repository suffixed with their name in brackets
• If multiple developers working on the same repositories, only one person forks and names that repository
• name suffix of repositories will match the workspace forked into
• copy the names of workspace/project/repository from originals, only adding name suffix in brackets

User Access

• Bitbuckets 5 developer limit is per workspace
• by splitting into many workspaces we can more easily apply access to people working on that code
• always create User Groups for each workspace and apply to repositories (can apply as default access), so can easily adjust who has access