Procedure

Integration process

Procedure

Integration process

Document type:

 draft

 to be validated

 validated

Reference: QUA_IntegrationProcess.doc

Purpose of the document

The purpose of this document is to describe the procedure for integrating an application at the Council of Europe

This document is the property of the Council of Europe.

It may not be reproduced or passed on without prior permission of the author.

Contents

Purpose of the document

1.Introduction

1.1Purpose of the Document

1.2Presentation of the Integration Environments

1.3Definition of an Integration Operation

1.4The different types of services

1.5The Players

1.5.1Business owner project leader

1.5.2Project-side manager

1.5.3Architect

1.5.4Head of the integration team

1.5.5Integration team

1.5.6Operating team

1.5.7Change management team

1.5.8Key users

1.5.9TPM team

1.6Reference documentation

2.Integrating a project

2.1Presentation of the phases of a project

2.1.1Technical meeting(s)

2.2Presentation of the phases of a delivery

2.2.1Prior planning

2.2.2Checking of the delivery

2.2.3Analysis of source code

2.2.4Validation of documentation

2.2.5Installation of the application in the delivery environment (delivery)

2.2.6Technical approval, unit tests and non-regression tests

2.2.7Installation of the application in the validation environment – pre-release (validation)

2.2.8Functional Tests (VABF)

2.2.9Installation in release/production (MEP)

2.2.10Final approval (VSR)

2.3Integration process

3.Deliveries/Deliverables

4.Using a tracking tool : Metro

4.1Prerequisite

4.2Delivery

5.Glossary of abbreviations used

1.Introduction

1.1Purpose of the Document

The purpose of this document is to formally lay down the process for integrating applications at the Council of Europe. This document is mainly intended for the managers of projects, so that they may familiarise themselves with the different phases of an integration process.

1.2Presentation of the Integration Environments

Delivery/test environment - This is the environment for technical approval of the delivery and validation of the correct functioning of the application, by carrying out unit tests as well as regression testing before the application is installed on the validation/pre-production platform.

Validation/pre-production environment - This is the environment for validating the functional aspects of the application by carrying out functional tests (UAT- User Acceptance Testing) relating to changes and corrections to the new version of the application before it is installed on the release/production platform.

Release/production environment - This is the environment for final acceptance, where users can use/try out the applications hosted. Unlike the other environments, the release/production environment is subject to an SLA, which makes it possible to guarantee a certain level of availability of the applications hosted.

1.3Definition of an Integration Operation

The ultimate aim of an integration operation is the deployment of an application on the production servers. A number of phases are necessary before this can be done:

  • Checking of the delivery.
  • Analysis of source code
  • Validation of documentation
  • Installation of the application in the delivery environment (delivery)
  • Technical approval, unit testing and non-regression testing
  • Installation of the application in the validation/pre-production environment (move to validation)
  • Functional validation of the application
  • Installation of the application in the release/production environment (release)
  • Final approval
  • All deliveries must be accompanied by a delivery slip, clearly indicating which components have been modified in the application in relation to the previous delivery.
  • Firstly analysis is carried out of the sources and documents (installation, operation etc) to check that the project complies with the standards and norms, and that the information contained in the documents is sufficient for the application to be installed and operated in proper conditions. At this stage it is also checked that the architecture file has been complied with.
  • Once the sources and documents have been validated, the application may be installed in the development/delivery and integration environments. Installing an application in the development/delivery environment makes it possible to validate the installation process and carry out unit testing if this has not already been done, and installing it in the integration environment allows the project's key users to carry out overall functional tests for the application and validate it for release.

1.4The different types of services

The architecture/integration team provides two types of service:

  • Architecture and integration in connection with the release of new projects.
  • Integration in connection with the release of corrections or functional developments concerning existing applications.

1.5The Players

1.5.1Business owner project leader

The project leader is usually an employee of the Council of Europe and acts as a middle-man between the customer and the project team. They also coordinate the actions of the different players and are responsible for planning.

1.5.2Project-side manager

The project-side manager is usually an employee of an outside company and coordinates project implementation at the technical level. They are the main contact person for the project leader.

1.5.3Architect

The architect validates the technical choices concerning the architecture of projects. They also ensure that the projects make good use of shared software components.

1.5.4Head of the integration team

The head of the integration team is responsible for the proper planning of the different phases presented in this document.

1.5.5Integration team

The integrator carries out the analyses of sources and documentation. They are also in charge of the installation of applications in the different environments.

1.5.6Operating team

The operating team is in charge of all the servers. It has the administrator rights over the entire Information System.

1.5.7Change management team

The change management team manages all the operating requests.

1.5.8Key users

The key users are usually members of the department which initiated the project. They are responsible for carrying out the functional tests.

1.5.9TPM team

This is the team which will keep the application operational.

1.6Reference documentation

Internal reference / Document Title / Section in
Developer's Toolkit
R1 / QUA_DeliveryProcedure.doc / Process and Procedure
R2 / Gestion de la documentation
R3 / ND_NormesDeveloppementDotNET.doc / Standards and Norms
R4 / ND_NormesDeveloppementJ2EE.doc / Standards and Norms
R5 / ND_NormesDeveloppementPHP.doc / Standards and Norms

