Project Guardrails : Environnements de provisionnement

Cette série de brefs articles est composée de quelques choses que j’ai apprises au cours des dernières années de projets basés dans le domaine dans lequel nous (en supposant que vous lisez ceci venant de la même partie de l’industrie que moi 🙂) travailler.

Si vous venez de tomber dessus, la série couvre certains facteurs importants pour un projet :

1. Il ne devrait pas y avoir de «conception par un comité ». "
2. Personne d’autre que l’équipe de développement principale ne devrait être en mesure d’assurer le développement, la mise en scène et la production.
3. Personne ne devrait être capable d’écrire en production, sauf l’équipe de développement (et même dans ce cas, il devrait y avoir un processus de déploiement).

Je n’aime pas vraiment établir des règles strictes et rapides comme celle-ci, notamment parce que les choses changent avec le temps, soit par nécessité, soit par plus d’expérience. C’est pourquoi j’aime les "lignes directrices".

Mais au moment d’écrire ces lignes, ce sont les choses que je vois se dérouler.

Environnements de provisionnement

Au cours des dernières années, nous avons fait beaucoup de progrès dans la rapidité avec laquelle nous pouvons provisionner nos systèmes afin qu’ils se reflètent tous (ou généralement). Cela inclut nos boîtiers de développement, la façon dont nos machines locales reflètent la mise en scène et la façon dont la mise en scène reflète la production.

Provisionnement d’un nouvel environnement, plus ou moins. Roulez avec.

C’est-à-dire si cela "fonctionne sur ma machine" devrait être vrai. Pas une excuse pour ne pas pouvoir reproduire un bug.

Et quand c’est vrai, c’est probablement vrai sur les machines des autres, sur la mise en scène et la production. Et c’est sympa, non? Je veux dire, nous faisons tourner nos boîtes, déployons nos scripts ou faisons ce que nous faisons, puis nous avons la configuration dont nous avons besoin.

Alors, qu’est-ce que cela signifie d’aborder les environnements de provisionnement ? Cela dépend de l’environnement auquel vous faites référence.

À quoi cela ressemble-t-il vraiment ?

Si vous travaillez dans WordPress, ce que je suppose si vous lisez ceci, cela suppose que vous utilisez au moins un serveur Web, une base de données et PHP.

Un environnement de développement peut ressembler à ceci :

• Apache de Nginx ,
• MySQL qui est le plus courant,
• Au moins PHP 5.2.4 (avec PHP 7.1 recommandé),
• Ou quelque chose de comparable.

Vous pouvez également utiliser quelque chose comme Laravel Valet ou quelque chose comme VVV. Tout dépend de la nature de votre travail.

De plus, selon la nature de votre entreprise, vous pouvez avoir un IDE qui vous est attribué ainsi que divers fichiers de configuration pour appliquer certaines règles.

Et le reste des environnements ?

Comme d’habitude:

• le développement fait référence à la configuration sur votre machine locale,
• la mise en scène fait référence à la zone dans laquelle vous et les parties prenantes pouvez tester,
• et la production est l’endroit où réside l’application.

Mais cela semble également différent selon l’endroit où vous travaillez, la façon dont votre travail est organisé, etc. Il ne s’agit pas tant de savoir comment il est utilisé – il s’agit de savoir comment il est utilisé.

Mise en scène

Cela sera généralement provisionné sur un serveur (ou un groupe de serveurs selon la taille du projet) sur lequel vous pourrez déployer votre dernier code pour le tester. Il peut inclure des fonctionnalités partielles, des données de test et uniquement un sous-ensemble d’informations de la production (si vous choisissez d’extraire ces informations, à savoir la base de données, de l’environnement de production).

Cela vous donne, à vous et aux autres parties prenantes, la possibilité d’examiner ce qui se passe et comment cela fonctionnera en production sans avoir à vous soucier de détruire quoi que ce soit de sensible.

