INTERNSHIP REPORT OF END-OF-STUDIES PROJECT IN

COMPUTER ENGINEERING

Option: Software Engineering and DevOps

Title of the internship

Ensure the multi-tenancy of the LEANIOS MES across different environments

Elaborated by
Bassem GHARSELLAOUI

Host Company

LEANIOS

Internship Supervisor
Mr. Amine BELKHIRIA

SESAME Supervisor
Ms. Lobna KRIAA

i
 Contents
List of Figures .................................................................................................................................... iv
List of Tables ..................................................................................................................................... vi
Glossary of Acronyms ......................................................................................................................vii
General Introduction ......................................................................................................................... 1
CHAPTER 1 GENERAL CONTEXT OF THE PROJECT .......................................................... 3
1.1 | Introduction .............................................................................................................................. 3
1.2 | Presentation of the host organization ....................................................................................... 3
1.2.1 Overview............................................................................................................................ 3
1.2.2 Product Overview .............................................................................................................. 4
1.2.3 Organizational chart of LEANIOS .................................................................................... 7
1.3 | Presentation of the project ........................................................................................................ 8
1.3.1 Existent system Study ........................................................................................................ 9
1.3.2 Existing limits .................................................................................................................. 10
1.3.3 Proposed Solution: ........................................................................................................... 11
1.4 | Methodology of work ............................................................................................................. 15
1.4.1 Agile ................................................................................................................................ 15
1.4.2 The Y-shaped life cycle model ........................................................................................ 15
1.4.3 Work adaptation according to the Y model ..................................................................... 17
1.4.4 Project Breakdown........................................................................................................... 18
1.4.5 Formalism ........................................................................................................................ 18
1.5 | Conclusion .............................................................................................................................. 19
CHAPTER 2 PRELIMINARY STUDY ........................................................................................ 20
2.1 | Introduction ............................................................................................................................ 20
2.2 | Single-Tenant approach .......................................................................................................... 20
2.3 | Multi-Tenant approach ........................................................................................................... 21
2.3.1 Multi-Tenancy in Software Architecture ......................................................................... 21
2.3.2 Multi-Tenancy in Cloud Computing Services ................................................................. 21
2.3.3 Multi-Tenant SaaS Architecture Types ........................................................................... 22
2.3.4 Tenant Resolver ............................................................................................................... 23
2.4 | DevOps Concept ..................................................................................................................... 24
2.4.1 Key Elements of DevOps ................................................................................................ 24
2.4.2 Continuous Integration/Continuous Deployment ............................................................ 25
2.5 | The « Cloud Computing » Approach ..................................................................................... 27
2.5.1 Cloud services .................................................................................................................. 27
2.5.2 Cloud Deployment Models .............................................................................................. 29
2.6 | Containerization approach ...................................................................................................... 31
2.7 | Conclusion .............................................................................................................................. 32
CHAPTER 3 TECHNOLOGIES ................................................................................................... 33
3.1 | Introduction ............................................................................................................................ 33

i
 3.2 | Ruby On Rails ........................................................................................................................ 33
3.3 | PostgreSQL............................................................................................................................. 33
3.4 | RuboCop ................................................................................................................................. 35
3.5 | Git ........................................................................................................................................... 35
3.6 | Docker .................................................................................................................................... 36
3.7 | Kubernetes .............................................................................................................................. 36
3.8 | GitHub Actions ....................................................................................................................... 37
3.9 | Helm Chart ............................................................................................................................. 38
3.10 | Visual Studio Code ............................................................................................................... 38
3.11 | Visual Paradigm ................................................................................................................... 38
3.12 | Conclusion ............................................................................................................................ 39
CHAPTER 4 SPECIFICATION AND DESIGN .......................................................................... 40
4.1 | Introduction ............................................................................................................................ 40
4.2 | Specification ........................................................................................................................... 40
4.2.1 Analysis of functional and non-functional requirements................................................. 40
4.2.2 Functional Requirements ................................................................................................. 40
4.2.2.1 Hybrid multi-tenancy solution (POC) ............................................................................ 40
4.2.2.2 Deployments Management App (Leanios-org-ops) ....................................................... 41
4.2.3 Technical Requirements .................................................................................................. 41
4.2.4 Identification of Actors .................................................................................................... 42
4.2.5 Use cases diagrams .......................................................................................................... 43
4.2.5.1 POC (Hybrid multi-tenancy Solution) general use cases: .............................................. 43
4.2.5.2 POC Detailed use cases: ................................................................................................. 44
4.2.5.3 LEANIOS-org-ops general use cases ............................................................................. 45
4.2.5.4 LEANIOS-org-ops (Deployments management) Detailed use cases: ............................ 46
4.2.5.5 DevOps pipeline use cases.............................................................................................. 47
4.3 | Design ..................................................................................................................................... 48
4.3.1 Physical Architecture ....................................................................................................... 48
4.3.1.1 Hybrid multi-tenant system architecture ........................................................................ 49
4.3.1.2 CI pipeline architecture for Leanios deployments management App: ........................... 50
4.3.2 Software architecture ....................................................................................................... 51
4.3.2.1 GitHub software Architecture......................................................................................... 51
4.3.2.2 Kubernetes Software Architecture .................................................................................. 52
4.3.2.3 Helm Chart Architecture................................................................................................. 54
4.3.2.4 CI Pipeline Architecture of Leanios deployments management App ............................ 56
4.3.3 Detailed Architecture ....................................................................................................... 56
4.3.3.1 POC (Hybrid multi-tenancy Solution) Class diagram: ................................................... 57
4.3.3.2 Sequence Diagram of the use case << Create Company (Tenant) >> ............................ 57
4.3.3.3 Sequence Diagram of the use case << access to the app with subdomain >> ................ 59
4.3.3.4 Sequence Diagram of the use case << Execute migrations across databases >> ........... 59
4.3.3.5 LEANIOS-org-ops (Deployments management) Class Diagram: ................................. 61
4.3.3.6 Sequence Diagrams of the use case << Create New Company >> Leanios-org-ops: .... 62
ii
 4.3.3.7 Sequence Diagrams of the use case << Edit server >> Leanios-org-ops: ...................... 64
4.3.3.8 Sequence Diagram of the use case << Delete database >> Leanios-org-ops: ................ 65
4.3.3.9 LEANIOS-org-ops Deployment Diagram: ..................................................................... 66
4.3.3.10 CI Activity Diagram ..................................................................................................... 66
4.4 | Conclusion .............................................................................................................................. 68
CHAPTER 5 REALISATION ........................................................................................................ 69
5.1 | Introduction ............................................................................................................................ 69
5.2 | Implementation of POC (Hybrid Multi-Tenancy) .................................................................. 69
5.3 | Leanios-org-ops ...................................................................................................................... 73
5.4 | CI Pipeline: ............................................................................................................................. 78
5.5 | Minikube dashboard: ............................................................................................................. 82
5.6 | Conclusion .............................................................................................................................. 82
General Conclusion .......................................................................................................................... 83
Netography/Bibliography ................................................................................................................ 84

iii
 List of Figures

Figure 1-1 Company Logo .................................................................................................................................. 3

Figure 1-2 Product Planning interface ............................................................................................................... 5
Figure 1-3 Track Production .............................................................................................................................. 5
Figure 1-4 KPIs & Results ................................................................................................................................... 6
Figure 1-5 Ordering Orders................................................................................................................................ 6
Figure 1-6 Contents of stocks ........................................................................................................................... 7
Figure 1-7 LEANIOS Organigram ........................................................................................................................ 8
Figure 1-8 Multi-Tenant Architecture of the existent solution ......................................................................... 9
Figure 1-9 One shared database and multi-schema........................................................................................ 10
Figure 1-10 single tenant & multi-tenant app architecture [4] ....................................................................... 12
Figure 1-11 Proposed solution: multi-schema across multi databases........................................................... 13
Figure 1-12 The Y-shaped life cycle model .................................................................................................... 16
Figure 1-13 2TUP process ................................................................................................................................ 18
Figure 1-14 Gantt Diagram .............................................................................................................................. 18
Figure 2-1 Single Tenant Architecture [5]........................................................................................................ 21
Figure 2-2 Architecture of Multi-tenancy in cloud .......................................................................................... 22
Figure 2-3 Database-Per-Tenant ..................................................................................................................... 23
Figure 2-4 Private Tables per tenant ............................................................................................................... 23
Figure 2-5 Process DevOps .............................................................................................................................. 25
Figure 2-6 CI/CD Pipeline ................................................................................................................................ 26
Figure 2-7 Orchestration Architecture ............................................................................................................ 27
Figure 2-8 Cloud Computing- SaaS, IaaS, et PaaS ............................................................................................ 28
Figure 2-9 Cloud Deployment Models [6] ....................................................................................................... 29
Figure 2-10 « Software-As-A-Service [7] »....................................................................................................... 31
Figure 2-11 Container vs VM ........................................................................................................................... 32
Figure 3-1 Tenants schema within a PostgreSQL database [11] ..................................................................... 35
Figure 3-2 GitHub Actions workflow example ................................................................................................. 37
Figure 3-3 GitHub workflow Repository ......................................................................................................... 38
Figure 4-8 POC General use cases diagram ..................................................................................................... 43
Figure 4-11 Detailed use cases diagram for POC............................................................................................. 44
Figure 4-9 Deployment App General use cases diagram................................................................................. 45
Figure 4-16 Detailed use cases diagram for deployment app ......................................................................... 46
Figure 4-10 DevOps general use cases diagram .............................................................................................. 47
Figure 4-1 Hybrid multi-tenant architecture ................................................................................................... 49
Figure 4-2 Physical architecture of CI .............................................................................................................. 51
Figure 4-3 k8S architecture [19] ...................................................................................................................... 53
Figure 4-4 Helm Architecture .......................................................................................................................... 54
Figure 4-5 The structure of a regular Helm ..................................................................................................... 55
Figure 4-6 Config value for different environments of ROR app ..................................................................... 56
Figure 4-7 CI architecture ................................................................................................................................ 56
Figure 4-12 POC (Hybrid multi-tenancy Solution) Class diagram ................................................................... 57

