kokou Agbedanou

Usine de développement
Les entreprises industrielles du secteur secondaire (industrie automobile, industrie pétrolière, industrie
sidérurgique, industrie électronique et de matériels informatiques...) ont toutes créé des chaînes de
fabrication pour transformer la matière première en produits finis. À chaque fois, la réussite de ces
industries est passée par l’automatisation des tâches et le contrôle qualité.

Par exemple, la fabrication d’une voiture passe par différentes étapes d’assemblage presque toutes
automatisées. Le crash test fait partie de ces étapes.

Ce principe est applicable à l’industrie du développement logiciel.

1. Intégration continue (CI)

a. Définition

"L’intégration continue est un ensemble de bonnes pratiques utilisées en génie logiciel consistant à vérifier
à chaque modification de code source que le résultat des modifications ne produit pas de régression dans
l’application développée [...]." (source : Wikipédia).

Autrement dit, l’intégration continue constitue un sous-ensemble d’une usine de fabrication de logiciel. La
CI est constituée d’outils permettant une automatisation.

© Editions ENI - Tous droits réservés - Copie personnelle de kokou Agbedanou -1-
 kokou Agbedanou

Place du sous-ensemble de la CI dans l’UDD

b. Les briques de la CI

La CI est composée de plusieurs éléments qu’il convient de mettre en place afin d’apporter une meilleure
qualité de code et une fabrication rapide des versions d’applications (releases mineures et majeures).
L’objectif principal est d’utiliser les éléments pour effectuer une compilation, lancer des tests (unitaires et
fonctionnels, de sécurité et de performance) et lancer une analyse de code. Il s’agit bien d’une intégration
de tout nouveau composant applicatif.

Chaque changement de code déclenche automatiquement l’exécution des éléments de la chaîne

d’intégration continue.

Environnement de développement (IDE)

Au départ de toute fabrication de logiciel, il y a le code source qu’un développeur produit. Ce code est
constitué d’une série de lignes de caractères alphanumériques compréhensibles uniquement dans le
langage de programmation qui a servi à l’écrire. Ce code est la transcription informatique d’un besoin
métier (exemple : "Afficher la liste des commandes du mois de mai 2015 pour le produit P, à partir d’une
région saisie en paramètre").

© Editions ENI - Tous droits réservés - Copie personnelle de kokou Agbedanou -2-
 kokou Agbedanou

Le développeur a aujourd’hui des outils à sa disposition permettant de lui faciliter le travail : il s’agit des
IDE et des frameworks de développement.

Gestionnaire de versions de code source

Le développeur stocke le code source sur son PC de développement mais il doit aussi le stocker sur un
dépôt centralisé afin de pouvoir le partager avec d’autres développeurs et/ou faire en sorte que le
gestionnaire d’intégration continue puisse lancer la chaîne.

Les étapes, pour un développeur, sont les suivantes :

ˇ
Installation d’un client de gestion de version sur le PC local.
ˇ
Clonage du dépôt central présent sur un serveur vers le dépôt local sur le PC local. À ce stade,
le développeur est autonome et peut développer dans son dépôt local.
ˇ
Partage du code source modifié quotidiennement, à partir du dépôt local, vers le dépôt central.

Les principaux gestionnaires de versions de code source sont : Git, GitLab, GitHub, CVS, Subversion et
Mercurial.

Gestionnaire d’intégration continue

Immédiatement après la phase de codage vient la phase d’initialisation de l’intégration continue à l’aide de
l’orchestrateur central qui permet de lancer les tests unitaires et l’analyse de code, puis de lancer la
compilation et la fabrication d’un build. Le résultat du build est visible via une interface web ; il peut
également être inséré dans un workflow avertissant le développeur du résultat du build. Le job permettant
de lancer le build peut également ne pas aller au bout de la fabrication si la qualité de code n’est pas en
phase avec les critères de qualité de code établis.

Les principaux outils sont Jenkins (fork de Hudson), TeamCity (Microsoft), CruiseControl, Tinderbox
(Mozilla)…

© Editions ENI - Tous droits réservés - Copie personnelle de kokou Agbedanou -3-
 kokou Agbedanou

 Jenkins est très populaire pour les développements Java. Il peut également être
utilisé pour les développements PHP. Jenkins comporte de nombreux plug-ins
(pipeline pour visualiser le statut des étapes de la chaîne, buildbreaker pour
stopper la fabrication d’un build, gestion de code source, gestion de triggers,
gestion de notification, gestion du monitoring...). Les plug-ins sont disponibles sur
http://wiki.jenkins-ci.org/display/JENKINS/Plugins.

Gestionnaire de qualité de code

La qualité de code est une étape obligatoire à prendre en compte lors de la fabrication d’une application.
Elle peut être mesurée a priori ou a posteriori. Dans ce dernier cas, quelle que soit la qualité du code, la
fabrication de l’application est toujours effectuée. L’analyse de code sert aux développeurs et aux
managers à des fins d’amélioration continue.

Les principaux gestionnaires de qualité de code sont SonarQube et Jacoco.

Gestionnaire de tests

Les tests unitaires d’intégration doivent être développés immédiatement après avoir effectué le
développement du code ou pendant l’écriture du code. Ces tests permettent de valider séparément un
composant applicatif sans prendre en compte des relations avec d’autres composants.

Les principaux gestionnaires de tests sont Junit (tests unitaires pour Java), PHPUnit (tests unitaires pour
PHP), Selenium et Behat pour les tests fonctionnels.

2. Livraison continue (continuous delivery)

La livraison continue concerne toute la chaîne d’intégration continue et son automatisation : à partir du
dépôt des sources, enchaînement automatisé des tests unitaires, des tests d’intégration, des tests métier
mais cela s’arrête là. Le déploiement en production est toujours effectué de façon manuelle.

© Editions ENI - Tous droits réservés - Copie personnelle de kokou Agbedanou -4-
 kokou Agbedanou

Schéma de la livraison continue

3. Déploiement continu (continuous deployment)

Le déploiement continu reprend le même chaînage que son petit frère, le développement continu, mais
pousse l’automatisation jusqu’au déploiement automatisé de l’application en production.

En réalité, peu d’entreprises sont dans ce modèle, tant la zone de production est sous contrôle manuel des
OPS et le déploiement continu n’est pas ITIL compliant.

Schéma du déploiement continu

4. Tests

Lorsque le code est produit, il faut le tester ; il existe plusieurs types de tests.

a. Les tests unitaires

Définition

Les tests unitaires (TU) sont les premiers tests à être effectués sur le code ; il s’agit de tester une partie du
programme ou du module, de façon indépendante du reste du programme ou des autres modules. Les TU
doivent être exécutés durant le développement

© Editions ENI - Tous droits réservés - Copie personnelle de kokou Agbedanou -5-
 kokou Agbedanou

afin de détecter rapidement les erreurs.

La couverture de code permet d’indiquer une mesure de passage des TU sur le code.

Chaque test unitaire doit pouvoir être rejoué après une modification afin de vérifier la non-régression de
l’application.

Exemple de test unitaire avec PHPUnit

Les étapes sont les suivantes :

1) Installation de PHPUnit sur le serveur Linux de test unitaire :