Le code est généralement déployé à partir d’une branche, généralement master, à partir de votre référentiel Git (si c’est ce que vous utilisez). Et des outils tels que DeployBot, CircleCI, Travis CI, GrumPHP, Behat, etc. sont également utilisés pour évaluer la qualité du code, exécuter des tests automatisés, puis enfin déployer le code.

En fin de compte, chaque environnement sera provisionné de manière à pouvoir être rapidement mis en miroir sur les machines locales, les serveurs intermédiaires et les serveurs de production. De plus, il devrait être facile de pousser et d’extraire des données entre eux pour faciliter le travail avec les données.

Production

Enfin, la production concerne le projet de fonctionnement réel; Cela signifie que le serveur, l’application et la base de données s’exécutent conjointement et sont utilisés par les utilisateurs.

Cela signifie également que le code est dans un endroit stable. Il existe probablement des mécanismes de journalisation en place qui informeront l’équipe de développement de tout problème. Aucun changement de code ne doit se produire dans cet environnement sans qu’il ait d’abord passé l’AQ ou la mise en scène.

Et les processus en place ?

Bon, disons que vous travaillez avec une configuration traditionnelle, faute d’un meilleur terme, où tous vos déploiements sont effectués via S/FTP dans un environnement de production (ou même de mise en scène). De cette façon, les utilisateurs peuvent extraire des fichiers, apporter des modifications et les remonter.

Ce n’est pas bon.

Cela signifie que toute personne disposant des informations d’identification peut se connecter, apporter les modifications et contourner le contrôle des sources, l’intégration continue, les outils d’assurance qualité, etc., effectuer les modifications souhaitées.

Elle sape l’ensemble des processus mis en place. Non seulement cette procédure standard de contournement (qui est en place pour une raison, bien sûr), mais elle finit par casser le code qu’un développeur ou une équipe de développeurs a sur leurs machines principalement parce que ce qui est en production n’est plus synchronisé avec le référentiel du code.

De plus, ce code pourrait être réparti entre les succursales qui doivent encore être fusionnées ou déployées. Cela nous laisse avec une variété de situations dans lesquelles les développeurs et les clients ont rompu une partie du processus de construction et donc l’ensemble du projet.

Quand vient le temps de vérifier la production, elle n’est pas synchronisée avec le développement et la mise en scène, et personne ne sait pourquoi. Au moment du déploiement, les modifications sont écrasées et les responsables ont perdu ce qu’ils pensaient voir.

Qu’est-ce qu’une équipe doit faire ?

Je ne sais pas s’il y a une bonne réponse à cela, mais plus je travaille longtemps dans cette industrie, plus je pense que l’entreprise – ou les entreprises – responsable de la construction de la solution pour le client devrait avoir le contrôle du processus de bout en bout. finir.

• Les concepteurs sont responsables de la gestion de leurs domaines de création de concepts, de maquettes, de création de modèles de démonstration et de sollicitation de commentaires,
• Les chefs de projet sont responsables de la communication avec les départements,
• Les développeurs sont responsables de la mise en œuvre de la solution et de la liaison entre le travail des concepteurs et le back-end fonctionnel,
• Le client est chargé d’examiner les modifications, de fournir des commentaires et de fournir toute autre information nécessaire à l’exécution de la tâche.

Cela signifie que lorsqu’il s’agit de configurer le domaine, l’hébergement, les environnements, le contrôle de version, le processus de construction et l’intégration continue, et tout ce que j’ai négligé de mentionner, incombe directement à l’équipe de développement.

Restez dans les tranchées, restez sur la cible (mais faites attention à ceux qui vous entourent).

En termes simples, ce ne sont pas les responsabilités du client et elles ne devraient pas l’être. Les limites de responsabilité doivent être définies, maintenues et respectées dans toutes les équipes – pas seulement les développeurs et les clients ou les clients et les concepteurs ou les concepteurs et les développeurs, etc.

Et après?

Dans le prochain article, je parlerai des responsabilités des développeurs (et des autres parties prenantes) dans la maintenance des environnements pour le code.

Autrement dit, qui devrait être responsable de quoi et qui a accès pour lire et écrire quelles données et comment cela peut finalement avoir un impact sur le résultat du projet.