ce qui devrait les développeurs ont accès?

Question

Je travaille à un endroit où nous construisons des applications de processus et stocker des données sensibles. nous avons 3 environnements. Dev, UAT / QA (utilisateur de test acceptante) et la production

les développeurs de mon travail n'a pas accès à l'UAT ou la production et ont un accès limité à Dev. Tout ce que nous pouvons faire en dev est connecter à un serveur dev DB. nous n'avons pas accès au serveur de dev lui-même. donc nous arent permis de jouer avec des choses comme le serveur Web (IIS) sur dev. si nous voulons des changements que nous devons faire si un processus formel de soumettre des demandes de travail à nos administrateurs réseau (qui pourrait prend des jours pour terminer). la même chose si un développeur devait demander quelque chose à vérifier dans une base de données UAT ou PrOd. cette restriction d'accès stricte est vraiment frustrant lorsque vous essayez de soutenir nos applications.

Je peux comprendre pourquoi nous avons ces politiques, car il réduit le risque de choses se foiré. mais cela fait des problèmes de résolution vraiment de temps et douloureux. quelque chose qui pourrait prendre 5 minutes pour fixer (si un développeur a accès) pourrait prendre des jours pour résoudre.

est ce genre de droits d'accès stricts normal?

Answer 1

Difficile de dire s'il est normal. Par exemple, j'ai travaillé pour les banques d'investissement où ils ont des procédures encore plus draconiennes que celles que vous décrivez. J'ai aussi travaillé pour un IB qui avait aucune procédure à suivre. Cependant, il est à noter que les premiers sont toujours en activité, alors que ce dernier a fait faillite célèbre tout récemment!

Answer 2

Il est pas un « serveur dev » si les développeurs ont pas accès. Maintenant, il est pas rare d'avoir 4 environnements: production, pré-production, de test et dev. (Triés en augmentant l'accès pour les développeurs). Si j'ignore les noms, il semble que vous avez la même structure, sauf que vous êtes absent le serveur dev.

Answer 3

me semble un peu serré pour. Normallly Je me attends à un contrôle complet sur le serveur Dev, je serais heureux de voir l'accès en lecture seule onthe serveur de test et d'être tout à fait honnête, je ne suis pas intéressé à regarder le serveur de production (d'un point de vue du développement).

Bien sûr, les assumtpions suivantes sont faites ici;

• les 3 environnements a commencé exactement le même
• Les modifications apportées à prod sont montés en cascade retour à dev par test
• Toutes les modifications de configuration dans Dev sont faites par le déployeur pour tester et prod

Dans notre procédure ici, nous ne permettons pas le développeur de déployer à tester -. C'est au testeur avant de reversent à une 3ème partie qui se déploie à aiguillonner

Ceci valide notre procédure de libération autant que toute autre chose.

; aussi longtemps que everythiong est documenté pour la libération, vous ne devriez pas avoir accès à autre chose que Dev, mais il serait agréable d'avoir un niveau de contrôle décent sur l'environnement dev.

Answer 4

Il est une question de ce que vous voulez

Il y a 2 exigences concurrentes au travail:

• Délai d'exécution rapide pour résoudre les problèmes / développement nouveau code.
• Veiller à ce que aucune donnée sensible se fuites.

Votre société a décidé (consciemment ou inconsciemment) qu'il est préférable de réduire le risque de fuites de données sensibles que d'avoir la capacité de résoudre les problèmes et d'élaborer un nouveau code rapidement. Mon entreprise se penche dans la même direction, mais pas vraiment assez clued-up pour prendre les extrêmes que vous décrivez.

Ceci est une décision business .

Il est fait parce que (probablement inconsciemment) votre entreprise met une valeur plus élevée sur le risque de baisse (données fuites) que sur le risque à la hausse (ce qui fonctionne le logiciel). Ceci est un biais commun - il est connu comme étant une aversion au risque (je suis sûr qu'il ya un meilleur terme que - tout le monde), et il est très gênant pour ceux d'entre nous qui, en essayant d'obtenir nos emplois fait, doivent surmonter un tas d'obstacles mis là par des gens qui n'ont pas une bonne compréhension de l'impact de ces obstacles.

Pour Résumer

• Ceci est un business décision.
• Il est une question de la façon dont différents risques sont perçus .
• Il reflète une aversion au risque position .
• Cette position a probablement été arrivé à par la société entièrement inconsciemment .

Answer 5

Il est sur la gestion du changement; en vous assurant toutes les modifications du système sont suivis et d'en faire les notes de version, ainsi qu'un changement dans une partie du système ne pose pas de problème dans une autre partie.

S'il était à moi, je donnerais chaque développeur un PC assez puissant pour exécuter autant de machines virtuelles que nécessaire pour émuler l'environnement de production, avec un contrôle total sur ces machines. Et puis assurez-vous que tous les changements à l'environnement de dev officiel est documenté de telle sorte que des notes de version peuvent être produits.

Answer 6

Même dans une petite entreprise, les ingénieurs ne devraient pas avoir un accès à l'environnement de dev au-delà du code. L'environnement de base devrait rester assez statique. Quels types de choses sur le serveur web voulez-vous changer à un rythme rapide?

Answer 7

Consultez Stackify. Nous venons de publier un nouveau service qui offre aux développeurs une plus grande visibilité à leurs applications et les serveurs de production. Nous pouvons leur donner simplement un accès en lecture seule à des choses comme les fichiers journaux, les fichiers de configuration, Windows Observateur d'événements, etc. Nous pouvons résoudre le problème que vous décrivez. Nous avons essentiellement inventé le soutien DevOps: http://www.stackify.com