Closed wrichter closed 5 years ago
A single src tree is not enough. We probably need the above-mentioned structure per component. We also need to consider the triggering of builds of the individual components. If I see correctly, git webhook is project wide - so either we need projects per component, or a way to filter somehow.
We probably need to work with sub-modules or sub-projects on github.
Proposed new structure. Component Names are just a draft.
.
├── README.md
├── docs
│ ├── 00project
│ │ ├── developmentapproach.md
│ │ ├── projectcharta.md
│ ├── 10requirements
│ │ ├── model.md
│ │ ├── mvp.md
│ │ └── requirements.md
│ ├── 20architecture
│ │ ├── architecture.md
│ │ ├── componentmodel.md
│ │ ├── system\ context.md
│ │ └── technologies.md
│ ├── 30design
│ │ └── userinterface.md
├── build
│ ├── readme.md
│ ├── cicd
├── install
│ ├── readme.md
│ ├── install.sh
│ └── openshift
│ ├── main.yml
├── run
├── components (!!! each is a git Sub-Projects !!!)
│ ├── frontend-www
│ │ ├── doc
│ │ ├── api
│ │ ├── src
│ │ ├── tst
│ │ ├── build
│ │ ├── install
│ │ │ └── openshift.yaml
│ │ └── readme.me
│ ├── service-playlist
│ │ ├── doc
│ │ ├── api
│ │ ├── src
│ │ ├── tst
│ │ ├── build
│ │ ├── install
│ │ │ └── openshift.yaml
│ │ └── readme.me
│ ├── service-spotify
│ │ ├── doc
│ │ ├── api
│ │ ├── src
│ │ ├── tst
│ │ ├── build
│ │ ├── install
│ │ │ └── openshift.yaml
│ │ └── readme.me
│ ├── backend-kafka
│ │ ├── doc
│ │ ├── api
│ │ ├── src
│ │ ├── tst
│ │ ├── build
│ │ ├── install
│ │ │ └── openshift.yaml
│ │ └── readme.me
How do you intend to realise subproject - will these be separate GIT repos in the mw-sa-dach namespace?
Good Point! Options I see:
A: stay with mw-sa-dach org create additonal repos like opendj-service-spotify, opendj-frontend-www
B: move to new github org github.com/opendj Create Repos there with opendj/opendj opendj/frontend-www
I am inclined to go with B - move to the new org.
Ok, but why do you want to go multi-repo? the article you referenced seemed to suggest not to do it (but use git branches instead)?
I consider that branch approach confusing and complex, with a great risk of not being on the right branch. I think we dont have the issue with API definitions. APIs can be defined locally in the components (API dir), or centrally in the opendj/opendj/api project. Worst case we need to copy e.g. JSON Schema from to central project to the local one. I expect these to be quite stable and am fine with that, for the sake of simplification.
What we gain with multi-repo is that we can easily trigger re-build of that component using webhooks. That is very important to me. How would you solve that in single-repo approach?
suggest to do a full analysis of options and pro cons for each. Is there anything else beyond multi-repo and single-repo/multi-branch?
Multi-repo rids us of a single place to collect issues, might require a more complex project gating (#21), makes on boarding of new team members more complicated and possibly other aspects
Maybe for single-repo/multi-branch we could use the approach to trigger a build but abandon it if the branch was not pushed to as outlined here: https://stackoverflow.com/questions/46140233/github-webhooks-triggered-globally-instead-of-per-branch
I have no experience with multi-repo, so I will use the OpenDJ repo to try and experiment with that approach. Thanks for the issue collection topic, I did not think about that.
I am still inclined to go with the multi-repo/single-branch approach and switch to single-repo/multi-branch when we actually encounter a problem with api definitions. Sounds to me like an easy re-factoring.
Coming back to the original intention of this - any feedback on the actual dir structure?
No vetos regarding the structure. Structure is now implemented. Regarding Multi-Repo vs. Multi-Branching for Components/Microservices: I agreed with Ortwin that we start with Single-Repo to avoid complexity. The trigger problem will be solved somehow else, e.g. using a CI/CD Pipeline which inspects which component actually have been changed and triggers sub-chains only for changed components.
We need a good way to organize