iv
Figure 4-13 Sequence diagram <<create company(tenant)>> ........................................................................ 58
Figure 4-14 Sequence diagram <<access to the app with subdomain>> ........................................................ 59
Figure 4-15 Sequence Diagram of the use case << Execute migrations across databases >> ........................ 60
Figure 4-17 LEANIOS-org-ops Class diagram ................................................................................................... 61
Figure 4-18 Sequence Diagram << Create New Company >> ......................................................................... 63
Figure 4-19 Sequence Diagram << Edit server>>............................................................................................. 64
Figure 4-20 Sequence Diagram of the use case << Delete database >>........................................................ 65
Figure 4-21 Deployment diagram of Leanios-org-ops ..................................................................................... 66
Figure 4-22 CI Activity diagram........................................................................................................................ 67
Figure 5-1 add new company interface ........................................................................................................... 69
Figure 5-2 Companies List interface POC ........................................................................................................ 70
Figure 5-3 show company interface ................................................................................................................ 70
Figure 5-4 middleware file............................................................................................................................... 71
Figure 5-5 Custom migration file ..................................................................................................................... 72
Figure 5-6 Login Interface ................................................................................................................................ 74
Figure 5-7 Servers list interface ....................................................................................................................... 75
Figure 5-8 Edit server interface ....................................................................................................................... 75
Figure 5-9 Add database interface .................................................................................................................. 76
Figure 5-10 Edit database interface ................................................................................................................ 76
Figure 5-11 Company List interface ................................................................................................................. 77
Figure 5-12 Add company Interface ................................................................................................................ 77
Figure 5-13 Edit company interface ................................................................................................................ 78
Figure 5-14 Ci-development file ...................................................................................................................... 79
Figure 5-15 CI workflow on GitHub ................................................................................................................. 81
Figure 5-16 Helm chart repository structure................................................................................................... 81
Figure 5-17 Minikube Dashboard .................................................................................................................... 82

v
 List of Tables

Table 1 Postgres Schema vs Postgres Database .............................................................................................. 34

vi
 Glossary of Acronyms

2tup: 2 Track Unified Process

ERP: Enterprise Resource Planning

IaaS : Infrastructure-As-A-Service

MES: Manufacturing Executing System

PaaS: Platform-As-A-Service

ROR: Ruby On Rails

SaaS: Software-As-A-Service

SCM: Source Control Management

vii
 General Introduction
The influence of cloud computing and Software-as-a-Service (SaaS) in the enterprise software
domain has been steadily growing. SaaS is known for its ability to share computing resources and
offer software to various customers. To make the most of this capability, SaaS products need an
architecture that can handle the sharing of software instances and databases. This is where the
concept of multi-tenancy comes into play.

In the world of software architecture, multi-tenancy refers to the idea of serving multiple client
organizations through a single instance of a software product. Imagine one copy of the software
residing on the vendor's infrastructure, and multiple customers accessing and using that same
instance. What's interesting about multi-tenancy is that it allows for tailoring the software to meet
the specific needs of different customers. This contrasts with the traditional multi-user model,
where everyone gets the same standard offering. It’s a key factor for software vendors to increase
their profits by benefiting from economies of scale. In simple terms, it's a way for companies to
efficiently serve many customers, leading to higher profit margins.

Furthermore, multi-tenancy is not confined to specific resources, but is applicable at different levels
in a system's architecture, for example on a database or instance level. As a result, various
approaches to a multi-tenant architecture are possible.

In organizations committed to DevOps principles, development and operations teams collaborate

closely. This partnership streamlines the software development and deployment process, leading
to faster, more reliable releases and, most importantly, better communication. DevOps fosters
continuous improvement and automation, both of which are critical in managing the intricacies of
modern software systems. This seamless collaboration mirrors the integrated nature of cloud
computing and SaaS, where DevOps practices are often embedded, facilitating an agile and efficient
approach to software development and deployment.

Today, moving towards a culture of multi-tenancy and DevOps is at the core of LEANIOS strategies,
a culture well-applied on its cloud platform. It is within this framework that our End-of-Studies
Project takes place. Our goal is to enhance the level of multi-tenancy on this platform to achieve

1
exceptional scalability at the database level. Additionally, we aim to address the needs of certain
clients who require their own instance of this cloud platform, essentially extending LEANIOS solution
to support both multi-tenancy and single-tenancy concepts within this context. To accomplish this,
we will develop an application for managing the deployment of LEANIOS SaaS on the client’s servers.
Starting with Chapter 1, our report initiates with an exploration of LEANIOS, introducing the
company background, addressing prevalent issues, and outlining key project objectives. Chapter 2
seamlessly transitions to the preliminary study, where we define the various approaches employed
in our project. Moving forward to Chapter 3, we delve into the Specification and Design phase,
capturing both functional and technical requirements, and outlining the overall architecture and
design of our solution. Chapter 5 further expounds on the technologies and tools used. Then,
Chapter 6 shifts focus to the practical implementation of the project and finally, we conclude with
a general conclusion.

2
 Chapter 1 General Context of the Project

1.1 | Introduction
In this opening chapter, we will commence by conducting an initial analysis of our project. To get
started, we'll introduce the host organization for our graduation project—LEANIOS. highlighting the
areas in which it operates. Next, we will outline the current challenges facing the company, in order
to better understand the objectives of our work. Finally, we will detail the methodology used, the
work planning process as well as the formalism adopted to carry out our project.

1.2 | Presentation of the host organization

1.2.1 Overview

Figure 1-1 Company Logo

LEANIOS [1] is a Tunisian-German startup that appeared in January 2021, located in Blütenstr
15 c/o Base, 80799, Munich, Germany and within novation city Sousse technology parks. Specialized
in the digitalization of industrial processes such as MES (Manufacturing Executing System), ERP
(Enterprise Resource Planning) based on Lean manufacturing. LEANIOS GmbH has developed a
cloud-based production management platform "LEANIOS" used in manufacturing plants for
production planning, control and monitoring, which promotes:

• Planning:

o Tree nomenclature
o Multi-operations
o Capacities per line or machine
o Creating/Importing Production Orders
3
 o Order planning and tracking
o Inventory projection

• Scheduling and control:

Organize and dispatch the production orders necessary for the manufacture of the products,
taking into account production constraints.

o Scheduling Production Orders and Production Suborders

o Agile dispatching by Line, Team and Operator
o Account / Operator Terminal
o Real-time management

Production follow-up:

Follow production in near real-time with your PC or smartphone, wherever you are.

o Status/status of lines and machines

o Production Order Progress
o Production and shutdown history
o Machine and manpower duration
o Waste Rate and Material Consumption

1.2.2 Product Overview

• Plan, organize and manage
a. Import (ERP)/Create Production Orders
b. Scheduling & Dispatching
c. Control through terminals/operator accounts
d. Data Collection and Reports

4
 Figure 1-2 Product Planning interface

• Track production in real time

a. Dispatching of Production Orders
b. Made-to-order or stock-to-stock production
c. Follow-up of production reports
d. Traceability and batch management

Figure 1-3 Track Production

• Analyse KPIs and results

a. Multiple Dashboards
b. Automated, real-time calculations of results and KPIs
c. Hard Filters, Team, Operator, Line & Item
d. Function to compare selected durations.

5
 Figure 1-4 KPIs & Results

• Organize orders
a. Client Management
b. Sales Order Management
c. Kanban board
d. Delivery Times

Figure 1-5 Ordering Orders

6
 • Control inventory in real time
a. Multi-warehouses
b. Input / Output
c. Delivery Slips
d. Automation and Synchronization with Production

Figure 1-6 Contents of stocks

LEANIOS has an intelligent solution that ensures communication between the modules of the
factories containing all the functions and compatible with any type of hardware, whether tablets,
smartphones or PCs.

1.2.3 Organizational chart of LEANIOS

This organizational chart visually represents the hierarchical structure of LEANIOS
organization. with the CEO at the top. Each department is led by a chief, and within the Development
Department, there is the Product Development Team where I contribute. Additionally, I have
responsibilities within the Infrastructure Department and collaborate with the DevOps team.

7
 Figure 1-7 LEANIOS Organigram

1.3 | Presentation of the project

Multi-tenancy [2] is a software architecture model that's gaining prominence in the business
world, offering benefits such as cost-efficiency, resource optimization, and customization. It
facilitates multiple clients or users accessing a shared software instance while maintaining data and
functionality isolation.

For LEANIOS, the decision to enhance its multi-tenant solution stems from the need to
accommodate a growing user base. This enhancement will empower LEANIOS to scale efficiently,
providing personalized experiences for users while upholding data security and isolation. Such
evolution aligns with LEANIOS's commitment to meeting customer needs, optimizing resources, and
ensuring operational scalability.

Our project is aimed at addressing this requirement by adapting our architecture to meet the
new demands, advancing from a multi-schema approach to a multi-schema and multi-database
framework. In line with this objective, the project will now progress to the next phase where an
application will be developed to simplify the deployment of the LEANIOS application on dedicated
servers according to client requirements, leveraging CI/CD principles for an efficient and streamlined
process.

8
1.3.1 Existent system Study

Multi-tenant architecture involves serving multiple customers using a single instance of the
software and its supporting infrastructure. In this approach, each customer shares the software
application while maintaining data isolation from other tenants.

Figure 1-8 Multi-Tenant Architecture of the existent solution

The current system employs a multi-tenant approach using PostgreSQL, an open-source relational
database known for its extensibility. It leverages multiple schemas within the shared database,
ensuring data isolation among tenants as shown in the figure 1-9. The application relies on Ruby on
Rails, a web development framework known for its simplicity and convention over configuration,
and facilitates database connections and schema switching facilitated by the 'Apartment'1 gem.

1
THE 'APARTMENT' GEM IS A RUBY ON RAILS LIBRARY THAT PROVIDES DATABASE MULTI-TENANCY SUPPORT, ALLOWING DIFFERENT TENANTS
TO HAVE THEIR OWN SEPARATE SCHEMAS WITHIN A SHARED POSTGRESQL DATABASE.

9
 Figure 1-9 One shared database and multi-schema

1.3.2 Existing limits

In the following, we will describe the limitations of the current system in two parts: the constraints
of the multi-tenancy architecture in general, and the limitations of using a single database with
multiple schemas.

▪ Multi-tenant architecture limits:

⎯ Data Security and Compliance [3]: The client may have stringent data security and
compliance requirements, especially in highly regulated industries like manufacturing.
They may prefer to have complete control over their data and infrastructure to meet
industry 4.02 specific compliance standards.

⎯ Performance and Resource Control: In a multi-tenant environment, resource allocation

and performance can be less predictable, potentially leading to performance limitations
for specific clients.

2
"Fourth Industrial Revolution", "4IR", or "Industry 4.0" is a buzzword neologism describing rapid technological
advancement in the 21st century
10
 ⎯ Geographical Requirements: Multi-tenant apps might not always meet strict
