The Common Web Platform (CWP) is designed to accommodate the next generation of government websites, allowing multiple agencies and vendors to work as a community to build a variety of websites, while making use of shared infrastructure, software, and tools.
The technical architecture of the platform is summarised in the CWP Architecture Overview [PDF, 1.3 MB] (Updated 1 March 2015). If agency staff would like to read the solution architecture document, contact email@example.com
The architecture of solution:
CWP provides online tools to improve the management and deployment of code. These are setup when an agency requests a new instance of CWP. The code repository makes it easy for agencies to share and collaborate on code.
GitLab is used to manage website code on CWP. It enables sharing, collaboration, and audit trails of the code it stores. It is run securely on the CWP infrastructure, to keep code in New Zealand. Agencies can choose whether code they produce is private or shared, on a case by case basis. Find out more about GitLab (external link) .
Deploynaut publishes code from GitLab to the testing and production servers, and allows databases and files to be transferred from one environment to another. By automating the process using repository numbers, it reduces the risk of error and makes rolling back to a previous version easy.
CWP standardises how code is deployed to websites. For many agencies this will introduce better change control, and reduces the risk of outages or defects being released to production. It also makes deploying code quicker and easier.
The following graphic illuatrates the deployment pattern. It is explained in the paragraph below.
Code is developed on a local environment, then published GitLab. The developer then deploys to the test server using Deploynaut. Once the testing and review is complete, a request is made to release the code to production. Find out more about how to deploy code on CWP.
Participating agencies can start using the GitLab code repository for developing a website, before they have set up and begun paying for an Instance. They can then request the Instance when they are ready to start testing.
Supported by an active open source community, SilverStripe modules extend SilverStripe CMS, providing additional functionality such as blogging, user customisable forms, workflow, and lots more. Commercially Supported Modules take this one step further. By having the backing SilverStripe Ltd, there is a dedicated team of developers actively maintaining these modules.
As well as having the advantages of being open source community projects, Commercially Supported Modules have:
By using Commercially Supported Modules, agencies and developers can build projects with confidence, knowing these modules have been tested and have the backing of SilverStripe Ltd.
'Commercially supported' does not necessarily mean we add additional features over time - see how will CWP improve over time.
Agencies can pay to have a module added to the commercially supported modules list - see Module or extension warrantees. This is useful when an agency has developed a module they rely on.
Developers are encouraged to use Community Supported Modules (from the open source community) alongside Commercially Supported Modules. Many of these modules are high quality and provide functionality not available in the SilverStripe Commercially Supported Modules sub-set.
The following warranties are provided for Commercially Supported Modules as part of the CWP Lead Agency Agreement:
(i) there will be no loss of, degradation to, or new defects in the functionality and performance of any of the Participating Agency’s Instances where the upgrade takes the form of a point release (for example, from version 3.0.2 to 3.0.3);
(ii) there will be no loss of, degradation to, or new defects in the functionality and performance of the version of any extension (module, theme or widget) that was certified by the Service Provider in accordance with the certification process set out in the Operational Procedures Manual prior to the upgrade where the upgrade takes the form of a point release (for example, from version 3.0.2 to 3.0.3) or a minor release within the current major release (for example, from version 3.0.3 to 3.1.0); and
(iii) there will be no loss of, degradation to, or new defects in the functionality and performance of the latest version (prior to the upgrade) of any extension (module, theme or widget) that, prior to the upgrade, came bundled with the Content Management System, where the upgrade is a point release, minor release, or a major release (for example, from version 3.1.0 to 4.0.0), except to the extent that the Service Provider has: (A) deliberately replaced such an extension with a new or substitute extension that, again, is bundled with the Content Management System; or (B) deliberately removed and not replaced such an extension due to its low usage by Participating Agencies and/or other users;
In response to this, SilverStripe Ltd. Commercially Supported Modules meet each of these obligations:
(i) by ensuring that all modules that make up the CWP basic recipe follow “Semantic Versioning” (external link) .
(ii) by following Semantic Versioning, and amending the list of Commercially Supported Modules (external link) , making sure this is available and up to date.
(iii) in addition to following Semantic Versioning, we have a process for validating whether a feature should be removed from a module or moved to a different Commercially Supported Module, and where a features hasn’t been deliberately dropped by this process treat any missing feature as a bug.
Overall, this means that we should take reasonable steps to avoid bad things happening in the first place, and if they do, we will fix the sites (or, more likely, the product) at our own cost.
Deploynaut (external link) tool allows you to transfer data to, from and between particular environments that comprise the instance. By automating these processes it avoids common mistakes and makes sure the process is reversible by taking automated backup.
Roles differ in terms of access permissions to specific environments. For example access to production data is restricted due to data confidentiality requirements.
Find out more about data transfers in the tutorial.
Agencies can configure websites to be locked down or accessible only via encrypted connections, through a variety of means. This enables the platform to be used for intranets, and for websites, where all or part of the content is restricted to certain users. Specific techniques are available and include:
Development and configuration effort and/or costs may apply for anything beyond simple IP whitelisting.
Websites can connect to back-office systems and other sources of data through APIs. This allows transactional services to be delivered through the website. API support is built into the CWP install of the Content Management System.
There are various techniques to ensure the secure transmission of data over an API: