Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 19 Next »

Target release2019-M1
Epic EDOP-70 - Getting issue details... STATUS
Document status
INPROGRESS
Document owner


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


Platform Repos:

Repo StructureBranching StrategyReview Process

Core:  DONE

  • egov-accesscontrol
  • egov-common-masters
  • egov-common-workflow
  • 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
  • telemetry
  • telemetry-kafka-streams

  • Anything in MASTER is deploy-able, all CI/CD pipelines are only from master.
  • Developers are expected to have short-lived feature & hotfix branches which are then merged onto master via PR.
  • Forking workflow is a convenient way to share branches with 3rd party/open-source developers.
  • 3rd party developers follow Forking Workflow, they are pulled into developer’s local repository.

  • 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:

  • Master branch holds the core code and will maintain it own release and review cycle.
  • Developers are expected to have short-lived feature & hotfix branches which are then merged onto master via PR.
  • Forking workflow is a convenient way to share branches with 3rd party/open-source developers.
  • 3rd party developers follow Forking Workflow, they are pulled into developer’s local repository.


  • 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


Libraries:   DONE

  • mdms-client
  • tracer
  • services-common

  • Developers are expected to have short-lived feature & hotfix branches which are then merged onto master via PR.
  • The repository hosts common libraries which are used across core and business modules.
  • The modules hosted in the repo are usually built and artefacts published to Nexus / Artifactory which are then re-used by other modules.
  • Artefacts release and versioning strategies to be followed strictly. 


  • 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

Municipal services:   DONE

  • Property Tax


  • Trade License


  • PGR



  • Modules are expected to have hooks through which state specific requirements can be met via sidecars rather than introducing the changes into the platform code-base itself.
  • Each of the feature module repos are to contain some sort of deployment packaging to help implementation teams / partners get up and running quickly. (Helm is one such)
  • States can opt to eject out from the platform's release by forking the repository and make any changes in forked repository and handle releases independently.
  • Such forked repositories can sync with upstream and stay up to date with the platform's releases.


  • 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



InfraOps: (Private)   DONE

  • Kubernetes manifests
  • Infra configs
  • nginx config
  • kibana config
  • Dockerfiles
  • Jenkins


  • The repository will contain all devops related source code (GitOps) such as kubernetes manifests, configs etc.
  • State or individual deployments is handled by one file per deployment, which in turn affects all other manifests.
  • States can opt to eject out from the platform's release by forking the repository and make any changes in forked repository and handle releases independently.
  • Everyone creates pull request and only code-owners checks & approves merge to master. Everyone else can still comment.
  • Can elect state specific code-owners / implementation team who will be gatekeepers.

Doc:Swagger/Contracts/web  Done

  • Core
  • Business
  • Features
  • Web
  • Mob
  • Option to have it published in confluence


Frontend (UI):

  • citizen
  • employee
  • employee-tradelicence
  • ui-uploader
  • report

Frontend (Mobile):

  • PuraSeva, AP Municipal
  • PGR, mSeva


  • Modules are expected to have hooks through which state specific requirements can be met via sidecars rather than introducing the changes into the platform code-base itself.
  • States can opt to eject out from the platform's release by forking the repository and make any changes in forked repository and handle releases independently.
  • Such forked repositories can sync with upstream and stay up to date with the platform's releases.
  • States also have the option to use their own UI while using our APIs alone.
https://levelup.gitconnected.com/using-pre-commit-and-pre-push-git-hooks-in-a-react-project-6c83431ef2bd

Config-Files: (Common)

  • Seed files
  • Migration files 
  • Persister  – Service repo
  • Indexer - Service repo







State or Implementation Team Repos:

Repo StructureBranching StrategyReview Process

State Extentions:

  • rainmaker-custom-service
  • custom-js-css-injection
  • egov-custom-consumer + CE
  • collection-receipt-voucher-consumer +CE
  • water wtms +CE
  • severage stms +CE
  • BPA/DCR +CE
  • finance +CE


  • The repository hosts extensions which exist to carry out state specific requirements but are not common enough to be part of the platform.
  • This repository is entirely state specific and is not part of the platform.


  • Everyone creates pull request and only code-owners checks & approves merge to master. Everyone else can still comment.
  • Can elect state specific code-owners who will be gatekeepers.

MDMS Data :

  • Role Actions
  • Feature Module Masters
  • Business Module Masters
  • Tenant Data
  • Location Data


  • The repository contains various master data which enable the functioning of core and business modules.
  • The config files in this repository are pulled into the deployment directly and hence it also makes sense to have a separate repo or branch for environments such as UAT & PRD.
  • This repository is state specific and is not part of the platform, although a repo with sample data will be maintained for DEV & QA.


  • Everyone creates pull request and only code-owners checks & approves merge to master. Everyone else can still comment.
  • Can elect state specific code-owners / implementation team who will be gatekeepers.
  • JSON format check is mandatory and runs as part of every pull request.

Config-Files: 

  • Seed files
  • Migration files 
  • Persister
  • Indexer


  • The repository maintains a folder based structure and holds DB migration seed files, module specific config files.
  • The config files in this repository are pulled into the deployment directly and hence it also makes sense to have a separate repo or branch for environments such as UAT & PRD.
  • This repository is state specific and is not part of the platform, although a repo with sample data will be maintained for DEV & QA.
  • Everyone creates pull request and only code-owners checks & approves merge to master. Everyone else can still comment.
  • Can elect state specific code-owners / implementation team who will be gatekeepers.


Action items

  • Branching strategies graphs
  • All repositories are to be private?
  • Digit open source fork from private repo
  • namespace sidecar





Task

Notes

1Break the repos as per the above and duplicate into the same or new org

Create a POC with the 


















Outcome

  • No labels