geographical, or data localization requirements that single-tenant installations can
address.

▪ Multi-schema shared Database limits:

⎯ Scalability Limitation: Scaling a shared multi-schema database can be complex. As the

number of tenants grows, we may need to invest in more powerful hardware or consider
sharding the database. This can be challenging and may result in additional costs.

⎯ Data Isolation: While multi-schema databases provide data isolation at a logical level,
they may not offer the same level of security and isolation as separate databases. In
highly sensitive industries, such as defence or healthcare, regulatory requirements may
necessitate strict data separation.

⎯ Performance: As the number of tenants increases, the performance of a shared database

can degrade. Resource contention among tenants can impact query performance and
response times, especially if some tenants have large datasets or complex workloads.

⎯ Flexibility: Customizations on a per-tenant basis are harder to do unless they are

carefully designed upfront.

1.3.3 Proposed Solution:

In response to the identified limitations of the current system, we will present comprehensive
solutions in two parts. First, we will outline specific measures to optimize the utilization of a multi-
tenancy architecture. Following that, we’ll explore a strategy to overcome the general constraints
associated with a single database with multiple schemas approach.

➢ LEANIOS Core App Deployment on Dedicated Servers:

In response to the limitations of a multi-tenant architecture, we propose the

development of an application streamlines the LEANIOS cloud platform deployment onto
client's dedicated servers, which means implementing a single tenant architecture offering
an application instance per client as the figure 1-11 describe, to provide greater control
over their data and infrastructure, this approach caters to customers who require

11
 dedicated hosting solutions. Ensure the continued operation of the existing multi-tenancy
solution.

Figure 1-10 single tenant & multi-tenant app architecture [4]

This versatile approach offers several key advantages:

✓ Greater Control: Clients benefit from increased control over their data and
infrastructure. They can customize and manage their dedicated servers according to
their specific needs and preferences.

✓ Greater Isolation: Each client's data and application are isolated on their dedicated
server, preventing any interference or resource sharing with other tenants.

✓ Flexibility:

o This pattern makes it easy to customize the application on a per-tenant basis.

Customization needs may include tenant-specific field names, user interface
look-and-feel, business logic such as conditions for field updates, workflows,
etc.

12
 o It is easier to perform common maintenance operations on a per-tenant basis.
For example, upgrades to the application may be applied to different tenants
at different times.

✓ Data Backup and Recovery: Clients can implement their backup and disaster recovery
solutions to meet their unique needs.

➢ Combining Multiple Schemas and Multiple Databases approaches:

The solution involves adopting a flexible approach that combines the use of multiple
tenants within a shared database and, when necessary, multiple schemas across separate
databases. In this approach, each tenant may utilize their own dedicated schema within the
shared database in this case Tenant1 and Tenant2, or they can opt for their separate
database instance Tenant N case.

Figure 1-11 Proposed solution: multi-schema across multi databases

13
 This versatile approach offers several key advantages:

✓ Maintaining Existing System Stability: The existing system's value is acknowledged,

and we aim to ensure its uninterrupted operation. We will retain the multiple schema
structure within the shared database to keep the current system functional and stable.
This approach allows existing users and processes to continue working without
disruption.

✓ Leveraging Multiple Databases for Scalability and Customization: To enhance the

system's performance and provide more flexibility, we will implement multiple
databases. This enables us to cater to a broader range of client needs. For instance, for
clients with intensive data requirements or complex operations, we can allocate a
standalone database, ensuring optimal performance. Within these standalone
databases, clients can have multiple schemas customized to their specific
requirements.

Data can be partitioned to achieve scalability goals. For example, one can place
different databases into different disks. It also makes it easier to avoid reaching
database physical limits due to excessive table growth.

➢ Proof of Concept (POC):

Before fully committing to this approach, we recognize the importance of conducting a Proof
of Concept (POC). The POC will serve as a pivotal phase in our project, allowing us to rigorously
investigate the feasibility and practicality of this multi-schema, multi-database approach. During the
POC, we will create a controlled environment where we can evaluate the performance, and
manageability of this solution.

The POC will offer valuable insights and lessons, helping us refine and optimize our approach.
Any necessary adjustments will be integrated into the existing solution. This iterative process
ensures alignment with project requirements and tenant needs, reducing risks and ensuring a
successful implementation of our multi-schema, multi-database solution.

14
1.4 | Methodology of work
The choice of development methodology must consider the scope of the project and the
people involved, the time constraints and the tools available, and the specific features of the
architecture.

1.4.1 Agile
At the beginning of the project, the first thought is to try to anticipate everything, which

is not always possible and can sometimes lead to failure. We can therefore mention two

limitations of this predictive approach:

-Risk management: It is impossible to anticipate all risks as unforeseen events can occur

at any given time.

-Development of needs: The unpredictability of task development and the discovery of

new possibilities and ideas during a project make it impossible to accurately predict all

tasks and their execution methods. These challenges have compelled IT professionals to

reshape project management and design methodologies, leading to the development of

the agile method. Agile is an incremental, iterative, and collaborative approach were

projects are divided into multiple sub-parts. The responsible team gradually carries out

these parts, constantly readjusting objectives to meet customer expectations. Agile

methodologies foster improved relationships among project members, as well as between

the team and the client.

1.4.2 The Y-shaped life cycle model

The development process adopted to bring the project to a successful conclusion is the 2TUP
"2 Track Unified Process", which follows a Y-shaped life cycle. The "Unified Process" family provides
a common framework for integrating development best practices. A UP process is iterative and
incremental, architecture-centric, driven by user requirements, risk-driven and component-
oriented. The 2TUP process is in this vein, emphasizing the initial non-correlation of functional and

15
technical aspects. "2 Tracks" literally means that the process follows 2 paths. These are the
"functional" and "technical" paths, corresponding to the two axes of change imposed on the IS. The
two branches of study then merge to design the system, resulting in a Y-shaped development
process. The initial dichotomy enables business knowledge to be capitalized on the left-hand
branch, and technical know-how to be reused on the right-hand branch.

Figure 1-12 The Y-shaped life cycle model

• The left (Feature) branch includes:

⎯ Functional requirements capture, which produces a requirements model focused on

the user's business. It qualifies as early as possible the risk of producing a system
unsuited to users. For their part, the project managers consolidate the specifications
and check their consistency and completeness.

⎯ Analysis, which consists in studying the functional specification in detail, to get an idea
of what the system is going to achieve in business terms. The results of analysis are not
dependent on any technology.

• The right-hand branch of technical architecture encompasses:

16
 ⎯ The key steps involved in capturing the technical requirements and generic design of
an IT system. The first step is to identify all the constraints and choices influencing the
design of the system, considering the tools selected and the constraints of integration
with existing systems. These elements generally define the prerequisites of the
technical architecture.

⎯ The second stage is generic design, in which the components required to build the
technical architecture are defined. This design is independent of the functional aspects
of the system and aims to standardize and reuse common mechanisms throughout the
system. The technical architecture thus establishes the fundamental framework of the
IT system, while minimizing technical risks.

To guarantee the validity of the technical architecture, it is often advisable to produce

a prototype to confirm its feasibility and effectiveness.

• The middle branch includes:

⎯ Preliminary design: this delicate stage involves integrating the analysis model into the
technical architecture, to map out the system components to be developed.

⎯ Detailed design: this stage examines in detail how each system component is to be
implemented.

⎯ Coding: at this stage, the components are developed, and the code units are tested as
they are created.

⎯ Acceptance: This involves testing and checking that the system meets the specified
requirements.

1.4.3 Work adaptation according to the Y model

To illustrate this concept more clearly, we present below a diagram representing the cycle
followed throughout the implementation of our project according to the 2TUP methodology. This
diagram shows the various stages and successive iterations that characterize this software
development process.

17
 Figure 1-13 2TUP process

1.4.4 Project Breakdown

It is necessary to draw a diagram illustrating the distribution of tasks throughout the 7-month
project stage to better understand the time allocation related to the required work.

Figure 1-14 Gantt Diagram

1.4.5 Formalism
For the design of this project, we used UML (Unified Modelling Language) to describe
requirements, conceptualize the system and create software architecture sketches. The relevant
diagrams we used are:

• Use case diagram to identify developer requirements.

18
 • Deployment diagram to visualize interactions between objects over time.

• Activity diagram to represent the flow of actions.

• As well as class and sequence diagrams to describe the application's structure and
behaviour.

1.5 | Conclusion
In this first chapter, we have contextualized the project. We began by introducing the host
organization, followed by a presentation of the project problem and the objectives to be achieved.
Finally, we introduced the Y methodology, 2TUP, that we adopted for the development of our
solution, as well as the UML diagrams used to represent the functionalities to be developed. The
following chapter will be devoted to preliminary research aimed at deepening our understanding of
general concepts and examining existing techniques, in order to gain a better grasp of the project
as a whole.

19
 Chapter 2 Preliminary Study
2.1 | Introduction
In this chapter, we delve into fundamental concepts related to our work. We begin by
exploring the concepts of the multi-tenancy and DevOps approach, including virtualization,
containerization, and continuous integration/continuous deployment (CI/CD). Then, we describe
the orchestration and deployment strategies for our application. Finally, we address the design of
our application. This chapter will provide us with a thorough understanding of these key concepts
that are essential for the successful implementation of our project.

2.2 | Single-Tenant approach

In a single-tenant setup or single-tenancy architecture, each customer is provided with their
own dedicated software and infrastructure, offering a parallel to having an individual house in a
neighbourhood. This means that every customer has their exclusive software instance and
database, ensuring that their data is completely isolated from other tenants. It's like owning a house
where you can freely customize and decorate without affecting your neighbour’s. In the context of
single-tenancy SaaS, the software can be purpose-built for each tenant or offer post-installation
customization of the user interface (UI).

With a single-tenant system, each tenant's data is backed up separately, ensuring data
recovery in case of any loss. Tenants also have the flexibility to install available updates at their
convenience, rather than waiting for the service provider to do so. This architecture is often adopted
in cloud computing, especially in private cloud services or third-party cloud offerings. In such cases,
individuals or businesses are the sole customers with access to their specific instance, allowing for
individual security, management, and control, making it a popular choice for those seeking
dedicated and customizable software solutions.

20
 Figure 2-1 Single Tenant Architecture [5]

2.3 | Multi-Tenant approach

In the upcoming sections, we'll define multi-tenancy with three key areas: “Multi-Tenancy in
Software Architecture” and “Multi-Tenancy in Cloud Computing Services” and “tenant resolving
technics”.

