GIT Repo Structure & Access

Owned by Anjoo Narayan
Last updated: Dec 10, 2020 by Malathi R. (Unlicensed)
3 min read

Overview

DIGIT is a microservice-based platform that is built to scale. It provides API based access to a variety of urban/municipal services. GIT hub as a DIGIT code repository holds multiple mono Repos with the simplified structure to manage the open-source and internal developer community. The core and state-specific changes are handled with a simple and efficient branching strategy.

Pre-requisites

Before you proceed with the configuration, make sure the following pre-requisites are met -

  • Prior knowledge of Git.

  • Prior knowledge of DIGIT architecture. 

Key Functionalities

  • DIGIT follows a layered architecture. Every layer consists of a set of microservices and we will have a repository structure same as our layered architecture.

  • Git being a DIGIT code repository provides an efficient branching strategy to handle core and state-specific changes and enhance the code-review through pull requests.

Deployment Details

Git is the form of the version control system, Continuous Integration(CI) and Continuous Delivery/Deployment(CD) setup with this git-flow is used for deployment.

Configuration Details

Gitflow is a very popular workflow that defines the different types of branches:

  • master: contains production code.

  • develop: contains the latest development changes that will be included in the next release.

  • feature: a new branch is created for each new feature we work on. We start it from develop and once we’re done, merge back into it.

  • release: starts from develop and signifies that there will be a new release once we merge this branch into master.

  • hotfix: used when we need to deliver urgent changes to our production app but develop is not yet ready to produce a release branch. Starts from master and merges into both master and develop.

Anything in the MASTER branch is deploy-able. Developers are expected to have hotfix/short-lived feature branches that are merged onto master via PR.

Git Access / Review Process:

  • Everyone creates pull requests 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.

  • State Specific Repos : Can elect state-specific code-owners / implementation team who will be gatekeepers.

We will have multiple repositories divide into the followings:

Repo Structure

Description

 core/Infra

This repo includes the following services :

egov-accesscontrol, egov-common-masters, egov-data-uploader, egov-enc-service, 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, egov-telemetry
egov-user, egov-workflow-v2, libraries, report, tenant, user-otp and
zuul

 Business Modules

This repo includes the following services :

  • billing-service

  • collection-services

  • egf-instrument

  • egf-master

  • egov-apportion-service

  • egov-hrms

  • finance-collections-voucher-consumer

Municipal services:

 

This repo includes the following services :

  • egov-user-event

  • property-services

  • pt-calculator-v2

  • pt-services-v2

  • rainmaker-pgr

  • tl-calculator

  • tl-services

Modules are expected to have hooks through which state specific requirements can be met rather than introducing the changes into the platform code-base itself.

MDMS (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.

Front end (Single Repository with multiple module wise folders)

  • 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 also have the option to use their own UI while using our APIs alone.

Config (Any other configurations - Centralised) 

  • Seed files

  • Migration files 

  • Persister  – Service repo

  • Indexer - Service repo

InfraOps (Kubernetes manifests, Infra/ngnix/kibana config, Dockerfiles and 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.

Libraries:  (mdms-client, tracer, services-common, enc-client)

The repository hosts common libraries which are used across core and business modules.

Docs:Swagger/Contracts/web 

  • Core

  • Business

  • Features

  • Web

  • Mob

  • Option to have it published in confluence

Reference Docs

Doc Links

Title 

Link

Title 

Link

 Git Strategy

 

 Github documentation and guide

 https://docs.github.com/en/free-pro-team@latest/github

Digit Architecture