search

sa-mw-dach / opendj

Apply Open Source principles to the Dance Floor! MOVED TO https://github.com/opendj/opendj
https://github.com/opendj/opendj
GNU General Public License v3.0
6 stars 9 forks source link

Define project Directory structure #22

Closed wrichter closed 5 years ago

wrichter commented 5 years ago

We need a good way to organize

DanielFroehlich commented 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.

DanielFroehlich commented 5 years ago

We probably need to work with sub-modules or sub-projects on github.

DanielFroehlich commented 5 years ago

Good readings: https://hackernoon.com/micro-services-git-d840305e6220 https://medium.com/@somakdas/code-repository-for-micro-services-mono-repository-or-multiple-repositories-d9ad6a8f6e0e

DanielFroehlich commented 5 years ago

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
wrichter commented 5 years ago

How do you intend to realise subproject - will these be separate GIT repos in the mw-sa-dach namespace?

DanielFroehlich commented 5 years ago

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.

wrichter commented 5 years ago

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

DanielFroehlich commented 5 years ago

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?

wrichter commented 5 years ago

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

DanielFroehlich commented 5 years ago

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?

DanielFroehlich commented 5 years ago

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.