All the reference documents may be accessed from the "developer's toolkit" via the URL:

2.Integrating a project

2.1Presentation of the phases of a project

The diagram below shows an overview of the different phases of a project:

Key:

Architecture phase
Project phase
Post-project phase

2.1.1Technical meeting(s)

Phase: Pre-project

Person Responsible: Business owner project leader

Players: Project-side manager,Architect / Integrator

During the architecture phase, one or more meetings may be organised by the business owners so that the architect / integrator can present the Council of Europe's architecture, the integration process, the standardisation documents and the software components that may be used during the project to the project management.

The project leader will also have to liaise with the architect/integrator to define the environments to be created (database, website, web application etc). The architect/integrator will then make the necessary requests to the change management team to create those environments.

2.2Presentation of the phases of a delivery

By way of a reminder, all the phases entailed by a delivery are as follows:

  • Checking of the delivery
  • Analysis of the source code
  • Validation of the documentation
  • Installation of the application in the delivery environment (delivery)
  • Technical approval, unit testing and non-regression testing
  • Installation of the application in the validation/pre-production environment (move to validation)
  • Functional validation of the application
  • Installation of the application in the release/production environment (release)
  • Final approval

2.2.1Prior planning

Person Responsible / CoE project leader
Players /  / CoE project leader
 / Users
 / Head of the integration team
 / Integration team
 / Change management
 / Operating team
 / Third Party Maintenance team

At the end of the pre-project phase or at the beginning of the project phase, the business owner project leader must work with the head of the Integration team to plan the different operations to be carried out.

The business owner project leader will be responsible for the integration schedule and may change it by agreement with all the players.

When all the dates have been set, the integrator works with the change management team to plan the operations requiring the intervention of the operating team.

When operations are planned in advance, delays in deliveries may have an impact on the scheduling of the subsequent tasks.

2.2.2Checking of the delivery

Person Responsible / Head of the integration team
Players /  / CoE project leader
 / Users
 / Head of the integration team
 / Integration team
 / Change management
 / Operating team
 / Third Party Maintenance team
Prerequisites / N/A
Lead-times proposed / d+1, d being the date of delivery

The integration team is responsible for checking that the delivery is valid.

The checks include:

  • presence of the Delivery Slip (French abbreviation - 'BL').This Delivery Slip will be a «note» in the integraion metro ticket
  • content of the Delivery Slip ('BL')
  • presence of the sources in the source manager
  • presence of all the documentation
  • etc.

At the end of this phase, the schedule will be validated or put on hold, depending on the outcome of the checks.

2.2.3Analysis of source code

Person Responsible / Integration team
Players /  / CoE project leader
 / Users
 / Head of the integration team
 / Integration team
 / Change management
 / Operating team
 / Third Party Maintenance team
Prerequisites / N/A
Lead-times proposed

In this phase, the integration team will check that the source code conforms to the technological standards and norms used within the Council of Europe.

The different aspects covered by standards and norms include:

  • Security implemented in the source code
  • Internationalisation and globalisation of the application

In the case of J2EE applications, the integration team's analysis report will be based on the project's "documentationwebsite" which groups the unit test reports, the javadoc, the reports checking conformity of the source code etc. The structure of this site will be generated and published on a web server by Maven 2 when the integrator deploys the J2EE application.

Each analysis must be written up in a report which the head of the integration team will forward to the CoE project leader, who must then forward the document to the contractor and ensure that the different comments are taken into account.

The report will assign a status from one of the following:

  • OK
  • NOK (non-blocking)
  • KO

If OK status is assigned, the next set of technical steps can be carried out once the delivered application has been installed in the Council of Europe environments.

If reservations are expressed, they must be "withdrawn" before the application is installed in the Council of Europe test environment.

In the event of a KO, the project leader must supply a new delivery schedule within a reasonable period of time, by agreement with the head of Integration.

In certain cases this postponement may prompt a meeting with the project leader the head of Integration and the person who produced the analysis report. Following that meeting a decision will be taken on which points are to be rectified for the pre-production and the release/production phases.

The analysis reports will be stored in an area provided for that purpose (Please contact the Business owner project leader)

2.2.4Validation of documentation

Person Responsible / CoE project leader
Players /  / CoE project leader
 / Users
 / Head of the integration team
 / Integration team
 / Change management
 / Operating team
 / Third Party Maintenance team
Prerequisites
Lead-times proposed

All documentation is versioned within the configuration manager used by the Council of Europe: Subversion.

Contractors have an obligation to update the documentation for each delivery, including when these entail only a correction.

In accordance with the procedure for managing documents linked to an application (cf R2) the integration team will be responsible for sending the document delivered by the contractor to each person responsible for validation.

These people must check the following points, among others:

  • the use of model documents applicable at the Council of Europe
  • the completeness of the document
  • the quality of the drafting
  • …

The people responsible for validating all the documents are:

