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.
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.
Example of resource allocation based on one physical server with 16 virtual CPUs, 64GB of memory, and 1TB of disk space:
Processor & Memory Allocation
Your Entrada Team
Support & Training
- CentOS / Redhat Enterprise
- Mac OS X / Linux
- Zend Server
- Git SCM
Your Development Workflow
The Project Lead creates a new project space on your Project Server for your branded version of Entrada.
The Project Lead clones the Entrada Git repository from the Entrada Git server, then checks out the desired version of Entrada.
The Project Lead removes the existing Entrada Git remote, then adds the remote of the new project space on your Project Server.
The Project Lead pushes the new branded version of Entrada to Git on your Project Server.
The Project Lead gives the Development Team access to the project space on your Project Server.
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.
The Senior Developers use Capistrano from their workstations to deploy changes from your Project Server to your Staging Server: cap staging deploy
The Development Team and any stakeholders test the changes and customizations on your Staging Server.
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