Technical Architecture & Analysis HS2 Technical Architecture & Analysis 15 October 2012 Anton Palitsyn 020 7426 8920 anton.palitsyn@precedent.co.uk
Contents Contents... 2 Document info... 3 Authors... 3 Change history... 3 Purpose... 3 1. Technical Overview... 4 1.1 Introduction... 4 1.2 Sources... 4 1.3 Technical Assumptions/Technologies... 4 2. Technical Architecture... 4 2.1 Server Specification... 4 2.2 Summary of Solution... 4 3. Post go- live deployment process... 5 3.1 Terminololgy... 5 3.2 General workflow... 6 3.3 The workflow process example (explained)... 7 3.4 Tag naming (versioning)... 9 3.5 Databases... 9 4. 3 rd Party Services and Systems overview... 9 4.1 Mapping... 9 4.2 Interactive Map... 10 5. CMS functionality and modules... 10 5.1 Browser Support... 10 5.2 Workbench... 10 5.3 Sitemap... 10 5.4 XML sitemap... 11 5.5 Drupal Webforms... 11 5.6 Comment module... 11 5.7 Apache Solr... 11 5.8 Views... 11 5.9 Search 404... 11 5.10 Google Analytics... 11 2 Precedent 15 October 2012
Document info Authors Name Telephone Email Anton Palitsyn 020 7426 8920 anton.palitsyn@precedent.co.uk Change history Version Date Purpose V.1.0 10/10/2012 Document creation Purpose The purpose to this document is to outline the technical architecture details for the HS2 website. 3 Precedent 15 October 2012
1. Technical Overview 1.1 Introduction The HS2 website will be built with the Drupal 7 CMS. This document outlines the technical architecture and how different technologies will be used. 1.2 Sources Information sources for this document include: Technical Analysis document Trello dicussions Technical Review meetings with HS2 staff 1.3 Technical Assumptions/Technologies The site will be built using: Drupal 7 XHTML & CSS jquery 2. Technical Architecture The technical architecture outlined below is the solution recommended by Precedent 2.1 Server Specification Hosting arrangement is yet to be agreed. 2.2 Summary of Solution Note: The summary of the solution outlined below is based on the assumption, that Precedent will host the new HS2 website or the alternative hosting provider can support the setup, which may involve more charges. Local development environments Every developer at Precedent works on a virtual machine running Ubuntu. Each VM comes bundled with the same packages that are on our UAT and Live servers, Git, Drush etc. Changes can be made at a central place on the Chef server, which can then push the updates out to each developers VM keeping development environments always up to date with changes to the live servers. Shared development Environment 4 Precedent 15 October 2012
This server is used to merge work from local environments and package them up for deployment to the UAT site. This environment is for Precedent internal use only and is hosted within our local network. UAT Environment This is used to test and sign off work both by Precedent and HS2. Any content entered here may be lost as once a release is ready for testing it will be deployed from development to UAT or a copy of live may be taken to UAT to update the content on it. UAT is a scaled down version of the Live environment so it still has access to an MySQL server, Apache Solr server, memcache etc but is not load balanced. Live Environment Drupal Platform consists of a six tier solution split across UK datacentres. Each location can burst up to 1 gigabit internet capacity and the datacentres are linked via a separate gigabit connection to allow data replication and backup. The system is built on a clustered virtualisation model so virtual servers can be added to each tier quickly and easily (as load demands). 3. Post go- live deployment process Note: The summary of the solution outlined below is based on the assumption, that Precedent will host the new HS2 website. Once the website is launched any changes, modification and bug fixes will have to go through the deployment process. This section outlines the deployment processes. 3.1 Terminololgy Term VM Chef Vagrant Desciption Virtual Machine VM System used to push changes out from a central location to multiple Used to bundle Ubuntu, Apache, MySQL into a quick installable VM 5 Precedent 15 October 2012
Drush Git Master branch Development branch Other branches Drupal shell utility, used to download and manage modules Version control system in place Stable release code is put into the Master branch and tagged with a release number. These tags/release numbers can be used in Codebase to tag tickets with, so that they can be associated with specific releases of code Is where the latest stable development code is stored. All development takes place here or in another branch of this. Copies of the development branch with code that is currently under active development 3.2 General workflow The workflow defined below is split into two stages New ticket and Main process. New ticket can refer to change request, bug fix or new development. New ticket Main process 6 Precedent 15 October 2012
3.3 The workflow process example (explained) Note: The workflow process is described based on an example. 7 Precedent 15 October 2012
Project team consists of 2 developers (Developer 1 and Developer 2) Project has been split into 3 releases o Main site content types, views etc all themed up o Functionality 1 o Functionality 2 Developers 1 and Developer 2 both work on the development branch together and regularly push their code to the shared dev site shown on the Diagram 3.1. Once ready for UAT, the development branch is merged into the master branch which is then pushed to the UAT server for client testing. Once client signs off UAT and any required amends are made the master branch is tagged with v1.0 as a Git tag. Master branch is then pushed to Live. Note that if the site is not live yet that Live is also the pre live server. Then Developer 1 creates a branch called Functionality 1 branch based off of the development branch and Developer 2 creates another branch from the development branch called Functionality 2 branch. Developer 1 finishes before Developer 2 and merges his branch back into development branch for testing on the shared dev site. Once the internal testing is complete and passed, he merges the changes to the master branch and then again pushes onto UAT for the client to test. 8 Precedent 15 October 2012
Client approves Functionality 1 section and the master branch is then tagged with a relevant tag which in this case would be v1.1. The master branch is then pushed to live. Developer 2 finishes and repeats the above steps and would then eventually tag the master branch with v1.2. The master branch is then pushed to live again. If the client reports a critical bug with the new version, Developer 1 or Developer 2 can revert back to the previous stable version. In rare occasions, reverting back may possess a certain level of risk. The client will be advised of such risks prior to the changes being pushed to the live environment. The risks will depend on the amount of time elapsed since the changes were pushed live. In such rare occasion, Precedent may advise to fix the bug via the outlined process instead of reverting to the previous versions (tag). 3.4 Tag naming (versioning) Indentation/ increment Desciption 1.0 Incrementing the version number by 1.0 would involve a major upgrade of the system or a near complete rewrite of the code, which results in theme alterations and module rewrites 0.1 Used for new features such as blog, commenting, new section etc. This is considered to be a minor upgrade, increasing the version number by 0.1 0.0.1 Whenever a bug fix is applied, the version number is incremented by 0.0.1 3.5 Databases Once the site is live and content entry has begun no databases will be uploaded to live unless a content freeze has taken place for a special reason to fix a bug or put some major change live. However, this will be rare. All modules will be written to store as much configuration as possible in code through a mixture of features, ctools exportables and through Drupal s module install and update hooks in modules. 4. 3 rd Party Services and Systems overview 4.1 Mapping The proposed solution is to use OpenLayers as the interface for maps for the following reasons: OpenLayers has a stable supported Drupal 7 modules. The Gmap module doesn t have a stable Drupal 7 release and doesn t even support the new Gmaps API. OpenLayers can use Gmaps as a tile provider so the user doesn t even know what we are using really they can just see the usual Gmap. 9 Precedent 15 October 2012
Gmap tiles are nice, but there are some that are even nicer. Mapbox have great looking tiles and its relatively easy to design and build your own tiles. To build your own tiles (using TileMill) you use base layers for boundaries, then you can upload your own layers (KML files, SVG, etc.) with streets, routes, etc. The map can then be styled with a similar language to CSS. http://mapbox.com/ http://mapbox.com/tour/design/ http://tiles.mapbox.com/mapbox http://mapbox.com/tilemill/ 4.2 Interactive Map Showing the interactive map with the points of our location pages is straightforward, this is done with Views (a query builder that outputs lists of content in any kind of display) and the OpenLayers module. Having a list of popular locations is easy, but there is no way to tie that list into point in the map without a bit of custom JS. I have worked on a project before where we did this using Drupal 6 + the Gmaps module (example below). I m sure I can code up something similar to work with Drupal 7 and OpenLayers. The way this would work is that when you hover over the popular locations the point would get centred on the map and the popup would get triggered. Example: http://www.rvparking.com/ca/bakersfield When a user looks for their post code it will show a point of their location in the map along with the other locations (entered by admins) and the route. The map would get centred on the user entered location. 5. CMS functionality and modules 5.1 Browser Support Drupal 7 back-end supports the following browsers: - Firefox (current version on Mac, Windows, Linux) - Safari 5 (Mac, not Windows) - Chrome (current version on Mac and Windows) - Internet Explorer 8 and 9 - Mobile browsers such as iphone, Android, and ipad will be supported but not optimised for. 5.2 Workbench Workbench moderation module will enable administrators to define and apply the workflow throughout the site and/or by section. http://drupal.org/project/workbench_moderation 5.3 Sitemap The website sitemap will be driven by the Site Map module. http://drupal.org/project/site_map 10 Precedent 15 October 2012
5.4 XML sitemap This module is used to generate an xml sitemap of the entire site and can be used for search engine indexing. http://drupal.org/project/xmlsitemap 5.5 Drupal Webforms This module allows administrators to create custom forms. http://drupal.org/project/webform 5.6 Comment module Drupal comes out of the box with commenting functionality in the form of the Comment module 5.7 Apache Solr This module integrates Drupal with the Apache Solr search platform. Solr search can be used as a replacement for core content search and boasts both extra features and better performance. If you're looking for Apache Solr integration, this is possibly the best option available. In order to be able to search for attachments, we will use Apache Solr Attachments module. http://drupal.org/project/apachesolr_attachments & http://drupal.org/project/apachesolr 5.8 Views This module allows administrators to create RSS feeds. http://drupal.org/project/views 5.9 Search 404 This module allows us to have a 404 page. http://drupal.org/project/search404 5.10 Google Analytics This module adds tracking to the site. Full list of options is available on http://drupal.org/project/google_analytics 11 Precedent 15 October 2012