Skip Navigation

Running Entrada

Aurora Borealis

Adopting Entrada 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 Entrada at your organization, so we have taken away the guess work by covering the bases.

Skip Your Server Environment

Your Server Environment

The Entrada Platform consists of 3 independent apps that can stand alone or work together: Entrada Admissions, Entrada ME, and Entrada 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 Entrada Team

Your Entrada 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 Entrada.

2

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

3

The Project Lead removes the existing Entrada 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 Entrada 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