Chapitre 5.3.1
La production

On appelle "environnement" une copie de l'infrastructure permettant d'exécuter le logiciel et les outils dont il a besoin. Il s'agit donc de faire tourner le code, mais aussi la base de données, le cache et toutes les autres dépendances.

Les environnements ne sont pas une science exacte. Chaque entreprise adapte son cycle de développement et ses environnements selon ses besoins.

Nous allons voir les plus communs.

Production

L'environnement de production, ou "prod" pour les intimes, est l'environnement final où le logiciel est déployé pour être utilisé par les utilisateurs.
C'est l'objectif ultime du cycle de développement, où tout doit fonctionner de manière fiable, sécurisée et performante. On y branche donc des outils de surveillance pour s'assurer en permanence du bon fonctionnement. Le nombre de ventes vient de tomber à 0 depuis 5 minutes : on envoie directement un SMS à l'astreinte.

On appelle "mise en production" (MEP) l'action de déployer sur cet environnement du code ou une dépendance.

Pour faciliter leur cycle de travail, les développeurs, notamment lorsqu'ils travaillent en équipe, préfèrent tout découper en petites tâches.
Dès que possible, ce sera un découpage fonctionnel : on itère sur une fonctionnalité pour à chaque fois apporter plus de valeur au client.
Pour certains sujets, on préfèrera un découpage purement technique : on sort les pièces du puzzle les unes après les autres pour tout emboîter à la fin. Ça arrive notamment sur les projets difficilement itérables. Par exemple, on ne peut pas exposer au client la moitié d'un moyen de paiement : avant l'ouverture, il faut avoir géré les remboursements, les rapports financiers, les outils pour le service client...

Dans l'idéal, ces petits morceaux sont déployés très rapidement en production. Sortir au fur et à mesure rend la MEP moins dangereuse :

• Moins de choses à tester et surveiller.
• Les anomalies sont localisées rapidement.
• Le retour en arrière est plus facile. On appelle ça un "rollback".

Quand un développeur dit que son code est en production, ça signifie juste qu'il est physiquement présent dans l'infrastructure de l'environnement de production. Il peut ne pas encore être ouvert aux clients.

Les deux techniques les plus utilisées pour déployer du code sans l'activer :

1. 99% du code est en production mais aucun scénario ne l'utilise. On s'assure qu'il n'y a pas de régression. La dernière MEP lance le point d'entrée vers la fonctionnalité.
2. Utiliser un commutateur de fonctionnalité (feature toggle). 100% du code est en production mais on a placé dedans un interrupteur. L'activation de la fonctionnalité se base sur une configuration, bien souvent située en dehors du code. On peut donc manipuler l'interrupteur sans déclencher de mise en production.

Les systèmes de feature toggle avancés offrent des options intéressantes :

• Restriction aux internes : accès seulement via les adresses IP de l'entreprise. Ça permet la "prod cachée" : on manipule la nouvelle fonctionnalité en prod tandis que les clients utilisent toujours l'ancienne version.
• Déploiement progressif : ouverture pour un petit pourcentage d'utilisateurs. Si tout se passe bien pour eux, on continue, sinon, on revient en arrière. Cette stratégie se nomme un "canari", en référence aux canaris utilisés dans les mines pour détecter les niveaux de gaz dangereux.