2.3.1 Multi-Tenancy in Software Architecture

Multi-tenancy refers to the practice of several individuals with diverse needs sharing the same
software, often hosted in the cloud. Each user in this scenario is termed a "tenant." If users have
similar requirements, they can distribute the cost of the software, enhancing affordability. This
setup enables easy access, maintenance, configuration, and data interaction in a common database
on the same computer system. The architecture ensures data privacy and security for each user,
even though they share the same hardware and software resources.

2.3.2 Multi-Tenancy in Cloud Computing Services

In the realm of cloud computing, multi-tenancy is a crucial technique for delivering services
like Infrastructure as a Service (IaaS). IaaS involves the provision of computer infrastructure on a
rental basis and incorporates advanced features such as service level agreements, identity and
access management, fault tolerance, disaster recovery, and flexible resource allocation. Multi-

21
tenancy extends from the IaaS layer through the PaaS layer, providing a platform for application
development, and further into the SaaS layer, offering ready-to-use applications with business logic,
workflows, databases, and user interfaces. The figure 2-1 describe how multi-tenancy implemented
across the cloud services.

Figure 2-2 Architecture of Multi-tenancy in cloud

2.3.3 Multi-Tenant SaaS Architecture Types

There’re two multi-tenant models worth considering:

Database-per-tenant: In this model, each tenant receives a dedicated database. The application
tiers can scale either vertically (augmenting resources per node) or horizontally (increasing node
quantity). Nevertheless, databases within the same resource groups can be partitioned into flexible
pools. Vendors have the ability to shift tenant databases among these pools to streamline resource
management as shown in Figure 2-2.

22
 Figure 2-3 Database-Per-Tenant

Database-Tables-Per-Tenant / Private Schema: In this approach we isolate tenant data from that
of others, but we consolidate database infrastructure for tenants.

Figure 2-4 Private Tables per tenant

2.3.4 Tenant Resolver

Tenant resolution is needed in multiple places. Here we consider only the entry point of the
SaaS application. Tenants can be identified through query parameters, host headers,
authentication, etc.

• Manual Selection After Authentication: In this method. The application would then be
available to all tenants through the same URL, such as http://saas.example.org. SO, until the
user is authenticated, the application is generic. Only after authentication is a tenant
resolved and a tenant-specific user interface can be made available.

23
 • Automatic Selection by Subdomain: This is the most user-friendly option, which is adopted
also in LEANIOS platform but it's more advanced. Users just open the application in their
browser, log in, and the system takes care of the organization selection in the background
without them noticing the authentication process. For example:

http://tenant1.example.org

http://tenant2.example.org

• Sub-Directory per Tenant:

Segment the application by a tenant-specific sub-directory. We have the same domain for all
tenants, with a tenant-specific sub-directory. A variant is when tenant ID is passed as a query
parameter. For example

https://example.org/tenant1

https://example.org/tenant2

2.4 | DevOps Concept

DevOps, a portmanteau of "Development" and "Operations," is an approach based on a set of
practices aimed at promoting communication, collaboration, and integration between software
developers (Dev) and IT operations (Ops) within a single platform. By simplifying the relationships
between these stakeholders, it becomes easier to iterate rapidly in deployment phases while
improving reliability through the automation of tasks such as unit testing, machine configuration
management, and deployment. This system aims to enhance team productivity and strengthen the
ability to deliver applications and services, making it more competitive in the market.

2.4.1 Key Elements of DevOps

DevOps describes and systematizes the development process for building, testing, and
delivering a product quickly and reliably. It typically relies on five fundamental pillars,
represent in Figure 2-5:

✓ CI (Continuous Integration): This is the practice of frequently merging code changes

made by developers into a shared repository. This helps quickly detect any integration
issues.

24
 ✓ CD (Continuous Delivery): This is the ability to deliver code changes quickly and in an
automated manner, ensuring efficient software deployment.

✓ Containerization: This is the practice of encapsulating an application and its

dependencies in a lightweight and portable container, enabling more efficient
management of development and deployment environments.

✓ Continuous Monitoring: This involves using tools and practices to continuously

monitor the operation of the application, detect issues, and make real-time
adjustments.

Figure 2-5 Process DevOps

2.4.2 Continuous Integration/Continuous Deployment

The CI/CD approach addresses the challenges associated with integrating new code segments
for development and operations teams. It enhances the frequency of application delivery through

25
the automation of development stages. The core concepts of the CI/CD approach include
continuous integration, continuous delivery, and continuous deployment.

Figure 2-6 CI/CD Pipeline

▪ Continuous Integration (CI)

Developers practicing continuous integration regularly merge their changes into the main branch.
These modifications are validated by creating a version and running automated tests. This approach
prevents integration issues that occur when changes are merged only during the release.
Continuous integration places emphasis on test automation to ensure that the application remains
unaffected with each new commit integrated into the main branch.

▪ Continuous Deployment (CD)

Continuous delivery extends continuous integration by enabling the swift and dependable
release of new changes to clients. It automates the release process, making it possible to deploy an
application with a single click at any time. In practice, quick releases are preferred for easy issue
resolution.

Continuous deployment takes it a step further by automatically transmitting each change that
passes all stages of the production pipeline to clients without human intervention. Only failed tests
block deployment, which speeds up client feedback and eases the development team's burden.

The orchestration approach automates the deployment, management, scaling, and

networking of containers. It simplifies the handling of complex tasks and workflows within the IT

26
service. This approach is especially valuable in complex IT environments with numerous containers
and Linux hosts.

Orchestration combines automation tasks and their configurations across various machine
and system groups, streamlining the management of the mobile components of the IT environment.
Here is a general orchestration architecture diagram.

Figure 2-7 Orchestration Architecture

2.5 | The « Cloud Computing » Approach

The "Cloud Computing" approach, or cloud computing, is a technology that enables access to
data or infrastructure through a simple internet connection. Data is managed by remote
servers, eliminating the need for local installation or configuration. The concept of the "cloud"
represents the dematerialization and virtualization of data on the internet. In other words, it
allows access to any data from anywhere. With Cloud Computing, users can store, manage,
and access their data flexibly and conveniently, without having to worry about the underlying
infrastructure.

2.5.1 Cloud services

In practice, Cloud Computing offers various services in the form of subscriptions:

27
Infrastructure as a Service (IaaS): This service provides the IT infrastructure, which includes resource
virtualization such as servers, storage, and networks. Users can remotely manage and control these
resources without the need to worry about purchasing, configuring, or physically maintaining
hardware.

Platform as a Service (PaaS): This service provides a development and execution platform for
applications. Developers can create, test, and deploy applications without having to worry about
managing the underlying infrastructure. PaaS platforms offer tools, libraries, and frameworks to
facilitate application development and integration.

Software as a Service (SaaS): This service offers ready-to-use software applications accessible
through the cloud. Users can easily access these applications through a web browser without the
need to install or manage software locally. Software updates and maintenance are handled by the
service provider.

Figure 2-8 Cloud Computing- SaaS, IaaS, et PaaS

28
2.5.2 Cloud Deployment Models
To define various cloud computing service models, it's important to address two key
questions:

— Who is responsible for cloud management? A company can choose to handle the
management of the entire cloud with its own resources, or it may prefer to delegate this
management to an external partner.

— Who are the clients of the services provided by the cloud? The company can be the sole
user of the cloud services, or these services can be accessible and open to third parties such as
partners, customers, subsidiaries, etc.

The answers to these two questions will facilitate the understanding of the four deployment
models defined by the NIST standard and represented in the following figure:

Figure 2-9 Cloud Deployment Models [6]

— Public Cloud: Managed externally, for public use. The cloud infrastructure is accessible to
the public and located at the cloud provider's premises. It can be owned, managed, or operated by
a commercial, academic, or government organization. This model offers the highest level of
resource sharing for its customers, making it the most economically attractive option. However, it
comes with security and potential data confidentiality concerns as trade-offs.

29
 — Private Cloud: Managed internally, for private use. The cloud infrastructure is exclusively
for the use of a single organization but may potentially serve multiple consumers, such as various
operational units. It can be managed, owned, or operated by the organization itself (internal private
cloud) or by a third party (external private cloud). The infrastructure can be either on-site or off-
site. A private cloud allows for the optimization of internal resources utilization and the
sustainability of the infrastructure. However, the internal cloud solution is heavily debated, as it may
not provide significant added value compared to traditional infrastructures.

— Community Cloud: Managed internally, for public use. The cloud infrastructure is for the
exclusive use of a community that includes multiple consumers from different organizations with
common interests (e.g., security, compliance requirements, etc.). Like a Private Cloud, the
infrastructure can be managed, owned, or operated by one or more of these organizations or by a
third party and can be on-site or off-site.

— Hybrid Cloud: Managed externally, for private use. The cloud infrastructure consists of two
or more clouds (private, community, or public), which remain distinct entities but are connected by
standardized or proprietary technology, enabling data or application portability (technically known
as "load balancing" for load distribution). This cloud model is the most commonly used by
businesses. The relationship with the provider is essential and ensures data security and service
quality.

Software as a Service (SaaS) is the delivery and management of software applications via the
cloud, rather than through.

manual installation and configuration. With SaaS, applications are hosted and maintained by
external providers, eliminating the need for in-house management and infrastructure setup.

By encapsulating software and making it available through the cloud, users can access
applications from any location with internet connectivity. Software updates and maintenance are
handled by the service provider, ensuring a seamless user experience.

In practical terms, SaaS provides various software applications through subscription models,
allowing businesses to leverage a wide range of applications. This model greatly enhances efficiency
and can reduce the total cost of ownership for software applications, making it an attractive choice
for many organizations.
30
 The key advantage of SaaS is that it enables businesses to focus on their core activities, rather
than dealing with software deployment and maintenance.

Why SaaS is important in the approach of multi-tenancy?

Software as a Service (SaaS) plays a crucial role in the multi-tenancy approach by enabling
multiple tenants or users to share and access the same software application from a centralized cloud
infrastructure. This approach optimizes resource utilization, cost-efficiency, and scalability, as the
software is designed to serve various tenants simultaneously. SaaS applications are architected to
provide secure, isolated environments for each tenant, ensuring data privacy and customization
while benefiting from economies of scale. By pooling resources and maintaining a single codebase,
SaaS providers can efficiently update and enhance the application, delivering consistent and
feature-rich services to multiple tenants, making it a highly efficient solution for businesses seeking
cost-effective and scalable software access.

Figure 2-10 « Software-As-A-Service [7] »

