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.
Répondre avec citation
Envoyé par esperanto
Partager