# yum install phpunit

2) Écriture d’un code PHP : Bonjour.php

Le programme Bonjour.php contient une classe Personne qui va permettre d’instancier une personne
(attribut nom et fonctions getName, setName et Bonjour).

<?php
class Personne {
protected $nom;

public function getName() {

return $this->nom;
}

public function setName($nom) {

$this->nom = $nom;
}

public function Bonjour() {

return "Bonjour";
}
}

© Editions ENI - Tous droits réservés - Copie personnelle de kokou Agbedanou -6-
 kokou Agbedanou

3) Écriture d’un test PHP sur le code : BonjourTest.php

Le programme BonjourTest.php est le programme qui sera lancé par phpUnit pour effectuer le test
unitaire. Tous les tests sont donc à écrire dans ce programme.

Il faut nécessairement inclure la classe à tester (Bonjour.php) et Autoload.php qui permet de charger les
fonctionnalités de phpUnit. Il faut aussi définir la classe de test BonjourTest avec une option extends
PHPUnit_Framework_TestCase.

<?php
//classe de test unitaire
require_once "PHPUnit/Autoload.php";
require_once "Bonjour.php";

class BonjourTest extends PHPUnit_Framework_TestCase

{
// test de la méthode Bonjour
public function testBonjour() {
// création d'une instance de Personne
$personne = new Personne();

// gestion des attendus du test

$attendu = "Bonjour";
$actuel_state = $personne->Bonjour();
$this->assertEquals($attendu, $actuel_state);
}
}

La méthode assertEquals()retourne un résultat binaire : Equal (le test a réussi)/Not Equal (le test
a échoué).

4) Lancement de la commande phpunit BonjourTest BonjourTest.php:

© Editions ENI - Tous droits réservés - Copie personnelle de kokou Agbedanou -7-
 kokou Agbedanou

# phpunit BonjourTest BonjourTest.php

phpunit BonjourTest.php BonjourTest.php
PHPUnit 4 .6.5 by Sebastian Bergmann and contributors.

Time: 80 ms, Memory: 3.75Mb

OK (1 test, 1 assertion)

Le résultat "." indique que le test a réussi.

5) Modification du fichier BonjourTest.php en modifiant le test :

// gestion des attendus du test

$attendu = "Au revoir";
$actuel_state = $personne->Bonjour();
$this->assertEquals($attendu, $actuel_state);

