Skip to content
Cuelogic
  • Services
        • Product Engineering
          • Product Development
          • UX Consulting
          • Application Development
          • Application Modernization
          • Quality Assurance Services
        • Cloud Engineering
          • Cloud Services
          • DevOps Services
          • Cloud Migration
          • Cloud Optimization
          • Cloud Computing Services
        • Data & Machine Learning
          • Big Data Services
          • AI Consulting
        • Internet of Things
          • IoT Consulting
          • IoT Application Development
        • Innovation Lab as a Service
        • Cybersecurity Services
        • Healthcare IT Services
  • Company
    • About
    • Culture
    • Current Openings
  • Insights
  • Tell Us Your Project
Tell Us Your Project  ❯
Product Development  3 Mins Read  January 16, 2017  Cuelogic Technologies

Multitenant Application and its Deployment

Share Via –
Share on facebook
Share on twitter
Share on linkedin

Home > Multitenant Application and its Deployment

How to Work with a Multi-Tenant Application Using Single Repository

The first blog of this series concerned our experience in working with multi-tenant applications. It went on to distinguish the use of single repository and multiple repositories. The prime question been, should everything be placed in a single github/svn repository or in separate repositories (tenant wise)? The following blog focuses on working with a multi-tenant application using a single repository.   

Multi-tenant application can be created by maintaining single repository with configurations.

Entire application is divided into minute features which can be enabled or disabled via configurations. It seems time consuming at the start or during development. But it makes the application very easy to manage in the longer run.

Once the entire feature is developed, updates are easily done without modifying the majority of the code. Whereas in multiple repository approach of multi-tenant application, updates can be made by making the same change in respective tenant’s repositories.

One of the greatest benefit of single repository approach is to have everything “configuration based”, so that adding a new tenant is a very simple process.

Also, tweaking the configuration for each client helps enable or disable certain features, instead of removing some functionality entirely from code base in multiple-repository approach.

Development phase:

  1. Need to be very careful about extracting features from application. Divide application in smaller features which can be enabled or disabled without having any impact on the application and other features.
  2. Caution while coding...execute code only if feature is enabled.
  3. Testing entire application with all possible values of the features (enabled/disabled).

My experience is, once you have proper setup with configuration, developing new features or adding new functionality for some set of tenants becomes very easy and manageable. Also tenant wise, we can have their own set of features and disable them when not needed, without affecting the other tenants.

Deployment:

Deployment of such applications as different instances for each tenant becomes critical, this is where Docker helps us. Each tenant has a code base on their own server and their own deployments. Docker helps us in sharing only specific tenant’s code from a single repository code base.

Approach we followed for deployment:

We have a single repository, with some architecture level changes to maintain feature-configuration and label file for each tenant. Those files are committed to git repository in their respective config folders (all the other code base remains common to all).

Following diagram depicts the applied sample code architecture for 2 tenants:

Multi-tenant Directory Structure
Applied sample code architecture for 2 tenants

The above described architecture helps developers to have an idea about features and labels of each tenant, rather than maintaining them as env files (As .env files are not committed and it becomes difficult to predict values for each tenant and identify the issues they are facing).

This architecture helps to maintain control of the features with us and discloses only required features to the tenant.

Following diagram demonstrates the approach we followed:

Multi-tenant-deployment
Multi-tenant Application and its Deployment

Pre-deployment processing on our Jenkins server:

  1. To run separate instances for each client, the first step was to separate out the code base with their own configuration.
  2. Running a script which could identify whether it has to replace the configuration file with tenant specific file or keep the default one. If tenant specific files are not found, default files would be taken and application will still run perfectly with the basic default configuration (With this, adding new tenant with default configuration became just a matter of a click).
  3. Once the code base is ready, all the pre-deployment processes are executed. 

Eg. running test case. On success or failure, Jenkins is setup to send mails to developers.

4. Create image for each tenant once pre-deployment is successful, and deployed to their respective docker hub account. After successful uploading of new image, respective tenants receive mail about new updates.

On client server:

  1. Client server needs to have Docker installed.
  2. Client can take pull of the latest image from their respective Docker-hub account.
  3. If container spins properly, application will run with the new changes, else application is rolled back to the previous running container with old image.

Summary:

Initial time spend during development has reduced our efforts in  the development cycle's later stages. Also the deployment process with Docker was a great experience and very suitable in a multi-tenant application with a single repository.

