IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

  1. #1
    Membre chevronné
    Inscrit en
    janvier 2006
    Messages
    562
    Détails du profil
    Informations forums :
    Inscription : janvier 2006
    Messages : 562
    Points : 1 890
    Points
    1 890
    Par défaut Développer un client sans avoir accès au serveur!
    Bonjour à tous

    Je travaille depuis dix ans dans une grosse institution. A force de laisser les différentes équipes chargées de la sécurité éditer sans cesse plus de nouvelles règles sans jamais se soucier de savoir si elles ne sont pas en contradiction avec celles de l'équipe voisine, je suis sur le point d'aboutir à une situation absurde dont le titre de ce post constitue un résumé même pas exagéré.
    Vu que mes discussions avec le client semblent virer au dialogue de sourds, j'envisage de jeter l'éponge mais comme j'apprécie ce que je fais (mais pas les conditions!) j'ai une question fondamentale avant: ce client est-il un cas isolé? ou assiste-t-on, avec la mode du cloud, à un délire généralisé?
    Avant que vous ne répondiez sur base de la version courte, je vais quand même détailler un peu.

    J'ai déjà travaillé chez d'autres clients, et à cette époque, on n'avait pas accès à la production, ce qui ne me choque pas. Par contre, dans ce cas, chaque serveur de production avait une réplique en développement avec des données de test mais pour le reste, assez fidèle à la production.
    Chez mon client actuel, les répliques de développement existent. Sauf qu'il n'y a qu'un seul réseau, un seul domaine Windows, et on a beau avoir chacun un compte sur le domaine, les droits sont les mêmes pour tout le monde. Résultat: en voulant légitimement isoler les développeurs de la production, ils ont isolé ceux qui font du développement client... des serveurs de développement, qui ne peuvent plus être utilisés que par ceux qui développent spécifiquement ces applications serveur!!!
    Sur les serveurs les droits ont toujours été limités, en gros, à déployer une application. Mais comme on faisait ce qu'on voulait sur les PC locaux, la plupart des développeurs serveur travaillaient avec Eclipse+Tomcat, et ne déployaient sur le serveur de développement qu'à partir du moment où il fallait faire interagir l'application avec une autre. Côté client on avait du Java mais aussi du C# et parfois du C++
    Ensuite ils ont bloqué tout fichier EXE ou JAR qui n'était pas sur les répertoires standard (program files, et quelques autres) sans donner les droits sur ces répertoires. Cela excluait de fait tout ce qu'on compilait nous-mêmes, puisqu'on ne pouvait plus le copier au bon endroit. Mais ceux qui développaient côté serveur pouvaient toujours générer un war et le déployer sur leur serveur respectif (au risque de perturber le développeur qui s'interfaçait avec eux, mais tant pis)

    Et maintenant l'étape suivante : plus aucun environnement de développement directement sur le PC local !!!
    Au lieu de qui ils louent pour nous des PC virtuels sur une plateforme cloud, impérativement sous Windows, et totalement isolées les unes des autres. Faute de pouvoir y installer quoi que ce soit, je ne peux rien faire du PC local sauf lire mes mails, écrire du word ou ... me connecter à cette machine cloud!
    Ceux qui développaient en Eclipse + Tomcat ont encore tenté de le faire sur la machine cloud, mais comme elles n'ont pas accès aux bases de données, y compris celles de développement, ils sont obligés pour tous leurs tests de faire transiter le WAR via ftp vers le pc local avant de déposer sur le serveur (deux transferts donc). Mais au moins les serveurs peuvent continuer à communiquer entre eux.
    Par contre pour les couillons comme moi qui travaillent côté client c'est pire, parce que je n'ai même plus d'endroit pour installer l'application si je dois tester l'interaction avec la partie serveur!

    En fait le seul outil de développement encore toléré c'est Postman, pour lancer et analyser des requêtes http. C'est comme ça que je suis supposé apprendre le protocole des applications, en utilisant les serveurs de développement (et évidemment il ne leur est pas venu à l'esprit de limiter l'accès aux serveurs de dev ), ensuite développer un serveur bidon qui émule ce que j'ai appris via Postman, et après seulement je peux développer mon client en pointant sur ce serveur temporaire. Évidemment ils ne me donneront pas plus de temps pour compenser celui que je perds à écrire le serveur bidon, et si on découvre au moment de la mise en test que ça ne marche pas, ce sera de ma faute. Opération de mise en test qui sera impérativement effectuée par l'équipe sécurité, seule habilitée à installer quoi que ce soit en interne, et qui râle dès qu'on demande plus de deux fois la même opération dans le mois, parce qu'on s'est rendu compte pendant les tests qu'on avait oublié quelque chose...
    Compte tenu de leurs dépendances, notamment à des bases de données, installer sur chaque PC une réplique de chacun des serveurs est inenvisageable. Certains développeurs d'applications serveur ont été assez sympas pour développer une réplique renvoyant toujours les mêmes données et facile à installer en local. Mais la plupart n'en ont pas le temps, sans même parler du risque que ce service ne soit plus à jour. Et je ne parle même pas des serveurs auxquels je dois accéder et qui n'ont pas été développés en interne, juste achetés et installés (et dont la doc de l'API n'est disponible que via des requêtes sur le même serveur!)...
    J'essaie aussi de comprendre comment je dois travailler quand le serveur fait une opération asynchrone: jusqu'à présent mon application regarder dans un répertoire où le fichier qui mettait du temps à être généré finissait par arriver. Mais maintenant plus question d'accéder à un répertoire commun avec d'autres applications! Maintenant le client voudrait que je développe des scripts qui scrutent le répertoire et déposent une copie des fichiers sur un ftp auquel les machines cloud ont accès. Mais ils n'ont pas encore été capables de me dire sur quelle machine il sera matériellement possible d'installer les scripts en question!

    Donc les questions que je voudrais poser:
    • technique: est-ce que certains d'entre vous sont déjà obligés de travailler comme ça? Avez-vous connu un tel changement de façon radicale, ou plus progressive? Avez-vous sérieusement réussi à mener à bien un développement de cette manière, même avec très peu voire pas d'interaction avec le développeur du serveur (notamment si c'est un éditeur qui n'a pas l'obligation de vous aider au delà de l'installation)?
    • non technique: cette situation est-elle un cas isolé? un cas fréquent auquel j'aurais miraculeusement échappé jusque là? ou une évolution récente vers laquelle tous les clients veulent tendre?


    Merci d'avance si vous avez des témoignages à apporter.

    PS. J'ai hésité sur la rubrique pour poser la question, donc si les modérateurs veulent la déplacer, ça ne me pose pas de problème mais merci de prévenir.

  2. #2
    Expert éminent Avatar de 7gyY9w1ZY6ySRgPeaefZ
    Homme Profil pro
    dba
    Inscrit en
    juillet 2007
    Messages
    5 190
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Canada

    Informations professionnelles :
    Activité : dba

    Informations forums :
    Inscription : juillet 2007
    Messages : 5 190
    Points : 7 375
    Points
    7 375
    Par défaut
    J'ai été dba dans une boîte où je recevais des tickets de problèmes de prod... sans avoir accès à la prod ! Le CEO n'était vraisemblablement pas assez occupé et se gardait l'accès exclusif sur les instances de prod dans ses temps morts...
    J'ai vocalisé un peu trop fort mon « ressenti » et je me suis fais remercié peu de temps après.
    Meilleur move de ma vie ! Merci mon ex-boss

  3. #3
    Membre expert
    Profil pro
    Site Reliability Engineer
    Inscrit en
    juillet 2006
    Messages
    908
    Détails du profil
    Informations personnelles :
    Localisation : Royaume-Uni

    Informations professionnelles :
    Activité : Site Reliability Engineer

    Informations forums :
    Inscription : juillet 2006
    Messages : 908
    Points : 3 484
    Points
    3 484
    Par défaut
    C'est relativement courant.

    Si vous avez travaille en banque, en defense, en gouvernemental, ou generalement en tres large entreprises. Il y a toujours des contraintes d'access.
    Parfois les contraintes sont trop fortes et on ne peut pas travailler.

    Je pense que ca va devenir de pire en pire dans la prochaine décennie.
    Le buzzword du moment dans la sphere anglo saxonne c'est la cybersecurite. La premiere etape des nouveaux venus c'est de limiter/bloquer tous les accès, sans se poser trop de questions quant a l'impact sur la productivite.
    La France suit les tendances (avec quelques annees de retard). Ca m'etonnerait pas que ton entreprise ait lance une initiative la dessus.

    C'est le cycle naturel. C'est tres visible et previsible en interne.

    Les ancients projets sont entraves par des règles et contraintes. Ils peuvent facilement se retrouver gelés et impossible a maintenir, parce que c'est devenu impossible de travailler dessus.
    Les nouvelles initiatives ignorent toutes les regles (ils gerent eux meme leurs serveurs, avec leur propre compte AWS). Du coup ca avance au trot.
    Au bout d'un moment, le nouveau projet deviendra gros, et il y a un directeur/audit qui va mettre son nez dedans et se rendre compte que les regles ne sont pas suivies. Et le projet sera force a revenir vers le droit chemin. Jusqu'a ce que les regles s'accumulent et rebelotte.

    En tant que developpeur. C'est important de savoir ou l'on est dans le cycle pour assurer sa propre survie. Commencer a prevoir un autre projet/client/poste quand on sent qu'on va etre bloque de maniere permanente.

Discussions similaires

  1. Réponses: 10
    Dernier message: 14/04/2016, 11h02
  2. [Toutes versions] Utiliser un ODBC custom sans avoir accès au registre
    Par Paul34000 dans le forum VBA Project
    Réponses: 0
    Dernier message: 04/09/2014, 20h46
  3. Ajouter les DLLs de JOGL sans avoir accès au dossier du JRE
    Par Taurëndil dans le forum Eclipse Java
    Réponses: 11
    Dernier message: 31/01/2007, 13h57
  4. Réponses: 9
    Dernier message: 13/09/2006, 14h19

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo