Versions Compared

Old Version 2

changes.mady.by.user Gajendran C (Unlicensed)

Saved on

compared with

New Version 3

changes.mady.by.user Gajendran C (Unlicensed)

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.


Info

Add your comments directly to the page. Include links to any relevant research, data, or feedback.

Page Properties
label


Status
Status
colourYellow
titleIn progress
Impact

Status
colourRed
titleHIGH
  

Driver
Gajendran C (Unlicensed) 
Approver
Contributors
Gajendran C (Unlicensed) Vasanth K.G. (Unlicensed) @shiva @nithin
Informed
Unknown user Dhananjay SinghUnknown userUnknown userUnknown userUnknown userUnknown userUnknown user
Due date
Outcome


...

Repo StructureBranching StrategyReview 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

New branching structureImage Modified

  • 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.
  • 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 and statesMaster & 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

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





...