2.6 | Containerization approach

The concept of containerization allows the utilization of the host system's kernel, eliminating
the need to install a new operating system, as required for virtual machines. This approach

31
minimizes resource wastage because each container only contains the application and its associated
binary files or libraries. Consequently, the same host operating system (OS) can be used for multiple
containers. Containerization simplifies the mobility of virtual applications between identical
operating systems and requires fewer storage, RAM, CPU resources, etc. The following figure
provides a comparative diagram between a virtual machine and a container.

Figure 2-11 Container vs VM

2.7 | Conclusion
In this chapter, we've introduced the fundamental concepts of our project, such as multi-
tenancy and DevOps. We've highlighted the importance of multi-tenancy architecture for SaaS
platforms, discussed their key features, and explained the differences between multi-tenancy and
single-tenancy approaches. We've also covered continuous integration, continuous delivery, and
continuous deployment. Finally, we've defined the concepts of containerization and orchestration.

Now, we're moving on to the first practical step of our project, which involves analysing and
specifying both the functional and non-functional requirements and the design.

32
 Chapter 3 Technologies

3.1 | Introduction
After finishing the preliminary study, the next step involves selecting the tools necessary to
implement the approaches outlined in the study.

3.2 | Ruby On Rails

Ruby on Rails is a server-side web application framework written in Ruby under the MIT
License. Rails is a model–view–controller framework, providing default structures for a database, a
web service, and web pages [8] [9].

Ruby on Rails, particularly with the "Apartment" gem, simplifies multi-tenancy by effortlessly
managing separate schemas within a single database or even across multiple databases on distinct
servers. This streamlined approach enhances scalability and maintenance, making it an ideal choice
for efficient and organized multi-tenant architectures.

3.3 | PostgreSQL
PostgreSQL, also known as Postgres, is a free and open-source relational database
management system emphasizing extensibility and SQL compliance. It was originally named
POSTGRES, referring to its origins as a successor to the Ingres database developed at the University
of California, Berkeley [10].

Ruby on Rails, paired with PostgreSQL, excels in crafting robust multi-tenancy solutions.
PostgreSQL's native support for schemas aligns seamlessly with Rails, facilitating efficient isolation
of tenants within a single database. This combo ensures simplicity in development, robust security,
and streamlined scalability, making it an ideal choice for building agile and effective multi-tenant
applications.

• Difference Between Postgres Schema (private schema) vs Database

Here is a summarized table outlining the key distinctions between a Postgres schema and a
database:
33
 Postgres Schema Postgres Database

A container for a set of tables and other A collection of schemas and other related data
database objects structures

Provides a way to organize and group related Provides a way to manage and access all the
tables schemas and other data structures within the
database

Allows for multiple schemas to exist within a The highest level of organization in a Postgres
single database, each with its own set of tables database, containing all the schemas, tables,
and other objects and other objects

Can be used to group tables by functional area Can be used to separate different applications
or department or projects within an organization

Tables in different schemas can have the same Schemas within a database cannot have the
name without causing naming conflicts same name

Can be used to set different access permissions Can be used to set different access permissions
for different groups of tables for different users or roles

Table 1 Postgres Schema vs Postgres Database

It’s important to note that a schema is a logical container within a database, it is used to
organize tables and other objects as shown in the next figure3-1, and provide a way to separate
different functional areas, while a database is a physical container that provides a way to manage
and access all the schemas and other data structures within the database.

34
 Figure 3-1 Tenants schema within a PostgreSQL database [11]

3.4 | RuboCop

Robocop is a Ruby code style checker (linter) and formatter based on the community-driven.
Robocop is extremely flexible and most aspects of its behaviour can be tweaked via various
configuration options. In practice Robocop supports pretty much every (reasonably popular) coding
style. Apart from reporting problems in the code, RuboCop can also automatically fix some of the
problems automatically [12].

3.5 | Git
Git is a free and open-source tool for tracking changes in software code. It was created by
Linus Torvalds in 2005. Unlike older systems like SVN and CVS, Git is distributed, meaning each
developer has a complete history of their code on their local machine. While the initial copy of the
code might take a bit longer to download, operations like commit, blame, diff, merge, and logs are
much quicker.

Git is great for handling branches, merges, and rewriting the history of a code repository. This
flexibility has led to creative workflows and tools. Pull requests, a popular tool, help teams
collaborate on different branches and review code efficiently. Git is the most widely used version
control system globally and is considered the modern standard for software development [13].

35
3.6 | Docker
Docker [14] is a free containerization platform that lets you bundle your application and all its
needs into a standardized package known as a container. Containers are lightweight, making them
easy to move around, and they're separated from both the underlying infrastructure and other
containers. You can run a Docker image as a Docker container on any machine with Docker installed,
regardless of the operating system.

Docker is powerful because of these reasons:

Portability: Easy movement of applications across different environments.

Reproducibility: Consistent behaviour and performance, regardless of where it runs.

Efficiency: Efficient use of system resources, as containers share the same OS kernel.

Scalability: Simple scaling up or down of applications by adjusting the number of containers.

3.7 | Kubernetes

Since in our project we will run our Leanios deployment on Kubernetes cluster, it is important
that we choose the right technology to support our efforts. In this case, the most

important technology to consider is Kubernetes. Kubernetes, an advanced container

orchestration platform [15], offers a range of crucial functionalities and features essential for
effectively managing large-scale containerized applications. Key highlights of Kubernetes
comprise:

•Automation: Kubernetes offers automated deployment and scaling capabilities, allowing

containerized applications to be deployed and scaled effortlessly according to predefined
rules and resource usage.

•Reliability: With its self-healing capabilities, Kubernetes incorporates inherent mechanisms

to detect and replace failed containers as well as reschedule them automatically. This ensures
uninterrupted application availability and reliability.

36
 •High performance: Service discovery and load balancing in Kubernetes enable the automatic
exposure of applications to external users using DNS names and the distribution of traffic
across multiple containers.

3.8 | GitHub Actions

GitHub Actions [16] is a continuous integration and continuous delivery (CI/CD) platform
that allows us to automate the build, test, and deployment pipeline. We can create workflows
that build and test every pull request to our repository, or deploy merged pull requests to
production.

GitHub provides Linux, Windows, and macOS virtual machines to run the workflows, or we
can host our own self-hosted runners in a data center or cloud infrastructure.

We can configure a GitHub Actions workflow to be triggered when an event occurs in our
repository, such as a pull request being opened or an issue being created. Our workflow
contains one or more jobs that can run in sequential order or in parallel. Each job will run
inside its own virtual machine runner or inside a container and has one or more steps that
either run a script that we define or run an action, which is a reusable extension that can
simplify our workflow.

Figure 3-2 GitHub Actions workflow example

A workflow is an automated process defined by a YAML file in our repository’s.

GitHub/workflows directory as shown in the figure 3-7. It runs one or more jobs triggered by events
inside the repository, or manually, or on a set schedule. Repositories can have multiple workflows,

37
each handling specific tasks. For instance, one can build and test pull requests, another can deploy
the application with each release, and yet another can label new issues.

Figure 3-3 GitHub workflow Repository

3.9 | Helm Chart

A Helm chart [17] is a package format used in Kubernetes for defining, installing, and
upgrading even the most complex Kubernetes applications. It contains pre-configured Kubernetes
resources, such as deployments, services, and ingress rules, packaged together. Helm charts simplify
the deployment process by allowing users to define, version, and manage Kubernetes applications
as a single, deployable unit. Helm, the package manager for Kubernetes, helps streamline
application management, making it easier to share, reuse, and maintain Kubernetes configurations
across different environments.

3.10 | Visual Studio Code

Visual Studio Code is a lightweight yet powerful source code editor available on Windows,

macOS, and Linux. It comes with built-in support for Ruby on Rails.

3.11 | Visual Paradigm

It is an open-source online application for creating diagrams, offering a user-friendly interface

and a wide range of features. It supports real-time collaborative editing, allowing multiple
38
 users to work on diagrams simultaneously [18].

3.12 | Conclusion
As we conclude our exploration of technologies, each tool introduced plays a vital role in our
system's robust architecture. From the server-side web application framework, Ruby on Rails, to the
advanced container orchestration platform, Kubernetes, and the CI/CD automation with GitHub
Actions, these technologies collectively empower our project's development and deployment,
ensuring efficiency, scalability, and reliability.

39
 Chapter 4 Specification and Design
4.1 | Introduction
In this chapter, we will delve into two main sections. We will commence with the specification,
which encapsulates the analysis of needs. Following that, we will explore the design, encompassing
both the general architecture and the detailed architecture.

4.2 | Specification
Within this chapter, we introduce the diverse stakeholders involved in the project and define
their roles and responsibilities. We establish both the functional and technical requirements
essential for the subsequent design and development of the system. The analysis encompasses
functional needs for the Proof of Concept (POC) of a hybrid multi-tenancy solution and a solution
managing LEANIOS Cloud Platform deployment.

4.2.1 Analysis of functional and non-functional requirements

In this section, we will present the requirements analysis, which is the process of identifying
and documenting the needs of a system or product. These needs can be divided into two
categories: functional needs and non-functional needs.

4.2.2 Functional Requirements

We're looking at functional requirements here, which are crucial to meet the functionality
criteria of the solution. Through our investigation, we've pinpointed specific needs. It's worth
mentioning that we'll be dividing these functional requirements into two sections: the first set for
the Proof of Concept (POC) of the hybrid multi-tenancy solution, and the second set for the solution
tasked with managing the deployment of the LEANIOS Cloud Platform on dedicated servers.

4.2.2.1 Hybrid multi-tenancy solution (POC)

• Companies (Tenant) creation, edit and delete in the chosen database by the administrator.

• Tenants access their accounts through their designated subdomains.

• Tenant could manage their projects in their space.

40
4.2.2.2 Deployments Management App (Leanios-org-ops)
• Authentication.

• Servers Management.

• Companies Management.

• Databases Management.

• Automated deployment of LEANIOS platform on client dedicated server.

• Implementing CI pipelines for application:

- Creating a GitHub Actions Workflow to deploy application.

- Developing a generic Helm chart for the application.

- Deploying application from a generic Helm chart according to the desired specifications.

4.2.3 Technical Requirements

• Security and isolation:

o Data security is better with the multi-database approach. Now, each tenant has
their own database credentials. Even if there's a rare chance of a leak, not all
tenant data would be at risk. This is different from a single shared database
with the same credentials for everyone.

o In the deployments management app, only the administrator has access to log
in with the provided credentials.

