You are viewing an old version of this page. View the current version.
Compare with Current
View Page History
« Previous
Version 4
Next »
Background
- Existing mono-repo is fattened, need to break it down into multiple mono repos and structure it to manage the open-source and the internal developer community.
- Need a simple and efficient branching strategy to handle core and state-specific changes.
- Enhance the code-review through pull requests.
Relevant data
Proposed Repository Structure: (Ranjeet's doc)
We will have a repository structure same as our layered architecture. We will have multiple repositories divide into followings:
1. Core/Infra
2. Business services [Collections, Billing etc]
3. Individual Modules [PT, TL etc]
4. MDMS
5. Front end (Single Repository with multiple module wise folders)
6. Config
7. Seed files for products
8. Config files for persister, indexer, report
9. Libraries [Tracer, mdms-client etc]
10. Docs → Swagger/Open API contracts, web sequence diagrams etc.
State Level:
- MDMS
- Config -- state level seed files
- Additional module customizations
- Front-End-UI
New structure:
| Repo Structure | Branching Strategy | Review Process |
|---|
Core: - egov-accesscontrol
- egov-common-masters
- egov-common-workflow
- egov-custom-consumer
- egov-data-uploader
- egov-filestore
- egov-idgen
- egov-indexer
- egov-localization
- egov-location
- egov-mdms-service
- egov-notification-mail
- egov-notification-sms
- egov-otp
- egov-persister
- egov-pg-service
- egov-searcher
- user-otp
- egov-user
- tenant
| 
- No other branches except MASTER, no state specific branch here
- Forking workflow is a convenient way to share branches with 3rd party/open-source developers.
- Everybody should still be using branches to isolate individual features
- 3rd party developers follow Forking Workflow, they are pulled into developer’s local repository.
- Anything in MASTER is deployable, all CI/CD pipelines are only from master.
| 
- Everyone creates pull request and only code-owners checks & approves merge to master. Everyone else can still comment.
- Can elect the code-owners based on tech/files or overall code base and architectural knowledge.
- Code quality check with codacy is mandatory and runs as part of every pull request.
- WIP: should be used when there are subsequent commits
- JIRA ticket should be prefixed as a topic name for the PR
- Anticipated PRs and the relevant discussions could be discussed on the daily SCRUM meetings.
- Authors, Reviewers, peers, approver
|
Business Modules: - hr-employee-v2
- hr-masters-v2
- collection-services
- billing-service
- egf-instrument
- egf-master
Feature modules: - pt-calculator-v2
- pt-services-v2
- tl-calculator
- tl-services
- rainmaker-pgr
- collection-receipt-voucher-consumer +CE
- water wtms +CE
- severage stms +CE
- BPA/DCR +CE
- finance +CE
| - Master branch holds the core/common code and will maintain it own release and review cycle.
- State branches are create from the master and continue as an isolated and specific custom code.
- Needing the reusable components, there could be the PR to share the code b/w Master & States.
| - There should be a codeowners who maintains master branch
- State teams also have designated codeowners including the
|
Doc:Swagger/Contracts/web - Core
- Business
- Features
- Web
- Mob
- Option to have it published in confluence
|
|
|
Web: - citizen
- employee
- employee-tradelicence
- ui-uploader
- report
| | https://levelup.gitconnected.com/using-pre-commit-and-pre-push-git-hooks-in-a-react-project-6c83431ef2bd |
Mob: (Android) - PuraSeva, AP Municipal
- PGR, mSeva
| |
|
Config-Files: (Private) - MDMS, MDMS client
- Seed files
- migration files ++ ap
- Persister
- Indexer
- JenkinsFiles ++ ap
- Dockerfiles ++ ap
- Tracers
|
|
|
Infra-services: (private) - zuul
- nginx --- seperate config for each service
- telemetry
- telemetry-kafka-streams
- rainmaker-custom-service
- es
- kibana
| |
|
|
|
|
Action items
Outcome