Document / Validator
Installation file ("DI - Dossier d’Installation") / Integration team
Functional specifications ("SF – Spécifications fonctionnelles") / Project leader
Operating file ("DE – Dossier d’Exploitation") / Operating team
Third Party Maintenance Team
User Manual ("MU – Manuel Utilisateur") / Users
Detailed functional specifications ("SFD – Spécifications Fonctionnelles Détaillées") / Project leader
Third Party Maintenance Team
Technical specifications ("ST – Spécifications Techniques") / Architect

In accordance with R2, all the validators must inform the project leader and the head of Change management.

The analysis report is to be completed by all the players, with comments linked to their analysis of the documents.

The status of the analysis may be modified accordingly.

2.2.5Installation of the application in the delivery environment (delivery)

Person Responsible / Head of the Integration team
Players /  / CoE project leader
 / Users
 / Head of the integration team
 / Integration team
 / Change management
 / Operating team
 / Third Party Maintenance team
Prerequisites
Lead-times proposed
Duration proposed / 1 day

The aim of this task is to enable validation of a number of points including the installation procedure described in the Installation file.

All the applications must be packaged as shown below:

Application / Description of packaging
.Net / Packaging on the basis of WiX technology
J2EE / Generation of a WAR file and deployment of the WAR in the application server deployment directory (eg webapps for Tomcat).
PHP / Copy of files generated by SVN in the PHP server deployment directory

These packages are created or updated in line with the installation procedure.

This phase will always be carried out if the delivery is deemed compliant during the "delivery checking" phase.

If not scheduled, this phase is to be carried out within one week following delivery at the latest.

The average duration is about one day.

When installation is complete, the integrator must notify the project leader by e-mail.

2.2.6Technical approval, unit tests and non-regression tests

Person Responsible / CoE project leader
Players /  / CoE project leader
 / Users
Integration team

 / Change management
 / Operating team
 / Third Party Maintenance team
Prerequisites
Lead-times proposed
Duration proposed / 5 days

A set of tests will be carried out, under the responsibility of the project leader, who must provide an adequate testing plan. This plan may be supplied by the development teams.

It may be implemented by the integration team.

In the case of J2EE applications, the integration team will be able to check that the unit tests have run correctly by consulting the project's "documentation website". By way of a reminder, this site's structure will be generated and published on a web server by Maven 2 when the integrator deploys the J2EE application.

Where a tool exists (UAT) and a testing plan is supplied, a new test campaign can be run.

The priority during these tests will be to validate correct installation in the development environment.

Accordingly, the following aspects are to be integrated in the testing plan:

  • authentication
  • access to the database
  • access to reports
  • reading on hard disk
  • writing on hard disk
  • interaction with filemanager
  • interaction with errormanager
  • interaction with the directory list
  • limit testing (no base, no directory list, no disk rights, bad parametering etc)
  • non-regression tests

2.2.7Installation of the application in the validation environment – pre-release (validation)

Person Responsible / Head of the Integration team
Players /  / CoE project leader
 / Users
 / Head of the integration team
 / Integration team
 / Change management
 / Operating team
 / Third Party Maintenance team
Prerequisites / Validation of documentation
Lead-times proposed
Duration proposed / 2hrs

Installation in the test environment is to take place under the same conditions as installation in the development environment.

It is recommended that the database be restored from the release/production base to enable users to enjoy similar conditions to their release/production environment.

2.2.8Functional Tests (VABF)

Person Responsible / CoE project leader
Players /  / CoE project leader
 / Users
 / Head of the integration team
 / Integration team
 / Change management
 / Operating team
 / Third Party Maintenance team
Prerequisites
Lead-times proposed

A set of tests is to be carried out, under the joint responsibility of the project leader and the users. These tests are to be carried out by the users or individuals designated by them.

As a tool exists (UAT) and a testing plan is supplied, a new test campaign may be managed.

The minimum tests to be carried out will be the tests corresponding to the developments and corrections of the release.

2.2.9Installation in release/production (MEP)

Person Responsible / Change management
Players /  / CoE project leader
 / Users
 / Head of the integration team
 / Integration team
 / Change management
 / Operating team
 / Third Party Maintenance team
Prerequisites / Validation of the application (functional tests)
Validation of the documentation
Lead-times proposed

In accordance with the procedure supplied by the integration team, the installation is to be carried out by the operating team. All the issues reported are to be listed

2.2.10Final approval (VSR)

Person Responsible / CoE project leader
Players /  / CoE project leader
 / Users
 / Head of the integration team
 / Integration team
 / Change management
 / Operating team
 / Third Party Maintenance team
Prerequisites / Release/production
Lead-times proposed / Duration specified in the call for tenders
or 2 weeks

Once the application has been installed in the release/production environment, it must be definitively validated by the users. At the end of the scheduled period, the regular service check is declared.

2.3Integration process

See appendices (Visio)

3.Deliveries/Deliverables

All the information concerning the delivery procedure and the deliverables expected is listed in the R1.

4.Using a tracking tool : Metro

Metro is an opensource tool under GPL licence, developed in PHP.