o Each tenant has their dedicated database, enhancing security by preventing

cross-contamination of data. This approach guarantees that each client's
information remains strictly separated, contributing to a more resilient and
secure system architecture.

• Scalability:
Scalability sees a significant boost with the introduction of the multi-database solution.
Furthermore, adopting a single-tenant approach further enhances scalability as clients

41
 can host their LEANIOS Cloud Platform instances on private servers. This dual strategy
contributes to an overall more scalable and adaptable system.

• Flexibility:
Flexibility is guaranteed through the implemented multi-database and single-tenant
approach. Each tenant has a dedicated database, allowing for tailored configurations
and adaptable solutions. This flexibility enables the system to easily accommodate
diverse requirements, ensuring that each client's specific needs can be met without
affecting the overall system performance.

• Reliability:
We make sure everything works smoothly by being careful in how we set up the
system. Having separate databases for each tenant means that if something goes
wrong, it won't affect everyone, making the system more reliable. This way, any issues
that pop up won't cause big problems for everyone else, keeping things running
smoothly and reliably.

4.2.4 Identification of Actors

• Tenants: The tenants(clients) serve as the end users of our system, possessing specific
needs and requirements that must be met. They play a crucial role in providing
valuable feedback on the functionality and usability of the system.

• Administrator: The Administrator plays a vital role in the application, overseeing

company management and enabling or disabling functionalities for clients as required.
This involves managing access to different modules, ensuring flexibility and
customization based on the clients' needs. The Administrator actively maintains
system integrity, adapting it to dynamically meet the evolving requirements of the
clients.

• Team lead: A team lead is accountable for guiding and coordinating team efforts,
ensuring project goals are met while fostering a collaborative and productive work
environment. They play a pivotal role in aligning team members with the overall vision
and objectives, driving successful project outcomes.
42
 • It ops: bear the responsibility of deploying and maintaining the system. They
collaborate closely with developers to ensure a smooth deployment of the code and
swift resolution of any arising issues.

• Developer: The individuals who write and maintain the code that drives a system are
tasked with designing, constructing, testing, and troubleshooting software
applications. They bear the responsibility for the development and up- keep of the
software code.

4.2.5 Use cases diagrams

In the general use case diagram, we group the basic use cases to get an overview of how the system
works and to highlight the relationships between them. The overall use case diagram, as shown in
the following figures, illustrates the main functionalities that each solution's system can provide to
various actors.

4.2.5.1 POC (Hybrid multi-tenancy Solution) general use cases:

Figure 4-1 POC General use cases diagram

This use case diagram illustrates the fundamental interactions and functionalities within the
Proof of Concept (POC) system, involving three primary actors: Administrator, Tenant, and
Developer.

43
 ▪ Administrator:

Manage Companies: The Administrator actor is responsible for the creation, modification, and
oversight of companies within the system. This includes configuring company settings and ensuring
proper administration.

▪ Developer:

Create and Manage Databases: Developers play a crucial role in the system by creating and
managing databases. They have the authority implement, and maintain databases to meet the
specific requirements of the application.

▪ Tenant:

Access App with Subdomain: Tenants interact with the system through a subdomain,
accessing the application and its functionalities. They have the capability to manage projects.

4.2.5.2 POC Detailed use cases:

Figure 4-2 Detailed use cases diagram for POC

This detailed use case diagram elaborates on the interactions and functionalities within the
Proof of Concept (POC) system, with a focus on create, edit and delete operations for the three
primary actors: Administrator, Tenant, and Developer.

44
4.2.5.3 LEANIOS-org-ops general use cases

Figure 4-3 Deployment App General use cases diagram

This use case diagram outlines the key functionalities within the LEANIOS-org-ops system,
featuring the Administrator actor who plays a central role in managing companies, servers, and
databases, as well as initiating the deployment of the LEANIOS Cloud Platform on a server.

45
4.2.5.4 LEANIOS-org-ops (Deployments management) Detailed use cases:

Figure 4-4 Detailed use cases diagram for deployment app

As we can see in the Detailed use cases diagram, we can specify one actor:

• Administrator who can:

− Access to the management app after authentication. This user plays a central role in
managing various aspects of the system.
− Company Management:
▪ Create: Initiate the addition of new companies, supplying essential details like name
and subdomain.
▪ Edit: Modify existing company information to ensure accuracy and relevance.
▪ Delete: Remove companies from the system when they are no longer needed.
− Servers Management:
▪ Create: Authorize the inclusion of new servers, defining attributes such as name,
IP address, and configuration settings.

46
 ▪ Edit: Adjust server configurations or details to accommodate evolving
requirements.
▪ Delete: Eliminate servers that are obsolete or no longer serve a purpose.
− Databases Management:
▪ Create: Establish new databases, specifying parameters like name, port, and host.
▪ Edit: Make adjustments to the settings or structure of existing databases.
▪ Delete: Remove databases that are no longer relevant or necessary.
− Authentication: Before accessing the management app, the User Administrator
undergoes a secure authentication process to ensure the confidentiality and integrity of
the system.
− Deploy Leanios Cloud platform use case

4.2.5.5 DevOps pipeline use cases

Figure 4-5 DevOps general use cases diagram

47
 This use case diagram illustrates the collaborative workflow within the DevOps environment,
involving three key actors: IT Ops, Developer, and Team Lead. Each actor contributes to the efficient
development, deployment, and management of software projects.

▪ IT Ops:

Implement Infrastructure: Designs and supervises the infrastructure.

Manage DevOps Tools: Oversees and manages DevOps tools for smooth collaboration.

▪ Developer:

Create Merge Requests: Proposes code changes for review and integration.

Collaborate on Code: Works collaboratively using version control and DevOps tools.

▪ Team Lead:

Manage Merge Requests: Makes decisions on code integration, ensuring code quality.

Coordinate Team: Facilitates communication and collaboration within the team.

4.3 | Design
After analysing user requirements, we proceed to design the architecture of our system. This
phase falls between requirement specification and the implementation phase. The goal is to define
a functional implementation strategy that addresses identified constraints while optimizing the
system.

4.3.1 Physical Architecture

The physical architecture, also known as technical architecture, encompasses the hardware
components that support the application.

48
4.3.1.1 Hybrid multi-tenant system architecture

Figure 4-6 Hybrid multi-tenant architecture

In the multi-tenant system, the main identifier for identifying an organization

(tenant/customer) for virtual separation is sub-domain. Using a sub-domain each tenant is
identified at the application level and isolated data is served. In this way, each customer sees
their own version of the site customized by their admin.

To explain this process further let us consider a scenario in the figure 5-1,

49
 ⎯ A user loads a URL *.leanios.com in the browser.

⎯ Once a URL is loaded Leanios cloud platform mapped to the domain receives a request.

The application then resolves a tenant, finds the location of the database where
requested customer data is located.

⎯ After finding data application then processes a request, and returns the requested data
to the client.

⎯ Based on where the request comes (URL) a tenant is resolved and data for a particular
tenant is returned to the requested user.

4.3.1.2 CI pipeline architecture for Leanios deployments management App:

In our Solution, we have two main parts:

⎯ Developer machines: These are the physical machines used by developers to make
changes in the source code and develop new features for the application.

⎯ Cloud: This refers to a server environment accessible over the Internet, with software
and databases running on these servers.

This figure illustrates this physical architecture and the protocols used for communication
between the various components.

50
 Figure 4-7 Physical architecture of CI

4.3.2 Software architecture

In this section, we will examine in detail the software architecture of GitHub, our source code
management tool, as well as the architecture of the Kubernetes cluster responsible for deploying
Leanios Org Ops. We will then present an overview of our pipeline, highlighting the synchronization
and communication among all the tools used. The goal of this overall architecture is to create an
integrated CI chain, enabling us to achieve our objectives.

4.3.2.1 GitHub software Architecture

The software architecture of the GitHub server is based on a set of interconnected services that
work together to provide a robust source code management platform. Here are the main
components of the GitHub server's software architecture:

API: GitHub server exposes an API that allows users and third-party applications to interact
with the platform. The API provides functionalities for repository management, user management,
GitHub actions, issues, pull requests, etc.

Authentication and Authorization: GitHub server handles user authentication and

authorization for accessing repositories and specific features. Various authentication mechanisms
are supported, such as access tokens, SSH keys, etc.
51
 Repository Management: GitHub server stores source code repositories, including files,
branches, commits, tags, etc. It provides features for creating, cloning, merging, and managing
repositories.

Collaboration and Issue Tracking: GitHub offers advanced features for collaboration among
developers, such as issues, pull requests, discussions, comments, etc. These features facilitate team
coordination and issue tracking.

Continuous Integration and Continuous Deployment (CI/CD): GitHub provides built-in

features for continuous integration and continuous deployment, such as GitHub Actions. This
enables the automation of tests, builds, deployments, and development workflows.

Data Storage: GitHub server uses a storage system to store repository data, user data, issues,
etc. Storage systems like relational databases or distributed file systems can be employed based on
scalability and performance requirements.

The software architecture of the GitHub server is designed to deliver a seamless and
performant experience to users while ensuring security, collaboration, and continuous integration
in the software development process.

4.3.2.2 Kubernetes Software Architecture

In our project, we have decided, following a comparative study conducted in a previous
chapter, to utilize the renowned Kubernetes as an orchestration tool, whose architecture is outlined
below:

Master:

• Comprises the kube-api server, kube scheduler, cloud-controller-manager, and kube-

controller-manager.

• Proxies Kube and kubelets exist on each node, communicating with the API, and
managing the workload of each node.

Cloud-controller-manager:

• Operates in the control plane as a replicated set of processes (typically containers in

pods).

52
 • Connects clusters to the cloud provider's API and executes only cloud-provider-specific
controllers.

etcd:

etcd is a distributed key-value store and the primary data store for Kubernetes.

This Kubernetes architecture includes a control plane (Master) housing essential component,
a distributed storage system (etcd) to maintain the cluster's state, and a set of nodes
(Workers) briefly described above. The Master encompasses various components such as
kube-api server, kube scheduler, cloud-controller-manager, and kube-controller-manager,
while the cloud-controller-manager facilitates the connection to the cloud provider's API.
Lastly, etcd serves as the distributed key-value store, ensuring coherent data storage for
Kubernetes.

Figure 4-8 k8S architecture [19]

Kubelet:

• Functions as an agent within nodes, responsible for running pod cycles on each node.

• Monitors new or modified pod specifications from master nodes.

• Ensures that pods within its residing node are healthy and that the pod state aligns
with the pod specification.

