The initial project specifications were delivered to us late in 2013. The project brainstorming, market niche research, competition comparison and branding strategy was already done by that time. Also the user experience mockups and workflow diagrams were done and provided as input for the first phase of the project.
We received the detailed functional specification for the phase 1 before we started to discuss the requirements with the customer. Also we received the initial set of the page designs. The rest of the designs were delivered either during the specifications discussion stage or at the time when the core of the functionality was in implementation stage. While the functional specifications were discussed and polished the rest of the designs were delivered. Also the slicing style guide was made up and ready for the HTML/CSS slicing stage.
Our work on the project started early in 2014 when the functional specification was finalized, the designs were complete and refined and the estimation for the first phase was agreed upon. The first efforts at our side were to slice the static HTML/CSS pages and prepare the staging server for demonstration purposes (as we strongly believe that early feedback from the customer can save a lot of efforts and can give the customer real-time insight on how the project implementation is moving on). Also we performed the initial research to decide upon the admin and CMS functions implementations.
The phase 1 was delivered to production late in September 2014. At this time we created the necessary instances on Amazon AWS cloud and prepared the automated deployment process. Also we added up the tools and services to make sure the project availability is as close to 100% as possible, and also we integrated NewRelic monitoring solution to be able to monitor the project health in real time and to get notifications about any critical events. Also together with the project core implementation the integrations with third party services was built up :
In October 2015 the second phase implementation has started. It featured the integration with RACQ (Australian club for Roadside Assistance, Motoring, Insurance, Finance & Travel) and special membership conditions for its existing participants. Also the project services availability for guest and members users was refactored. In addition the path to accept the Global Money Week participants was added. And as a most recent addition LifeSherpa was extended to provide special conditions and services for corporate subscribers.
Life Sherpa was meant to be a highly available service targeted to the Australian and New Zealand audience equally accessible and usable from both desktop and mobile devices. The latter was especially important as the primary audience for the service is the generation of Millenials. To achieve this the most recent versions of desktop browser must have been supported - Google Chrome, Mozilla Firefox, Safari, Microsoft Internet Explorer and Edge. Likewise for mobile the support of Chrome, Safari and Edge browsers was necessary.
As an additional requirement Life Sherpa pages must be editable in-place by the admin staff whenever the page content has to be changed.
Although the initial requirements gathering process was organized by the customer and mainly done at their side we have participated in the requirements refinement and polishing process, to make them complete enough for implementation phase. In order to make the functional requirements as complete as possible before the implementation has started we have closely cooperated with the Life Sherpa founders, user experience engineer and the designer. Also we communicated closely with SalesForce & Pardot integration engineer to fulfil SalesForce integration requirements in a best possible way.
Our infrastructure includes 3 types of the servers :
Development servers, where our developers and slicers initially interact to implement the functionality and make it ready for QA
Staging servers where QA is performed and where the functionality is being demonstrated to the customer. These servers are setup to match the configuration of the production servers.
Production servers are the servers where the live application is running, and where the changes become visible to the audience of the application
Our development process features usage of the automated tests, which are produced during the implementation phase. The automated tests are further used during the deployment to development, staging and production servers. Before the QA phase is starting the implementation is deployed to the staging server, where the main QA activities are performed. After QA activities are over and the customer approves the functionality on the staging server it is deployed to the production and tested there.
To ensure the project efficiency, stability and security Amazon AWS was chosen as a hosting provider to hold the live application. Our installation features EC2 instance usage to run the application processes, S3 instance to store the assets and RDS to run the database. Our DevOps engineer makes the deployment process using Capistrano. The latter allows us to make the deployment procedure accessible with a single command. Once triggered Capistrano script performs all the necessary plumbing to shutdown/startup the application processes, to deploy to master/slave servers, to run the database migrations and more.
When the application is live on the production server our job is not finished. We continue to monitor the application health, look for the critical updates to make sure the application infrastructure is up to date. Also we receive the notifications about the critical system events and act upon them to make sure the system functions flawlessly. In addition we continuously overview the libraries and frameworks updates - this leads to the upgrades of the libraries within the project to keep the technology stack up to date. Of course we also keep an eye on the security bulletins to provide the system with best possible protection.
The backbone of the application is Ruby on Rails framework (of the version 4.1 at the time of writing). As the HTTP server Apache is installed. Together with Phusion Passenger it serves the user requests. As a backend storage we are using the MySQL 5 server, with InnoDB engine. The choice of MySQL allows us to use the full power of relational database storage engine and to keep the resources footprint to run a storage engine to minimum. To manage the asynchronous back end long running tasks we currently use DelayedJob ActiveRecord Backend library.
For the development of the front end we utilized jQuery, jQuery UI and jQuery plugins stack. As already mentioned the front end layout and interactions are done with SLIM, SASS and CoffeeScript to complement Ruby on Rails stack most efficiently. Also for in-place content editing on the pages we use Mercury engine.
As testing framework to implement the unit, functional and integration tests we use MiniTest. For the initial test data generation we utilize FactoryGirl as well as Faker gem. To add more useful methods and assertions we added up Capybara and Shoulda gems. For service integration testing we utilize Webmock and VCR gems. Also for acceptance testing we use headless and selenium webdriver gems. Before the functions are going live we provide performance testing with SoapUI test automation framework.
From the time when we introduced the first implementation of Cognition to Global Rev Gen employees around the world it became the indispensable part of the company workflow, which tightly glues together separate services used for company operations. It quickly became a platform which allows the company employees to control the online digital campaigns at any stage - starting from the prospecting phase to the billing.
Constant monitoring and support of the service deployment allows us to keep it up and running 24x7, make the critical updates and upgrades well before they might become a bottleneck, and lets us implement the user requests in quick iterations, providing the balance between time to production, quality and costs.