Hippo

Repository interfaces

Deployment and staging can be subdivided into two tasks:

  • Deployment of a software update
  • Deployment of changed content

Deployment of a software update

Hippo uses server deployment mirroring. A new release or implementation is tested thoroughly first by Hippo internally on a test machine, before it is made available to the customer on an external test server. After approval, an exact copy of this installation is installed on the live server by a single action. Our experience is that this keeps the number of errors caused by last minute modifications down to a minimum.

Deployments are offered as a single package and change and version information is supplied. The different versions of a deployment are archived and can be restored straight away if necessary. This process is completely automated, so that errors due to human intervention are avoided.

This procedure can be done quickly. If necessary, depending on the infrastructure provided, it is possible to carry out an update in just a few minutes. This means that the actual downtime for the site can be limited to just a few seconds. If a load-balanced environment is used, there will be no downtime.

Source code that is developed by Hippo is stored centrally in the Hippo CVS or SVN repositories. A bug-tracking system (Atlassian Jira) is linked to this and this is also available to the customer. This makes it easy to follow the progress and makes clear which changes are present in each deployment, and which problems have been resolved.

Knowledge or data are not lost due to changes being handled carelessly.

Deployment of changed content

The live environment uses two repositories: one for creating and managing the content, and a second one that only contains copies of the approved documents. A message can only be put online after approval by one or more editors. This process is described in more detail under ‘workflow’.

Real-time and batch updates

The Hippo Repository accepts updates over one of the following protocols:

  • WebDAV
  • HTTP
  • SOAP
  • Java API
  • File system import ('DROP directory')
  • E-mail
  • Directly from another database (using JDBC / ODBC)

It is easy to write a custom link that receives data via HTTP, for example, and then stores them in the repository using the Java API or WebDAV interface.

Data that arrive in the repository undergo the same workflow process as all other data, but can also be ‘approved’ immediately so that they are visible online at once, rather than requiring intervention by the editorial team. In the case of a link with e.g. Documentum, this may be desirable: after all, the documents have already been approved. Documentum and Hippo CMS can exchange documents without problems via a SOAP interface.