53
 Proxy:

• Each computing node includes a network proxy called "kube-proxy," facilitating the
implementation of Kubernetes networking services.

• Manages network communications within and outside the cluster.

• Utilizes the operating system's packet filtering layer if available; otherwise, it handles
traffic itself.

Scheduler:

• Takes into account the resource needs (CPU or memory) of a pod.

• Plans the assignment of the pod to the appropriate computing node.

4.3.2.3 Helm Chart Architecture

Helm has a fairly simple client-server architecture, including a CLI client and an in-cluster
server running in the Kubernetes cluster:

Figure 4-9 Helm Architecture

54
 • Helm Client: Provides the developer to use it a command-line interface (CLI) to work
with Charts, Config, Release, Repositories. Helm Client will interact with Tiller Server,
to perform various actions such as install, upgrade and rollback with Charts, Release.

• Tiller Server: an in-cluster server in the Kubernetes cluster, interacting with the Helm
Client and communicating with the Kubernetes API server. Thus, Helm can easily
manage Kubernetes with tasks such as install, upgrade, query and remove for
Kubernetes resources.

Helm has 4 basic concepts:

• Chart: a collection of YAML files as shown in figure5-5, bundle of the Kubernetes

resources needed to build a Kubernetes application. For ease of visualization, Helm
Chart can be compared like a Docker Image. Of course, Helm also has a Helm Hub
where to search and share Charts for popular apps.

Figure 4-10 The structure of a regular Helm

• Config: a configuration in the values.yaml file figure4-6, which contains configuration

explicit to a release of Kubernetes application. It can be the config for service, ingress,
deployment, etc.

55
 Figure 4-11 Config value for different environments of ROR app

4.3.2.4 CI Pipeline Architecture of Leanios deployments management App

After explaining the different architectures of our tools implemented in our solution, we now
present our pipeline that will seamlessly interconnect these tools to establish continuous
integration for Leanios management deployment app.

Figure 4-12 CI architecture

4.3.3 Detailed Architecture

Within the detailed architecture, we will proceed with the design of our solution, employing
UML diagrams.

56
4.3.3.1 POC (Hybrid multi-tenancy Solution) Class diagram:

Figure 4-13 POC (Hybrid multi-tenancy Solution) Class diagram

These classes model a scenario where companies can be associated with multiple projects,
and each project is uniquely linked to a single company. Otherwise, the Company class represents
an organizational entity with attributes defining its identity and configuration, while the Project class
represents a specific project associated with a company, encapsulating details and actions related
to that project. The methods in each class reflect the actions and management operations
associated with companies and projects, respectively.

4.3.3.2 Sequence Diagram of the use case << Create Company (Tenant) >>
A sequence diagram visually represents the chronological flow of interactions between objects
or components in a system using UML, aiding in understanding dynamic behaviours and
communication patterns.

57
 Figure 4-14 Sequence diagram <<create company(tenant)>>

The Sequence Diagram for the <<Create Company (Tenant)>> use case illustrates interactions
between the administrator, middleware handling request resolution for each tenant, and the
company module components, including the apartment gem, library for multitenancy, and the
PostgreSQL database housing our schemas.

58
4.3.3.3 Sequence Diagram of the use case << access to the app with subdomain >>

Figure 4-15 Sequence diagram <<access to the app with subdomain>>

Initiated by the Tenant entering a subdomain URL, this sequence involves the Apartment Gem
parsing and configuring database connections. Switching to the tenant-specific schema, the
projects Controller efficiently loads the project list from PostgreSQL, streamlining the process
without direct interaction with the Gem.

4.3.3.4 Sequence Diagram of the use case << Execute migrations across databases >>
This sequence diagram addresses the challenge of efficiently applying database migrations
across multiple tenants in a multi-tenant Ruby on Rails application. By leveraging the capabilities
of the Apartment Gem, the task fetches tenant configurations from the Primary Database,
establishes connections to individual Tenant Databases, and applies migrations in a schema-
specific manner. This solution ensures the seamless execution of database migrations across
diverse tenants and databases within the application architecture.

59
Figure 4-16 Sequence Diagram of the use case << Execute migrations across databases >>

60
4.3.3.5 LEANIOS-org-ops (Deployments management) Class Diagram:

Figure 4-17 LEANIOS-org-ops Class diagram

61
 the Administrator class represents individuals overseeing deployment management. Each
Administrator has the capability to manage multiple servers, reflecting a one-to-many
relationship. Servers are associated with a specific Company, adhering to a one-to-one
relationship, and a Company, in turn, can possess multiple databases, establishing a one-to-
many relationship.

Furthermore, the relationship extends to the Database class, where one or many databases
can be hosted on server, forming a many-to-one relationship. This design allows for a flexible
and scalable deployment management system, accommodating the complex interconnections
between administrators, companies, servers, and databases within the LEANIOS
organizational operations framework.

4.3.3.6 Sequence Diagrams of the use case << Create New Company >> Leanios-org-
ops:
To initiate the deployment of the cloud platform for a company or client service, the sequence
diagram involves the following interactions within the Deployments Management Hub. The
Administrator triggers the <<Create Company (Tenant)>> use case, leading to the involvement of
the Companies section and Database components. The Administrator communicates with the
Companies section to create a new company, and subsequently, the database component is
engaged to set up the required database configurations. This sequence outlines the coordinated
efforts within the Deployments Management Hub to establish the necessary infrastructure for
deploying the cloud platform for a specific company or client service.

62
Figure 4-18 Sequence Diagram << Create New Company >>

63
4.3.3.7 Sequence Diagrams of the use case << Edit server >> Leanios-org-ops:

Figure 4-19 Sequence Diagram << Edit server>>

In the "Edit Server" sequence, an Administrator triggers the <<Edit Server>> use case,
interacting with middleware for request resolution. The middleware collaborates with the server
component to modify configurations as shown in figure 4-19. This sequence emphasizes the
streamlined process of adjusting server settings within the LEANIOS organizational operations
framework.

64
4.3.3.8 Sequence Diagram of the use case << Delete database >> Leanios-org-ops:

Figure 4-20 Sequence Diagram of the use case << Delete database >>

The Sequence Diagram for the <<Delete Database>> use case involves the Administrator
initiating the deletion process. The Administrator communicates with the middleware for
request resolution, which then orchestrates the deletion procedure with the database
component. This sequence illustrates the coordinated steps in removing a record within the
Deployments Management Hub, showcasing the interactions between the Administrator,
middleware, and database components.

65
4.3.3.9 LEANIOS-org-ops Deployment Diagram:

The diagram in Figure 4-22 shows how our solution works physically. It highlights the servers
we've set up and how they communicate. The diagram also includes the tools and virtual machines
we use to make everything run smoothly.

Figure 4-21 Deployment diagram of Leanios-org-ops

4.3.3.10 CI Activity Diagram

The activity diagram presented outlines the process of the "Continuous Integration" phase
and explains the interactions between different components.

66
 Figure 4-22 CI Activity diagram

➢ Textual Description:

⎯ Event Triggering:

An event is triggered in the GitHub repository, such as a code push.

Source Code Retrieval:

The source code is retrieved from the GitHub repository.

Install Dependencies:

If the workflow is triggered, the CI system initiates the installation of project dependencies
necessary for the build and test processes.

67
 Lint Code:

Assuming successful dependency installation, the system proceeds to lint the code using tools
like RuboCop to enforce coding standards.

Run Tests:

With successful linting, the system runs automated tests, typically using RSpec, to ensure the
correctness of the code.

Build Image:

The Docker image is built using a specified Dockerfile in the repository. This may involve
executing build commands, installing dependencies, and configuring the environment.

Push Image:

If the tests succeed, the Docker image is pushed to a Docker registry, such as Docker Hub. This
allows storing the image and making it accessible for subsequent deployment.

4.4 | Conclusion
In this chapter, we establish a comprehensive foundation for the project, outlining the key
stakeholders and their roles, as well as presenting a detailed analysis of functional and technical
requirements. The chapter delves into the identification of crucial actors such as tenant,
administrators, It ops, team lead and developers. The design is divided into General architecture
and Detailed architecture section provides a holistic view through use case diagrams, while the we
break down specific use cases with sequence and class diagrams. The focus on security, scalability,
flexibility, and reliability in technical requirements underscores the robustness of the proposed
solutions. Overall, this chapter serves as a crucial roadmap, guiding to the final part of our report,
which is the implementation of the various elements of the work.

68
 Chapter 5 Realisation
5.1 | Introduction
In this final chapter, we will cover the work done, explore the different steps to achieve the
final result by detailing each step, and include the necessary screenshots to explain the
implementation of our solutions.

5.2 | Implementation of POC (Hybrid Multi-Tenancy)

Our Proof of Concept (POC) encompasses three primary concepts to achieve the multi-schema
multi-databases solution:

Company Schema Creation: This involves creating a schema for each company in its dedicated database.

Figure 5-1 add new company interface

As a first step, we have the company page that allows us to add a new company (tenant) by
specifying their subdomain and the basic database configuration for that company. After

69
creating the company and invoking a callback, the system automatically creates the schema
in the specified database introduced in the input.

That’s the home page of our POC:

Figure 5-2 Companies List interface POC

This interface corresponds to the Show Company page:

Figure 5-3 show company interface

70
Middleware Connectivity: The middleware ensures that every tenant's request, based on
their subdomain, is directed to their respective database where their schema is hosted.

Figure 5-4 middleware file

Tenant then could access to their space and manage their projects.

71
Database Migrations Handling: The solution manages running database migrations on all the
schemas and databases connected to the application.

Figure 5-5 Custom migration file

Actor Initiation:

The Developer initiates the process by running the custom rake task (rake db: multi_server
[db: migrate]).

Task Runner Validation:

The Task Runner validates the presence of the specified task.

Task Presence Check:

If the specified task is not present, an error message is displayed to the Developer.

72
 Fetching Tenant Configurations:

If the task is present, the Task Runner communicates with the Apartment Gem to fetch
configurations for all tenants.

Fetching from Primary Database:

The Apartment Gem interacts with the Primary Database to obtain tenant configurations.

Tenant Configurations Returned:

The fetched tenant configurations are returned to the Task Runner.

Displaying Configurations:

The Task Runner displays the fetched configurations to the Developer.

Migration Loop for Each Tenant:

⎯ For each tenant, the Task Runner establishes a connection to the respective Tenant
Database.

⎯ The Developer is informed about the established connection.

⎯ The Task Runner switches to the specific schema for the tenant in the Tenant Database.

