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 cas précis. 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, que les applications deviennent plus complexes et que 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 distincts?

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 chaque cœur du processeur? Voulez-vous que vos tests s'arrêtent parce qu'un développeur a fabriqué une bombe fourche 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 soit exécuté 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 gréement ad hoc des développeurs.
• pour réduire les risques que les données de production tombent entre de mauvaises mains (très important lorsque les organisations traitent des données sensibles, telles que 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 séparés 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 surtout 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 se produiraient 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 ne pas 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 - que faire 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.

Avoir 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 différents schémas. 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 vraie question que vous devez vous 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 un certain isolement dans une certaine mesure à 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 vous assurer qu'ils n'auront pas accès aux données de production si vous n'utilisez qu'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 de développement, de test et de production.

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 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 correction 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 causés par l' absence d' 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: indiquer 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.

Il existe de nombreuses forces et dynamiques opposées. Il y a un coût d'avoir plusieurs serveurs et le coût d'en avoir un seul. Je pense que cette question peut être plus complexe que la simple base de données? Je peux être un malentendu, mais cela se rapporte à un malentendu systémique qui existe sur les coûts des biens tangibles par rapport au résumé

Les coûts évidents sont généralement faciles à comprendre.

Les coûts abstraits sont plus difficiles à quantifier et donc plus difficiles à comprendre. La dette technique, le coût des erreurs, le coût du stress, la charge pesant sur les développeurs, les effets du changement, les tests de régression, l'impact des temps d'arrêt, etc. sont plus difficiles à expliquer.

environnements différents Les environnements sont généralement séparés pour les données et / ou le but. Chaque environnement a une fonction différente. Le taux de changement sur un système, c.-à-d. la fréquence à laquelle il sera mis à jour, le type de changements et les effets du changement, sont tous pris en compte.

Nous utilisons différents environnements pour banaliser le changement.

Nous utilisons différents environnements, nous offrons donc la robustesse et la certitude de l'environnement qui n'a pas changé.

Nous utilisons des environnements pour considérer les effets d'un changement.

Nous utilisons des environnements pour réduire les coûts liés au changement.

tester et stabiliser un système coûte cher. Vous créez des environnements pour sécuriser l'investissement réalisé sur l'environnement stable.

Vous n'êtes jamais une équipe trop petite pour adhérer à des schémas de processus pragmatiques, économiques, diligents et éprouvés.

Utiliser un environnement pour tout, c'est comme stocker toutes vos photos sur un disque dur, vous pouvez le faire, mais vous allez le regretter.

certaines personnes ont besoin d'une preuve que j'ai été dans de nombreuses situations avec des clients ou d'autres qui n'apprécient pas les coûts liés à la robustesse et au respect des meilleures pratiques. Je vous suggère de rassembler quelques exemples de cas réels où les coûts sont clairement définis.