Skip Navigation

Running Elentra

Aurora Borealis

Adopting Elentra does not have to be a difficult or arduous process. It can be done in manageable, and incremental steps. The first step is usually just figuring out what you would need to run Elentra at your organization, so we have taken away the guess work by covering the bases.

Skip Your Server Environment

Your Server Environment

The Elentra Platform consists of 3 independent apps that can stand alone or work together: Elentra Admissions, Elentra ME, and Elentra CPD.

Virtual Servers

Web Servers

websrv 01
websrv 02
websrv 03

Database Servers

db 01
db 02
db 03

Project Server

GitLab

Staging Servers

Staging
Skip Resource Allocation

Resource Allocation

Example of resource allocation based on one physical server with 16 virtual CPUs, 64GB of memory, and 1TB of disk space:

Processor & Memory Allocation

Web Server: 45% (6–7 CPU / 16GB)
Database Server: 45% (6–7 CPU / 16GB)
Project Server: 5% (1–2 CPU / 8GB)
Staging Server: 5% (1–2 CPU / 8GB)

Disk Allocation

Web Server: 75% (768GB)
Database Server: 15% (150GB)
Project Server: 5% (50GB)
Staging Server: 5% (50GB)
Skip Your Elentra Team

Your Elentra Team

Project Lead

Support & Training

Senior Developers

Developers

Skip Stacks

Production Stack

  • CentOS / Redhat Enterprise
  • Apache
  • PHP
  • MariaDB

Development Stack

  • Mac OS X / Linux
  • Zend Server
  • Git SCM
  • Capistrano
  • PhpStorm
Skip Web Browsers

Web Browsers

Skip Your Development Workflow

Your Development Workflow

1

The Project Lead creates a new project space on your Project Server for your branded version of Elentra.

2

The Project Lead clones the Elentra Git repository from the Elentra Git server, then checks out the desired version of Elentra.

3

The Project Lead removes the existing Elentra Git remote, then adds the remote of the new project space on your Project Server.

4

The Project Lead pushes the new branded version of Elentra to Git on your Project Server.

5

The Project Lead gives the Development Team access to the project space on your Project Server.

6

The Development Team clones the Git repository from your Project Server and does their work committing their changes and customizations, then pushing them back to your Project Server.

7

The Senior Developers use Capistrano from their workstations to deploy changes from your Project Server to your Staging Server: cap staging deploy

8

The Development Team and any stakeholders test the changes and customizations on your Staging Server.

9

The Senior Developers then deploy the tested changes and customizations from your Project Server to the Web Servers: cap production deploy

!

If there is a problem with any production release, the Senior Developers can revert simply by typing: cap production deploy:rollback