⎯ Database migrations (db: migrate) are executed for each tenant.

⎯ The Developer is updated with the result of each migration.

Re-establishing Connection to Primary:

After migrating all tenants, the Task Runner re-establishes the connection to the Primary
Database.

Task Completion Notification:

The Developer is notified that the task has been successfully completed.

5.3 | Leanios-org-ops
In this part of the solution, our focus is on developing the fundamental functionalities of the
application, laying the groundwork for managing the deployment of the Leanios Cloud Platform in
the future. Additionally, we've established a continuous integration (CI) process, a crucial aspect

73
during this development phase. Manual deployment has been performed locally on a Minikube
Kubernetes cluster.

This screenshot displays the administrator's login page:

Figure 5-6 Login Interface

Here, we can see the Servers section, presenting a list of servers with their parameters. You can
manage, edit, delete, or add servers.

74
 Figure 5-7 Servers list interface

This is the edit page, allowing us to modify server configurations:

Figure 5-8 Edit server interface

Moving on to the Databases section, we find a list of databases with their parameters. We can
manage, edit, delete, or add databases.

75
Here's the Add Database page:

Figure 5-9 Add database interface

Additionally, an Edit Database page is available for modifications:

Figure 5-10 Edit database interface

In the Companies section, a list of companies (tenants) is displayed with their parameters,
along with information on the associated server and connected databases.

76
 Figure 5-11 Company List interface

We can manage, edit, delete, or add companies. An additional action here is the "Deploy,"
which triggers the automatic deployment of the Leanios Cloud Platform on the dedicated server in
the background. Note that this feature is currently in progress and will be fully added in the future.
As of now, we've prepared the basic functionalities.

Figure 5-12 Add company Interface

77
 In the user interface for adding a new company, several key fields are present to capture
essential company details. These include the name, email, subdomain, and deployment information
fields. It's important to note that among these fields, the 'server' field is mandatory, indicating the
necessity of specifying server-related details during the company creation process. Ensuring
accurate input in all these fields is crucial for the successful addition of a new company to the
system.

Figure 5-13 Edit company interface

In the edit page interface, users can efficiently modify key company details such as name,
email, subdomain, and deployment. The 'server' field remains mandatory, even during edits,
emphasizing the continued importance of specifying server-related details for accuracy. This
streamlined process ensures precise updates while maintaining data integrity within the system.

5.4 | CI Pipeline:
GitHub Actions is our continuous integration tool, serving as the orchestrator that
communicates with various CI tools to ensure the smooth execution of all steps in our workflow.
The definition of our pipeline is done through a CI development file, presenting a series of stages
that can be sequential or parallel.

78
 Figure 5-14 Ci-development file

Here's a step-by-step breakdown of the provided GitHub Actions workflow file for CI
(Continuous Integration) named "CI-development". Each step is described in detail:

Checkout Code:

Action: actions/[email protected]

Description: Checks out the code from the repository.

Setup Ruby:

Action: ruby/setup-ruby@v1

Description: Sets up the Ruby environment using version 3.2.2.

Cache Gems:

Action: actions/cache@v1

Description: Caches Ruby gems to speed up the workflow by reusing previously downloaded
dependencies.

Install Dependencies:

Action: Custom Ruby commands

Description: Installs Bundler, configures the bundle path, and installs project dependencies.

Pre-compile Assets:

Action: Custom Ruby command

79
Description: Precompiles assets using the rake assets: precompile command.

Run Rubocop:

Action: Custom Ruby command

Description: Runs Rubocop for code linting and style checking.

Setup Chrome driver:

Action: nanasess/setup-chromedriver@master

Description: Sets up Chrome driver for running tests.

Setup PostgreSQL Database:

Action: harmon758/postgresql-action@v1

Description: Sets up a PostgreSQL database for testing.

Setup Database:

Action: Custom Ruby commands

Description: Creates, loads schema, and migrates the test database.

Run Tests:

Action: Custom Ruby command

Description: Runs RSpec tests.

Upload RSpec Screenshots (if test fails):

Action: actions/upload-artifact@master

Description: Uploads RSpec screenshots as artifacts if the test fails.

Login to Docker Hub:

Action: docker/login-action@v1

Description: Logs in to Docker Hub using credentials stored in GitHub secrets.

Build and Push Docker Image:

Action : docker/build-push-action@v2

80
 Description: Builds and pushes the Docker image to Docker Hub with specified tags.The
previous steps are seen in this screenshot of the workflow on GitHub:

Figure 5-15 CI workflow on GitHub

The helm chart repository structure of Leanios-org-ops:

Figure 5-16 Helm chart repository structure

81
5.5 | Minikube dashboard:

Figure 5-17 Minikube Dashboard

The Minikube Dashboard serves as a user-friendly graphical interface for managing and monitoring
Kubernetes clusters deployed through Minikube. It provides a centralized platform where we can
effortlessly visualize, control, and interact with their local Kubernetes environments. Through the
dashboard, we gain insights into the status of nodes, pods, and deployments, allowing for real-time
monitoring of resource utilization and overall cluster health. Additionally, the Minikube Dashboard
offers a convenient way to manage and scale applications, inspect logs, and troubleshoot potential
issues, making it an invaluable tool for developers and administrators navigating the complexities
of Kubernetes development on a local machine.

5.6 | Conclusion
In this final chapter, we provided a detailed overview of our project, accompanied by
screenshots illustrating the implementation of each functionality within our solution.

82
 General Conclusion
This report marks the completion of our end-of-studies project at Sesame Private Higher
School of Engineering, spanning a seven-month period dedicated to collaborative efforts with
LEANIOS STARTUP. Throughout this duration, our primary focus was on investigating the
feasibility of transitioning the LEANIOS cloud platform. Specifically, we explored the shift from
a multi-schema shared database model to a hybrid multi-tenancy solution, encompassing
both multi-schema and multi-database architectures. As part of our deliverables, we
implemented a proof of concept (POC) to validate the viability of this new approach.

Simultaneously, we undertook the development of Leanios Org Ops, a solution designed

to facilitate the deployment of the LEANIOS cloud platform on dedicated private client
servers. Our approach involved the implementation of their fundamental functionalities, and
to ensure efficiency and reliability, we incorporated a continuous integration (CI) process. The
deployment of Leanios Org Ops was initially carried out locally, serving as an initial step before
further integration into LEANIOS infrastructure.

Looking ahead, the subsequent phase of this project involves establishing continuous
delivery (CD) for Leanios Org Ops and seamlessly integrating the hybrid multi-tenancy solution
into the LEANIOS cloud platform. This strategic integration promises numerous advantages,
enhancing the platform's scalability, efficiency, and overall performance. The successful
completion of these steps will contribute significantly to the evolution and optimization of
the LEANIOS cloud platform.

83
 Netography/Bibliography

[N1] Leanios, «Leanios,» [En ligne]. Available: https://leanios.com/.

[N2] Red Hat, [En ligne]. Available: https://www.redhat.com/en/topics/cloud-computing/what-is-

multitenancy#multitenancy-in-linux.

[B3] W. Bokämper, «vdma,» [En ligne]. Available:

https://www.vdma.org/documents/34570/4887363/Guideline_Industrie_40_Security.pdf/39573a09-
80f9-68e1-5afe-
365b89f8607f?t=1648731241990#:~:text=In%20addition%2C%20the%20requirements%20of,of%20conn
ected%20machines%20and%20systems..

[N4] O. Shilovitsky, «beyondplm,» [En ligne]. Available: https://beyondplm.com/2018/08/07/ask-right-

questions-single-vs-multi-tenant-plm-cloud/. [Access On 07 11 2023].

[N5] Anna Dziuba, «relevant,» [En ligne]. Available: https://relevant.software/blog/multi-tenant-architecture/.

[Access On 10 9 2023].

[N6] «alibabacloud,» [En ligne]. Available: https://www.alibabacloud.com/knowledge/what-is-hybrid-cloud.

[Access On 17 11 2023].

[N7] specpage, «specpage,» [En ligne]. Available: https://www.specpage.com/cloud-or-saas/. [Access On 08

11 2023].

[N8] rubyonrails, «rubyonrails,» [En ligne]. Available: https://rubyonrails.org/. [Access On 09 11 2023].

[N9] Ruby on Rails, [En ligne]. Available: https://en.wikipedia.org/wiki/Ruby_on_Rails. [Access On 17 11 2023].

[N10] postgresql, «postgresql,» [En ligne]. Available: https://www.postgresql.org/. [Access On 09 11 2023].

[N11] medium, [En ligne]. Available: https://medium.com/infinite-monkeys/our-multi-tenancy-journey-with-

postgres-schemas-and-apartment-6ecda151a21f. [Access On 17 11 2023].

[N12] rubocop, «rubocop,» [En ligne]. Available: https://rubocop.org/. [Access On 09 11 2023].

[N13] Git, «Git,» [En ligne]. Available: https://git-scm.com/. [Access On 17 11 2023].

[N14] Docker, «Docker,» [En ligne]. Available: https://www.docker.com/. [Access On 17 11 2023].

[N15] k8s, «k8s,» [En ligne]. Available: https://kubernetes.io/. [Access On 17 11 2023].

[N16] GitHub, «GitHub,» [En ligne]. Available: https://docs.github.com/en/actions. [Access On 17 11 2023].

[N17] Helm chart, «Helm chart,» [En ligne]. Available: https://helm.sh/docs/topics/charts/. [Access On 17 11
2023].

[N18] visual paradigm, [En ligne]. Available: https://www.visual-paradigm.com/. [Access On 17 11 2023].

84
[N19] «devops,» [En ligne]. Available: https://blog.devops.dev/the-kubernetes-architecture-
e1ee01ccb76d?gi=35596b3b5d4c. [Access On 14 11 2023].

[N20] A. Hills, «sentryone,» [En ligne]. Available: https://www.sentryone.com/blog/multi-tenancy-with-sql-

server-part-2-approaches. [Access On 8 9 2023].

[N21] Git, «Git,» [En ligne]. Available: https://git-scm.com/downloads/logos. [Access On 09 11 2023].

[N22] vscode, [En ligne]. Available: https://code.visualstudio.com/brand. [Access On 13 11 2023].

[N23] https://www.visual-paradigm.com/, [En ligne]. Available: https://www.visual-paradigm.com/. [Access On

13 11 2023].

[N24] GitHub, «GitHub,» [En ligne]. Available: https://github.com/rubocop/rubocop-rails. [Access on 17 11

2023].

85