Le test attend "Au revoir" alors que la fonction Bonjour() retourne "Bonjour" ; le test doit en principe
échouer.

6) Lancement du test :

# phpunit BonjourTest BonjourTest.php

PHPUnit 4 .6.5 by Sebastian Bergmann and contributors.

Time: 77 ms, Memory: 4.00Mb

There was 1 failure:

© Editions ENI - Tous droits réservés - Copie personnelle de kokou Agbedanou -8-
 kokou Agbedanou

1) BonjourTest::testBonjour
Failed asserting that two strings are equal.
--- Expected
+++ Actual
@@ @@
-'Au revoir'
+ 'Bonjour'

/src/BonjourTest.php:16

FAILURES!
Tests: 1 , Assertions: 1 , Failures: 1 .

Le test a échoué : le mot-clé de retour du test est F qui signifie "Fails".

Les outils des tests unitaires : xUnit

Afin de réaliser les tests unitaires, il faut installer un framework de test basé sur des outils adéquats par
rapport au langage de programmation.

Langage Outil

PHP PHPUnit

Java JUnit

JavaScript JSUnit

Python PyUnit

Perl Test:More

... ...

© Editions ENI - Tous droits réservés - Copie personnelle de kokou Agbedanou -9-
 kokou Agbedanou

Le Test-Driven Development (TDD)

Le TDD est une méthode de développement piloté par les tests. Le principe est d’écrire un test qui va
échouer car la fonction n’est pas développée puis ensuite de la développer, de la tester…

Les six étapes du TDD sont les suivantes :

1) Créer un test TU.

2) S’assurer qu’il est en échec.

3) Coder ce qu’il manque.

4) Exécuter le TU.

5) Refactorer le code.

6) Retourner à l’étape 1.

Conclusion sur les TU

Un code testé est un code robuste, réutilisable et évolutif car il a été... corrigé (refactoré) après une
succession d’échecs de TU.

b. Les tests métier

Les tests métier ou tests fonctionnels font également partie de la chaîne de développement logiciel et
sont sous la responsabilité de l’équipe de test.

L’objectif ici est de tester et d’automatiser dans son ensemble l’application (souvent difficile à effectuer) en
écrivant des scénarios de tests métier. Il est également possible de tester et d’automatiser des
enchaînements de modules applicatifs.

Exemples de tests métier

1) "Je veux passer une commande de produit sur un site web, je vérifie que mon compte est bien créé, que
je reçois un mot de passe de type OTP (One Time Password), je passe la commande, je suis débité...".

2) "Je lance l’application Bonjour.exe, je saisis mon nom, j’obtiens « Bonjour <nom> »".

© Editions ENI - Tous droits réservés - Copie personnelle de kokou Agbedanou - 10 -

 kokou Agbedanou

Plusieurs outils permettent d’effectuer les tests métier. Côté logiciel libre, il y a Selenium
(http://www.seleniumhq.org/), pour les tests côté front office web et Behat (http://docs.behat.org
/en/v2.5/) pour les tests de logique applicative, Cucumber (https://cucumber.io/)...

Il existe également des produits propriétaires : Rational Functional Tester (RFT) d’IBM, QF test
(http://www.qfs.de/en/index.html) de Quality First Software, SilkTest/TestPartner de MicroFocus, Unified
Functionnal Teststing (UFT) et ex-QuickTest Pro de HP, etc.

Pour que les tests puissent être automatisés, il faut que les produits de tests soient "ouverts" via des API
et il faut insérer le lancement des tests dans le pipeline de la chaîne de développement.

À noter que l’automatisation des tests fonctionnels est une opération longue et donc forcément coûteuse
qui intervient après une certaine maturité des équipes en matière d’usine de développement logiciel.

5. Conclusion sur la chaîne de développement

Les métiers exigent sans cesse des business cases nouveaux qui doivent être délivrés le plus rapidement
possible. Pour réussir ce challenge, il faut des processus permettant un delivery automatisé. La chaîne de
développement prend du temps pour être opérationnelle ; elle nécessite des outils indispensables :

ˇ
L’environnement de développement local du développeur (IDE, outils spécifiques...).
ˇ
L’intégration continue.
ˇ
L’analyse de code.
ˇ
Les tests unitaires et fonctionnels.
ˇ
Les tests techniques (intégration, performance et sécurité).

Toute cette chaîne peut être construite avec des outils open source.

© Editions ENI - Tous droits réservés - Copie personnelle de kokou Agbedanou - 11 -

 kokou Agbedanou

 Les nouvelles technologies de PaaS avec les containers, s’appuyant sur les IaaS
hybrides, vont bouleverser et encore plus automatiser la production logicielle.

© Editions ENI - Tous droits réservés - Copie personnelle de kokou Agbedanou - 12 -