Introduction

This document describes the quality assurance processes and procedures that governs the releases of Pure. This include a description of what we do to insure that Pure fulfill the functionality, services, and features that our customers expect, and also how we prevent mistakes and defects before delivering Pure to our customers.

When referring to a release of Pure in the context of this document, we mean a collection of Elsevier software as a specific package that fulfill the requirements and needs of one individual customer, and can be used for both updates and new installations.

Release cycle

Release types

We have three types of releases for Pure each release type is scheduled and used for different purposes. Notice that the schedules below are somewhat flexible, because we weigh quality higher than releasing on a specific date - i.e. we allow ourselves some flexibility in order to only release when we think the quality of a given release matches our goals.

It is important to note that we only maintain a given feature release, until the next feature release is released. Hence once 5.15.0 is release we stop maintaining all 5.14.x versions. This is a deliberate decision, in order to sharpen focus and directing all effort on only keeping one maintenance release stable, as well as dramatically increases our ability to support customers as we only one version of software in production.

In the release notes you find information on how to request a specific version/release of Pure:

Request Pure distribution file

Please note that there might be special requirements for a certain release and pay extra attention to the "Before Installation or Upgrading" section as you might be asked to upgrade the database, Java or Tomcat.

Quality Assurance

Requirements

Requirements are collected and maintained using four tools:

• Pure Client Community - Often used to capture and maintain requirements. Customers are also, when relevant, invited to contribute to the definition of requirements.
• Pure Help Center - Used when more detailed or comprehensive documentation of requirements is needed. Customers are also, when relevant, invited to contribute to the definition of requirements.
• Informal mock-ups - Usually produced by our Product Managers, UI/Usability Experts, Developers or customer.
• The Agile Team - Through iterations of ever evolving features, discussed among and evaluated by the Product Managers, UI/Usability Experts and Developers within a Agile Team. Relevant customers are also included in these discussions.

Case handling

When referring to a case in this context, “case” refers typically to bugs, questions, and install/update requests.
All cases at Elsevier are reported into and managed by a case tracking system named Salesforce. This includes cases reported by customers, but also cases found and created internally at Elsevier as a part of our development process. When a case is closed, a fix version is set and can then be referenced direct to our version control system. The use of such a system creates higher consistency in service and quality delivery because it provides traceability and ensures we track and account for all issues.

Version control system

As a software version and revision control system Elsevier primarily uses Git. All changes and modifications done as a part of development, support, and maintenance of Pure are registered through Git. This is the same for all types of Pure releases, which are also done with direct reference to Git. The tight integration of Git enables us to track all changes and make a reliable reference to all customer releases and issues reported. Git is also used to maintain Pure configuration.

Git is used to support our quality assurance procedure by branching and tagging software. A typical scenario (as illustrated in picture 1): Developers commit all new work, like new features, bug fixes, and so on, to the main development branch(master) on a day-to-day bases. When a new feature release is planned, e.g. '5.14.0', 'master' is copied or branched out to a new release branch, '5.14.0-SNAPSHOT'. A dedicated team of developers and testers (verification team) then start the test and verification period. They branch '5.14.0-SNAPSHOT' into '5.14.0-RELEASE' and then close that branch, which leaves master and '5.14.0-SNAPSHOT' open for the remaining teams to continue development, where they will not disturb the verification team. If bugs are discovered, fixes are ported back and forth as necessary, and also ported to '5.14.0-RELEASE' if the verification team sees it as critical for the release . At release '5.14.0-RELEASE' is tagged in Git as '5.14.0' for reference. The tag is used when distributions are build and packed for customers. The '5.14.0-SNAPSHOT' is maintained in parallel with master and bug fixes continue to be ported from 'master' to the snapshot branch. Around the 1st of every month, a maintenance release is planed and '5.14.1-RELEASE' is created and tested before it is tagged as '5.14.1' for distribution to customers. The maintenance of '5.14.0-SNAPSHOT' continues until the next feature release(5.15.0) is released, after which it is closed for further development. Throughout the maintenance of '5.14.0-SNAPSHOT' a hotfix/emergency release can be made when needed. A hotfix/emergency release is based on the latest maintenance release(5.14.1) by porting fixes from '5.14.0-SNAPSHOT' to latest release branch(5.14.1-RELEASE). The hotfix is then tested on the release branch and tagged as e.g. '5.14.1-1'.

Test activities

Releases

Before a release a team, usually consisting of Developers, Testers, and a Test Manager, is assembled. The team is dedicated to the verification phase until the software is released. The software is branched out to a release branch. The team is given exclusive right to the branch and is in full control changes going in or out. This is to stabilize the software, increase the knowledge of the release, and minimize the risk of introducing new issues. One of the first activities of the team is to identify functionality and features that have undergone (larger) changes or been added since last release – also called a risk analysis. These along with input from ongoing projects and, of course team experience, makes a list of potential focus areas and test subjects for the team.

A verification phase is usually divided in three sub phases. The first phase is a combination testing and issue fixing. Identified test subjects are tested and found issues are reported, fixed and committed to the release branch. During the second phase, important and business critical functionality of Pure are tested and solved issues are verified and closed. This is repeated throughout the phase. The third phase is to gain as much knowledge and confidence to release as possible and log any issues.

Fix/Emergency release

Virtually no different from a regular release except that the risk areas are usually one or two very specific things aimed at a single customer setup.

Continuous Integration

At Elsevier we have Continuous Integration(CI) testing integrated in our infrastructure, which means that committed changes are immediately tested and reported on when they are added to our code base. CI is used to provide rapid feedback so that if a defect is introduced into the code base, it can be identified and corrected as soon as possible. Because CI detects deficiencies early on in development, defects are typically smaller, less complex and easier to resolve.

Every night we perform even more in-depth tests on the latest committed software, results are summarized in a test report, and if necessary, issues will be sent to the developers.

The results from CI and our nightly tests are also taken into consideration when releases are tested.

Customer feedback

When a Pure system is installed and in use, users and customers still have the option to provide feedback.

Users and customers of a Pure system have the ability to register cases from the Client community through our support team or using our web site. And not only errors and corrections but also proposals for extensions and new features, making Pure even better. Through the Pure Client community the users and customers can also follow the workflow, comment on issues, close issues, or even re-open closed issues.

Security related QA

We regularly perform static code analysis on our code base in order to identify potential security risks.

We perform daily penetration tests on an instance of Pure within our own production environment - i.e. in essence we are performing penetration tests on both Pure and the production environment itself.

Governance

A dedicated team of Developers and Managers govern all security related topics in context of Pure. This team anticipates future attack vector and defines processes and procedures for all security related topics in context of Pure and our hosting environment.