Le gestionnaire veut un environnement combiné de développement et de production
Je travaille dans une petite équipe de programmation soutenant une organisation plus grande. Cette année, notre responsable a décidé d'utiliser les technologies Oracle Apex pour gérer la grande majorité des données de notre entreprise.
Ce serait correct, sauf que nous n'avons qu'un seul serveur Apex. Notre manager a décrété que tout se passait dans ce seul cas. Notre équipe est en train de développer des applications, tandis que notre manager en fait la démonstration, et nos clients internes les utilisent, ce qui pour des raisons évidentes pose déjà des problèmes!
Je ne peux que m'attendre à ce que cela empire à mesure que nous investissons davantage dans Apex, les applications deviennent plus complexes et le nombre d'utilisateurs augmente. J'ai entendu dire que la meilleure pratique est d'avoir des environnements de développement, de test et de production séparés, mais pourquoi est-ce le cas?
La question: Pourquoi devrions-nous avoir des environnements de développement, de test et de production séparés?
Pourquoi devrions-nous avoir des environnements de développement, de test et de production distincts?
Vous avez plusieurs activités en cours simultanément:
- développement - où les développeurs commettent du code, font des erreurs, expérimentent, etc ...
- tests - où les tests sont exécutés, manuellement ou automatiquement, et en raison de la complexité, peuvent consommer beaucoup de ressources.
- production - où de la valeur est créée pour les clients et/ou l'entreprise
Voulez-vous que tout cela se passe dans le même environnement? Voulez-vous que l'entreprise s'arrête, car un nouveau test a poussé vos serveurs à échanger sur des disques durs et consomme tous les cœurs du processeur? Voulez-vous que vos tests s'arrêtent parce qu'un développeur a fabriqué une bombe fourchue alambiquée à partir d'une expérience de mise à l'échelle? Voulez-vous que le code que vous pensiez fonctionner en raison de la ficelle et du ruban adhésif d'un développeur dans les tests s'exécute en production? Voulez-vous que les développeurs travaillent avec des données de production potentiellement sensibles (je sais que ce n'est pas un problème dans toutes les entreprises, mais c'est dans beaucoup d'entre elles)?
Qu'est-ce qui empêche ces problèmes de se produire?
Environnements séparés.
Alors de quoi avez-vous besoin?
Vous avez besoin d'environnements séparés.
Pour le mettre formellement
Vous avez besoin d'environnements distincts pour les raisons suivantes:
- pour réduire les risques de bloquer le développement commercial et logiciel.
- pour réduire les risques de mise en production de code ayant réussi les tests en raison du montage ad hoc des développeurs.
- pour réduire les risques que les données de production ne tombent entre de mauvaises mains (très important lorsque les organisations traitent des données sensibles, comme les numéros d'identification et les informations financières et sanitaires) ou qu'elles soient mêlées aux données de test ou détruites.
Pour votre contexte, une nouvelle plateforme technologique
Peut-être que ce n'est pas encore vraiment de la production (car c'est une plate-forme relativement nouvelle), mais vous obtiendrez vos environnements distincts lorsque l'entreprise commencera à en dépendre et ils sont soit assez sages pour prévoir le risque ou le réaliser en apprenant le dur façon.
J'ai entendu dire que la meilleure pratique est d'avoir des environnements de développement, de test et de production séparés, mais pourquoi est-ce le cas?
Ce n'est pas si clair de nos jours.
De nombreux endroits ne font plus de tests manuels, donc n'ont pas de données de test en soi. Beaucoup plus d'endroits ont une telle échelle qu'ils ne peuvent pas reproduire leur environnement de production en raison des coûts. Et en particulier avec la croissance explosive des microservices, il devient difficile de maintenir suffisamment synchronisés les environnements à évolution rapide pour garantir que les tests dans un environnement QA reproduisent les choses avec précision pour détecter les bogues qui pourraient apparaître en production.
Pourquoi devrions-nous avoir des environnements de développement, de test et de production distincts?
- Si vos données de test étaient vues par les utilisateurs, ce serait très mauvais.
- Si voir vos données de prod par des développeurs/testeurs serait très mauvais.
- Si vous ne pouvez pas faire confiance à vos développeurs pour ne pas casser mal les choses et que vous ne pouvez pas résoudre rapidement cette situation.
- Si vous avez automatisé CI en place de sorte que la promotion du code soit rapide et facile.
Essentiellement, si le coût d'avoir les environnements est inférieur au coût de pas d'avoir les environnements.
La raison principale (et la plus apparente) est que vous ne voulez jamais mélanger les données de test et de production. Cela peut devenir incroyablement déroutant très rapidement pour les utilisateurs du système ainsi que pour les développeurs. Lorsque vous gérez l'assurance qualité et les tests unitaires (ce que vous devriez faire), vous devez vous assurer qu'ils se trouvent dans un environnement totalement séparé. Si quelque chose explose dans votre environnement de développement ou dans le contrôle qualité, cela affecterait la production et donc les utilisateurs en direct et leurs données importantes! Vous ne voulez absolument pas que cela affecte la production!
Cela s'étend aux services normaux que vous devez utiliser dans votre travail quotidien, comme votre contrôle de version. Vous ne pouvez pas utiliser correctement le contrôle de version si le code que vous contrôlez est dans un environnement en direct! Vos utilisateurs deviendront fous - et si vous devez revenir en arrière ou revenir en arrière? Et si vous faites une erreur drastique quinze commits profonds? Comment allez-vous gérer les branchements?
À tout le moins, vous devriez séparer votre environnement en plusieurs instances virtuelles, mais vous devez vraiment faire exactement ce que vous avez dit et avoir des instances complètement séparées pour chaque environnement; idéalement développement, QA, mise en scène et production.
Tout cela finit par nuire énormément non seulement à votre application frontale (et donc à votre réputation auprès de vos utilisateurs), mais aussi à l'efficacité de votre équipe.
Le fait de n'avoir qu'une seule instance Oracle disponible ne signifie pas "pas de séparation entre les environnements de développement, de test et de production"!
Vous avez écrit dans un commentaire
Nous utilisons actuellement différents schémas pour différents projets
Ok, donc en consacrant certains projets uniquement au développement, et certains aux tests, vous pouvez séparer vos environnements dans une certaine mesure, en utilisant des schémas différents. Je suppose que vous l'avez déjà fait, car c'est la seule approche sensée que je connaisse lorsqu'aucune séparation d'instance n'est prévue. Je ne peux pas imaginer que votre manager soit si fou qu'il veut que vous mélangiez les données de développement, les données de test et les données client dans un seul schéma de manière arbitraire. Il veut probablement économiser de l'argent en n'achetant pas un deuxième serveur ou en investissant dans la licence pour une deuxième instance.
Par conséquent, la question réelle que vous devez poser est:
Avons-nous besoin d'utiliser différentes instances et/ou serveurs pour séparer les environnements de développement, de test et de production, ou la séparation des schémas est-elle suffisante?
Cela rend la réponse moins claire que dans les autres réponses ici. Différents schémas permettent différents droits d'accès, vous pouvez donc au moins obtenir une certaine isolation à un certain degré à l'intérieur d'une instance Oracle. Cependant, vos développeurs auront très probablement besoin de certains droits administratifs dans "leur" schéma, il sera donc plus difficile de s'assurer qu'ils n'auront pas accès aux données de production si vous utilisez une seule instance.
De plus, une instance/un serveur signifiera également des ressources partagées entre les développeurs, les tests et la production - administration partagée des utilisateurs/schémas, espace disque partagé, CPU partagés, bande passante réseau partagée. Combinez cela avec la "loi des abstractions qui fuient" , et il sera clair que l'utilisation d'une seule instance aura un certain risque d'avoir des effets secondaires indésirables entre l'environnement dev, test et prod.
En fin de compte, vous devez décider par vous-même: pouvez-vous travailler efficacement avec les inconvénients de l'approche? Votre application n'est-elle pas aussi gourmande en ressources et vos données de production ne sont-elles pas si "secrètes" qu'il est tolérable d'avoir un niveau de séparation réduit entre le développement, le test et la production que le niveau que vous obtiendriez à partir de "trois instances/trois serveurs" approche? Si vous ne pouvez pas travailler efficacement de cette façon, ou non sans risque élevé d'interférer avec la production de manière à commencer à perdre des clients, vous avez tous les arguments dont vous avez besoin pour convaincre votre manager d'acheter au moins un deuxième serveur.
Vous avez besoin de plusieurs types d'environnement et peut-être même de plusieurs serveurs dans chaque environnement.
Les développeurs peuvent mettre à jour le code en cours de développement. Le code pourrait même ne pas fonctionner - peut-être que l'application ne démarre même pas.
Cela n'affecte pas QA qui teste la dernière version stable dans son propre environnement.
Comme le développement et le contrôle qualité mettent à jour leurs environnements, la production est basée sur la dernière version publiée il y a six mois et n'est pas affectée par les changements dans d'autres environnements.
Ces modifications déployées dans divers environnements peuvent être du code ou des données. Peut-être que QA doit tester un script de base de données conçu pour corriger certaines mauvaises données en production. Peut-être que le script aggrave le problème - restaurez une sauvegarde de la base de données et réessayez. Si cela arrivait en production, vous pourriez avoir un problème financier très grave.
Que se passe-t-il si vous disposez de plusieurs versions? Vous développez peut-être la version 2.0, mais vous avez toujours besoin de versions de correctifs de bogues sur la branche de maintenance 1.0. Vous avez maintenant besoin de plusieurs environnements de développement et d'assurance qualité pour vous assurer que vous pouvez toujours développer et tester l'une ou l'autre branche lorsqu'un bogue critique est découvert et doit être corrigé hier.
Vous avez déjà remarqué les problèmes provoqués par pas ayant des environnements séparés. Là, vous avez la raison fondamentale pour des environnements séparés: pour éliminer les problèmes causés par les conflits qui surviennent inévitablement lorsque vous essayez de faire des opérations de développement, de test et de production dans un environnement unique. Le même raisonnement s'applique pour donner aux développeurs des bacs à sable individuels dans lesquels travailler, cela empêche les erreurs d'un développeur ou même des changements incompatibles de paralyser toute l'équipe de développement.
C'est également le meilleur argument que vous pouvez faire à la direction pour s'éloigner de l'environnement unique: signaler les problèmes qu'un environnement unique provoque déjà, montrer la ligne de tendance et affirmer que tôt ou tard, si les choses continuent comme elles sont, il y aura un problème qui coûtera beaucoup plus cher à nettoyer (à la fois dans l'effort direct et dans la perte de confiance des clients dans la capacité de votre entreprise à fournir des services) que la reconfiguration des choses pour des environnements séparés coûtera.