Recommended Content
Micro Frontend Deep Dive – Top 10 Frameworks To Know About ❯
Micro Frontends – Revolutionizing Front-end Development with Microservices ❯
Tags
docker multi-tenant application multi-tenant application with a single repository single repository
Share This Blog
Share on facebook
Share on twitter
Share on linkedin

Leave a Reply Cancel reply

People Also Read

Consulting

Top Technology Trends for 2021

10 Mins Read
DevOps

What is Infrastructure as Code and How Can You Leverage It?

8 Mins Read
Quality Engineering

Cypress vs. Selenium: Which is the Superior Testing Tool?

7 Mins Read
Subscribe to our Blog
Subscribe to our newsletter to receive the latest thought leadership by Cuelogic experts, delivered straight to your inbox!
Services
Product Engineering
  • Product Development
  • UX Consulting
  • Application Development
  • Application Modernization
  • Quality Assurance
Menu
  • Product Development
  • UX Consulting
  • Application Development
  • Application Modernization
  • Quality Assurance
Data & Machine Learning
  • Big Data Services
  • AI Consulting
Menu
  • Big Data Services
  • AI Consulting
Innovation Lab as a Service
Cybersecurity Services
Healthcare IT Solutions
Cloud Engineering
  • Cloud Services
  • DevOps Services
  • Cloud Migration
  • Cloud Optimization
  • Cloud Computing Services
Menu
  • Cloud Services
  • DevOps Services
  • Cloud Migration
  • Cloud Optimization
  • Cloud Computing Services
Internet of Things
  • IoT Consulting
  • IoT App Development
Menu
  • IoT Consulting
  • IoT App Development
Company
  • About
  • Culture
  • Current Openings
Menu
  • About
  • Culture
  • Current Openings
We are Global
India  |  USA  | Australia
We are Social
Facebook
Twitter
Linkedin
Youtube
Subscribe to our Newsletter

We don't spam!

cuelogic

We are Hiring!

Blogs
  • What is Infrastructure as Code and How Can You Leverage It?
  • Cypress vs. Selenium: Which is the Superior Testing Tool?
  • Micro Frontend Deep Dive – Top 10 Frameworks To Know About
  • Micro Frontends – Revolutionizing Front-end Development with Microservices
  • Decoding Pipeline as Code (With Jenkins)
  • DevOps Metrics : 15 KPIs that Boost Results & RoI
Menu
  • What is Infrastructure as Code and How Can You Leverage It?
  • Cypress vs. Selenium: Which is the Superior Testing Tool?
  • Micro Frontend Deep Dive – Top 10 Frameworks To Know About
  • Micro Frontends – Revolutionizing Front-end Development with Microservices
  • Decoding Pipeline as Code (With Jenkins)
  • DevOps Metrics : 15 KPIs that Boost Results & RoI
cuelogic

We are Hiring!

Blogs
  • What is Infrastructure as Code and How Can You Leverage It?
  • Cypress vs. Selenium: Which is the Superior Testing Tool?
  • Micro Frontend Deep Dive – Top 10 Frameworks To Know About
  • Micro Frontends – Revolutionizing Front-end Development with Microservices
  • Decoding Pipeline as Code (With Jenkins)
  • DevOps Metrics : 15 KPIs that Boost Results & RoI
Menu
  • What is Infrastructure as Code and How Can You Leverage It?
  • Cypress vs. Selenium: Which is the Superior Testing Tool?
  • Micro Frontend Deep Dive – Top 10 Frameworks To Know About
  • Micro Frontends – Revolutionizing Front-end Development with Microservices
  • Decoding Pipeline as Code (With Jenkins)
  • DevOps Metrics : 15 KPIs that Boost Results & RoI
We are Global
India  |  USA  | Australia
We are Social
Facebook
Twitter
Linkedin
Youtube
Subscribe to our Newsletter

We don't spam!

Services
Product Engineering

Product Development

UX Consulting

Application Development

Application Modernization

Quality Assurance Services

Cloud Engineering

Cloud Services

DevOps Services

Cloud Migration

Cloud Optimization

Cloud Computing Services

Data & Machine Learning

Big Data Services

AI Consulting

Internet of Things

IoT Consulting

IoT Application Services

Innovation Lab As A Service
Cybersecurity Services
Healthcare IT Services
Company

About

Culture

Current Openings

Insights
Privacy Policy  
All Rights Reserved @ Cuelogic 2021

Close

By continuing to use this website, you consent to the use of cookies in accordance with our Cookie Policy.