This website uses cookies to ensure you get the best experience. By clicking or navigating the site you agree to allow our collection of information through cookies. More info

Software Development and Infrastructure

The team (also known as, ‘the development team’ or ‘the technology team’) supports the online provision of the digitised collections of Europe’s cultural heritage institutions by designing, developing and maintaining Europeana's software for data ingestion, processing, publication, and retrieval. The product owners provide us with the requirements that we translate into real products.

Development process

We try to follow the Scrum principles, managing backlog, sprint logs and user stories in a tool called Jira. We also try to release code as often as possible. The team is divided into several scrum teams; these are detailed in the Agile Methodology section (see above).


They follow the 12-factor methodology, as we deploy to a PaaS (Cloud Foundry), using blue/green deployment.

Open Source

They publish our code using the open source license EUPL v1.1. We only use open source code libraries compatible with this license for the products we develop.

Version control

They use GitHub for versioning our code. We aim to merge code using pull requests with at least two people involved to ensure proper code reviews.

Continuous integration

Jenkins and Travis are our tools of choice for continuous integration. We use Jenkins for our nightly, snapshot and release builds, providing access to our artifacts via the Europeana Artifactory.

They try to leverage the available Github webhooks to provide helpful information on the build status of our code such as (in the context of a Ruby application):

And in the context of applications developed using Java we use SonarQube, as a centralised quality inspection tool.

Service Providers

This team works with several service providers to host and run our systems:

The Infrastructure team is responsible for managing the inventory of Europeana’s servers and applications managed by the hosting companies.

Release management

We don’t have scheduled releases but aim to do a release every sprint. We aim to follow the Semantic Versioning scheme to number our releases. We tag our releases in GitHub accordingly as well, once they are merged back into the master branch.

Components (developed with/by partners)

We do not try to reinvent the wheel. We try to incorporate as much code that our partners develop as possible. We sometimes even maintain the code developed by third parties on our own. REPOX, for example, was developed by IST in Portugal, but currently, Europeana is proud to be the official maintainer and owner. Other examples include:

  • UIM core implementation - the core implementation of our ingestion management tool
  • Europeana OAI-PMH Endpoint
  • LOD pilot
  • OpenSKOS
  • Annotations API
  • Entity API

Off the shelf: SugarCRM, MongoDB, Apache Solr, Neo4j, Swagger, PostgresQL, RabbitMQ, Apache Cassandra, Apache Storm, Apache HTTP Server, Apache Tomcat, Apache Maven, Subversion, IIPImage Server, Atlassian JIRA and Confluence are a few examples of software that we use in our daily operations.

Language agnostic tools/packages

  • If your app requires a database, use either PostgreSQL or MongoDB.
  • If your app has a public front-end, use the templates from our styleguide.

Language-specific tools/packages

The back-end code is mostly written in Java; the Collections middle tier in Ruby and the front-end in Javascript.

We sometimes do pair programming when we feel the task requires it, but most tasks are done by one person, with deliberation between colleagues when necessary.

We have language-specific development guidelines.

Third parties

Project partners and others that develop with/for us should follow our guidelines and quality standards. Any release of an application to production by third parties must be documented in detail to allow maintenance of the application when the third party is not around. This includes documentation about the configuration and dimensioning of the production environment.