kokou Agbedanou

Les zones de travail de l’UDD

Dans une usine de production IT, il est impératif de construire des zones de travail disjointes avec des
rôles bien distincts. Habituellement, les zones suivantes sont à prendre en compte :

ˇ
zone de développement
ˇ
zone d’intégration
ˇ
zone bac à sable
ˇ
zone de tests
ˇ
zone de préproduction
ˇ
zone de production

1. La zone de développement

Les zones de développement (ici, il s’agit de zones permettant aux développeurs d’applications de
produire du code, de créer des outils de scripting...) peuvent être vues de deux façons.

a. Environnement local autonome

Tout l’outillage permettant de produire du code est installé en local sur le PC du développeur. Celui-ci est
autonome et peut produire du code sans besoin de liens réseau. Pour cela, il doit disposer d’un
environnement de travail standardisé et commun avec les autres développeurs de son équipe ou de
l’entreprise ; cet environnement peut être composé des éléments suivants :

ˇ
Un environnement de travail intégré de type IDE (Integrated Development Environment), par
exemple, PHPStorm, Eclipse, WebStorm...
ˇ
Du middleware permettant de produire le service applicatif (database Oracle Express, Oracle,
MySQL, PostgreSQL, PHP...).

La distribution XAMPP (https://www.apachefriends.org/fr/index.html) permet de faire

cohabiter sur un même PC plusieurs applications dans des versions de

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

middleware différentes : une application développée en PHP 5.2 + MySQL, une application
développée en PHP 5.4... Elle contient une suite de programmes open source (Apache, Perl,
PHP et MySQL). Une matrice de compatibilité permet de savoir à l’avance ce qu’il est possible
de faire cohabiter sur un même ordinateur sans que cela soit problématique :

XAMPP Apache MySQL PHP 5 PHP 4

1.6.0 2.2.3 5.0.33 5.2.1 4.4.5

1.6.0a 2.2.4 5.0.33 5.2.1 4.4.5

1.6.1 2.2.4 5.0.37 5.2.1 4.4.6

1.6.2 2.2.4 5.0.41 5.2.2 4.4.7

1.6.3 2.2.4 5.0.54 5.2.3 4.4.7

1.6.3a 2.2.4 5.0.45 5.2.3 4.4.7

1.6.4 2.2.6 5.0.45 5.2.4 4.4.7

1.6.5 2.2.6 5.0.51 5.2.5 4.4.7

1.6.6 2.2.8 5.0.51 5.2.5 4.4.8 (RC2)

1.6.6a 2.2.8 5.0.51a 5.2.5 4.4.8

1.6.7 2.2.9 5.0.51b 5.2.6 4.4.8

1.6.8 2.2.9 5.0.67 5.2.6 4.4.9

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

1.7.0 2.2.11 5.1.30 5.2.8 -

1.7.1 2.2.11 5.1.33 5.2.9 -

1.7.2 2.2.12 5.1.37 5.3.0 -

1.7.3 2.2.14 5.1.41 5.3.1 -

1.7.4 2.2.17 5.5.8 5.3.5 -

1.7.5 2.2.21 5.5.15 5.3.8 -

1.7.7 2.2.21 5.5.16 5.3.8 -

1.8.0 2.4.2 5.5.25a 5.4.4 -

1.8.1 2.4.3 5.5.27 5.4.7 -

1.8.2 2.4.10 5.5.39 5.4.31 -

1.8.3 2.4.10 5.6.20 5.5.15 -

5.5.19 2.4.10 5.6.21 5.5.19 -

5.6.3 2.4.10 5.6.21 5.6.3 5.1.0

5.6.4 2.4.10 5.6.21 5.6.3 5.2.0

5.5.24 2.4.12 5.6.24 5.5.24

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

5.6.8 2.4.12 5.6.24 5.6.8

Source : http://code.stephenmorley.org/articles/xampp-version-history-apache-mysql-php/

 Les dernières versions de XAMPP contiennent également des outils comme

phpMyAdmin, OpenSSL, XAMPP control panel, Webalizer, Mercury Mail
Transport System, FileZilla FTP server, Tomcat et Perl.

 XAMPP permet aux développeurs de s’affranchir des problèmes d’installation de

middlewares et d’avoir des environnements facilement installables et rapidement
utilisables.

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

XAMPP Control Panel

ˇ
Des sources dans un dépôt local de gestionnaire de sources (un clone d’un dépôt central de
type GIT par exemple).

Ce type d’environnement contraint le développeur à l’utilisation de bonnes pratiques (pas d’appels à des
serveurs avec adresses IP écrites en dur dans le code ou dans des fichiers de paramètres, pas d’appel à
des partages NFS/Samba divers et variés, rapidité d’exécution locale...).

b. Environnement virtualisé

Ce cas est plus fréquent dans les équipes de développement mais plus complexe à gérer et à maintenir ;
en effet, souvent, de multiples VM sont présentes sur le réseau de

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

l’entreprise avec des cas de figure divers :

ˇ
Une VM par application et dédiée à un développeur ; ce dernier a ainsi autant de VM que
d’applications en cours de développement.
ˇ
Une VM avec du code source partagé par les développeurs de l’équipe. Ce type de
configuration peut poser des problèmes en cas de mise à jour de version de middleware
couplée à une mauvaise communication au sein des équipes.

Les machines de développement sont très souvent exclues du périmètre de l’équipe infrastructure, ce qui
rend délicate la tâche de maintenance par les équipes de développement elles-mêmes, mais cela n’est pas
leur métier. Chaque équipe de développement est alors libre d’installer ses propres outils (Vagrant,
VirtualBox, VMware...) pour la virtualisation et de plus en plus Docker pour la containerisation, ses
gestionnaires de sources (GIT, CVS, Subversion... ou même un dépôt de source dans le cloud, comme
Bitbucket), ainsi que ses environnement de développement divers.

 Cette approche de grande liberté, même si elle fonctionne au quotidien, est source
de gaspillage dans la productivité des équipes ; le manque de gouvernance nuit au
final à l’entreprise.

2. La zone d’intégration

Cette zone est fondamentale dans le processus de développement de l’UDD ; en effet, c’est la zone qui
permet aux développeurs de disposer d’une ou plusieurs VM contenant tous les éléments permettant
d’effectuer l’intégration de l’application dans son intégralité (accès Internet, composants externes réseau,
accès périphériques...). L’application sort de sa zone de développement et de ses tests unitaires pour
franchir une autre zone permettant d’effectuer des tests d’intégration. Les dernières fonctionnalités sont
testées et l’intégration devient iso-production, en ce sens que les serveurs sont configurés avec le même
middleware et la même infrastructure que la production.

Ces environnements sont créés de façon automatique par un automate qui provisionne la VM et le
middleware mais qui fait aussi l’installation toutes les nuits des nouvelles

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

fonctionnalités de l’application. Chaque nuit, les données de la production doivent être redescendues sur
l’environnement d’intégration.

Exemple de code pour du provisionning automatique sur une plate-forme RHEV :

Méthode Description fonctionnelle

createVm(java.lang.String templateName, Création d’une VM à partir d’un

java.lang.String networkName, template
java.lang.String clusterName,
java.lang.String vmName, int maxWait)

cloudInit(java.lang.String vmName, Démarrage de la VM avec CloudInit

java.lang.String osUser,
java.lang.String osPassword,
ConfigIp configIp,
java.lang.String networkName, int maxWait)

init(java.lang.String urlApiRHEV, Connexion à l’API RHEV-M

java.lang.String userRHEV,
java.lang.String passwordRHEV)

3. La zone bac à sable

Cette zone est fondamentale car elle permet d’effectuer des interventions sur une plate-forme qui n’est
pas considérée en production au sens ITIL. Cette zone peut être matérialisée par des machines Bare-Metal
ou des machines virtuelles.

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

4. La zone de tests

Cette zone est souvent omise. Pourtant, son rôle est nécessaire et elle est dévolue aux équipes de testing
qui peuvent jouer les scénarios de tests, modifier les bases de données ou s’assurer que les dernières
fonctionnalités passent sans bug.

C’est une zone qui dispose de VM se prêtant très bien au mode jetable et donc au
provisionning/déprovisionning en fonction de la version de logiciel testée.

5. La zone de préproduction

La zone de préproduction est une zone iso-production avec ses contraintes en termes de sécurité (règles
de firewalling appliquées), de gestion DNS, noms de domaines et certificats SSL/TLS, de load-
balancing/fail-over.

L’accès n’est possible que pour l’équipe de production qui effectue l’installation des softwares packages.

L’équipe de développement effectue les tests de préproduction pour s’assurer que l’application rend le
service demandé.

Cette zone permet de pousser des correctifs et de tranquilliser les équipes de production qui peuvent ainsi
disposer d’une copie de la production sans les contraintes clients en matière de disponibilité.

C’est la dernière étape avant la mise en production.

6. La zone de production

La zone de production est la zone comprenant les applications installées sur les serveurs et qui sont
accessibles aux utilisateurs (usagers internes au sens ITIL et clients). Cette zone est supervisée et sous la
responsabilité de l’équipe d’exploitation.

Encore faut-il définir ce qui se cache derrière le mot "exploitation".

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

a. L’exploitation d’infrastructure

C’est le rôle qui est le plus présent en entreprise. L’équipe de "prod" s’occupe du système, du réseau, de la
téléphonie sur IP, de la messagerie, de la sécurité... c’est-à-dire des couches dites basses. Elle installe les
machines virtuelles, les firewalls ou les datacenters. Dans le monde DevOps, elle correspond aux "OPS".

Elle fonctionne souvent en mode ITIL (avec un helpdesk et un service desk) et a besoin de documents de
mise en production (MEP) qui sont des tutoriels d’installation de l’application.

Une équipe de production doit disposer de documents décrivant des scénarios de tests simplifiés et, si
besoin, exhaustifs des applications en production. Ces scénarios permettent de tester en autonomie, sans
faire appel aux équipes de développement, les principales fonctionnalités (page de connexion, accès au
menu Vente, impression...).

Les développeurs développent, effectuent l’intégration et ensuite transmettent le software package à la

production d’infrastructure.

Mais souvent cette équipe ne connaît pas bien l’application et ne sait pas corriger en cas de coup dur. Elle
doit donc faire appel aux développeurs qui détiennent la connaissance de l’application mais ceux-ci n’ont
pas accès à la production si ITIL est bien en place dans l’organisation. Il faut donc créer des passe-droits
avec des accès root pour certains développeurs sur les machines de production.

C’est un cercle sans fin qui n’amène que confusion entre les équipes et insatisfaction auprès des clients.

b. L’exploitation applicative

Ce type d’équipe connaît bien les applications dont elle a la charge ; elle sait se connecter à une base de
données ou à un système de log pour corriger un bug. Elle est indispensable dans une grosse organisation
aux multiples applications.

Elle doit accéder à la production sous contrôle et cela peut s’exercer de plusieurs façons :

ˇ
Accès via un proxy d’authentification permettant de loguer toutes les actions effectuées sur la
production. Des systèmes comme AdminBastion de Wallix (http://www.wallix.com/fr/produits
/wallix-adminbastion) ou AdminProxy

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

(http://www.adminproxy.org/) permettent d’effectuer ce type de tâche.

ˇ
Accès avec compte nominatif (et non générique) et droits Read/Write sur les dossiers
applicatifs.

c. Une nouvelle tendance

De plus en plus, une troisième voie se dessine, celle de responsabiliser les développeurs eux-mêmes à des
tâches de production et d’exploitation de leurs applications.

L’équipe de développement, qui crée les services applicatifs, dispose alors des droits d’administrateurs sur
les machines de production concernées. De fait, elle effectue le travail de l’équipe d’exploitation
applicative mais pas celui de l’équipe d’exploitation d’infrastructure dont le métier est de créer et exploiter
des services d’infrastructure.

Le mouvement DevOps se matérialise par la création d’équipes de développement qui disposent de

compétences autrefois dédiées aux équipes de production.

Pour cela, elles doivent disposer d’outils de monitoring applicatifs puissants. La stack libre ELK pour
Elasticsearch/Logstash/Kibana (https://www.elastic.co/products) permet d’implémenter ce fameux
monitoring applicatif. D’autres solutions propriétaires comme Splunk (http://fr.splunk.com/) existent
également.

d. L’étape ultime

Aucun accès humain à la zone de production applicative n’est autorisé.

Pour corriger un bug, il faut corriger le bug au tout début de l’UDD et repousser en automatique le correctif
sur les machines de production. C’est d’ailleurs l’approche choisie par les équipes d’AWS : lorsqu’une
application plante, il faut corriger le code source et relancer la création d’un build puis pousser en
automatique sur la production.

De même, pour rajouter de la puissance machine (CPU, RAM, instances...), c’est l’automate qui le fait en
automatique.

Si toute la chaîne de production est correctement outillée selon les règles de l’art, les tests (unitaires,
performance, sécurité, métier...) sont préalablement exécutés et les correctifs effectués avant la mise en
production. La mise en production s’effectue donc de façon continue ; c’est le concept de déploiement
continu (continuous deployment), suite logique

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

 kokou Agbedanou

de l’intégration continue (continuous integration).

7. Schéma d’ensemble des zones de travail

Le schéma suivant décrit une synthèse des différentes zones.

Schéma d’ensemble des zones de travail

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