Discussion :

[ReptilPt]

Bonjour à tous. Je suis dans une situation un peu..inconfortable. Pour explique je viens de commencer un nouveau job, dans une entreprise assez petite –qui n'est pas d'informatique – mais qui a une équipe d'informatique. Cela après 3 ans comme développeur chez Oracle et un total de quasiment 7 ans d'expérience. Et j'ai rejoint en tant que "Web TeamLead" pour en projet en MERN, donc pour être le chef d'équipe. Le problème c'est que les membres actuels de l'équipe ne sont pas très contents de ma venue et ne me facilite pas du tout les choses. Après quasiment 4 semaines je n'ai même pas encore eu de passage de connaissance ou similaire.

Et donc j'ai des doutes que personne ici essaie de m'aider à comprendre. Actuellement je sais que le projet –en dev- est sur un serveur EC2 de Amazon. Et que pour "déployer" le code en production ils utilisent un script dans le même serveur. Donc c'est déjà mon premier doute. Est-ce normal d'avoir le serveur de test, être aussi le serveur de Prod?
Je viens d'un monde où on a toujours un serveur Dev, un UAT e finalement un serveur Prod. Et c'est normal que le dossier dev du Project a son propre domaine, ce qui veut dire que il est accessible par n'importe qui sur le web??

Et si par exemple, maintenant que je vais prendre contrôle de l'équipe, si je veux instaurer le système de 3 serveurs séparés pour faciliter le travail en parallèle mais aussi la qualité du code envoyer en prod, cela veut dire que les URLs pour la version UAT et DEV seront accessible para n'importe qui sur internet?

Et ma dernière question c'est que on a notre "portail"/site principal, mais on veut avoir un système CMS, pour permettre à nos équipes de remplir le "content" eux même. Et même dans le futur, nos clients. Mais on veut se portail CMS séparé du principal. Du moins niveau points d'accès. On ne veut pas permettre d'y accéder à partir du portail principal. Comment on peut faire ça niveau serveur, sachant qu'ils utiliseront la même DB (NoSQL).

Je viens d'un monde ou tout cela était "invisible" pour moi. A l'entretien j'avais été sincère disant que j'étais surtout un développeur et je n'avais aucune expérience avec les serveurs et déploiement outre JEnkins/Hudson. Ils avaient dit que j'aurais l'espace pour apprendre, mais vu la reception, j'essaie d'apprendre le plus possible tout seul. Donc je vous remercie pour toute aide que vous pouvez me donner.

[Marco46]

Si je résume tu as deux problématiques, la première c'est de prendre la fonction de team lead dans une équipe existante qui ne veut pas de toi, la deuxième c'est la mise en place d'une usine logicielle.

Je vais donc déplacer ton post dans la partie Usine Logicielle du forum, et pour ton premier problème tu devrais voir ça avec ton n+1. Si c'est toi le team lead, tu as autorité sur la team. Donc si tu demandes un passage de connaissances ils doivent s'exécuter (planifie au moins une réunion pour qu'ils te présentent l'existant je vois mal comment ils pourraient refuser !) sinon sanction. Il faut que tu vois ça avec ton n+1.

Après quasiment 4 semaines je n'ai même pas encore eu de passage de connaissance ou similaire.

Ça j'ai du mal à comprendre, si c'est toi le lead tu ne dois pas attendre qu'on te passe la connaissance. D'ailleurs ça devrait être à toi de leur donner leurs tâches respectives. Du coup je comprends pas bien ce qu'il se passe depuis 4 semaines, ils sont en roue libre ?

Pour la partie usine, généralement on a au minimum un environnement de test, un environnement de preprod (les anglophones disent "staging") qui doit être en tout point similaire à la prod mais qui n'est pas la prod. Et enfin la prod évidemment.

Chaque environnement doit être isolé à tous les niveaux (matériel, logiciel, ...).

Pour ce qui est des accès vous devriez bien être en mesure de le limiter d'une manière ou d'une autre. Après est-ce que c'est problématique que la terre entière puisse accéder à vos environnements ça ça dépend du produit. A voir avec ta hiérarchie en premier lieu.

Et ma dernière question c'est que on a notre "portail"/site principal, mais on veut avoir un système CMS, pour permettre à nos équipes de remplir le "content" eux même. Et même dans le futur, nos clients. Mais on veut se portail CMS séparé du principal. Du moins niveau points d'accès. On ne veut pas permettre d'y accéder à partir du portail principal. Comment on peut faire ça niveau serveur, sachant qu'ils utiliseront la même DB (NoSQL).

La question de fond relève du système d'authentification de votre système. Quel est-il pour le moment ? Il y a aussi la question de l'architecture générale, le site principal est-il la même appli que le CMS ?

Toute cette partie c'est vraiment de l'architecture pure. En général on utilise un architecte pour faire ça, c'est un métier

Je viens d'un monde ou tout cela était "invisible" pour moi. A l'entretien j'avais été sincère disant que j'étais surtout un développeur et je n'avais aucune expérience avec les serveurs et déploiement outre JEnkins/Hudson. Ils avaient dit que j'aurais l'espace pour apprendre, mais vu la reception, j'essaie d'apprendre le plus possible tout seul.

Donc en résumé tu n'as aucune expérience en DevOps, et on te demande de lead une équipe qui a dans ses responsabilités la partie DevOps en plus du développement pur. Ce que j'ai exposé juste avant c'est vraiment une des bases. As-tu des DevOps dans ton équipe ? Pourrais-tu nous dire quelles sont les compétences de ton équipe membre par membre ?

[ReptilPt]

Déjà je veux te remercier pour ta réponse. Et je vais te répondre en donnant un peu plus de contexte a la situation actuelle.

Donc actuellement l'équipe avait 3 personne avant mon arrivé. Un backend et un frontend, les deux avec 2/3 ans d'experience.Et un Team Leader qui les aidaient mais qui s'occupe aussi de tout le reste niveau informatique dans l'entreprise. Ma venue dans l'entreprise est exactement pour "libérer" cette personne pour qu'il puisse s'occuper du "reste". Parce qu'actuellement c'est trop pour une seule personne. En plus de ça, le backend vient de quitter l'entreprise. Donc l'équipe sera moi, le frontend, et 2 personnes que je recrute actuellement. Un back end et un front end, niveau plutôt proche de senior.

Et quand je parlais de passage de connaissance..Je m'attendais surtout venant du actuel leader. Que ça soit niveau serveur comme j'ai déjà expliqué, le propre code et la Stack (Je sais que la base est en React mais par exemple je vois du Laravel), leurs méthodes de travail, etc etc. Dans les projets que j'ai rejoint dans le passé, on m'a expliqué le contexte actuel. Ici ils m'ont donné les accès au serveur EC2 et débrouille toi. Finalement, pour expliquer ce qu'ils font entretemps, officiellement nous allons faire le passage de "pouvoir"/poste dans une ou deux semaines. La raison c'est que l'entreprise organise des évènements, des grandes conférences. Et on en avait une la semaine dernière aux USA. En plus de ça, le nouveau site (la première version du moins), devait être Live en Prod, le premier jour de cette conférence. Et c'est comme ça qu'ils justifient me laisser dans le banc de touche. Que je suis arrivé trop tard et que ils n'ont pas le temps de me mettre au courant. Mais le n+1 par exemple non seulement leur avaient demandé de me mettre au courant; mais s'attendais a que je puisse les aider, même niveau code.



Je pense que ma réponse répond aussi à tes autres questions. Aucun Dev Ops, aucun architecte. C'est une petite entreprise. Mon équipe de 4, plus l'ancien team leader seront toute l'équipe IT que l'entreprise a. Bien sur que je peux apprendre a m'occuper du Dev Ops. Mais voila..faut apprendre.

Finalement pour l'application. A la base je pensais faire tout dans la même appli, et donner un login spécial dans le site, qui permettrait d'accéder à la partie CMS. Mais on m'a dit qu'ils préféraient que ça soit impossible d'accéder à la partie CMS à partir du site. C'est pour ça que je pense que ou je séparé en 2 applis avec la me BD, ou la même appli mais avec 2 "points d'entrées". Mais voila..je ne suis pas sur de quelle est la meilleure approche vu que c'est la première fois que je me trouve face a un probleme similaire.

Je suis conscient que la description de mon problème peut donner l'impression que j'ai accepté un job au-dessus de mes capacités. J'ai été complètement sincère dans mes entretiens sur mes limitations (Dev Ops par exemple), et sincerement je m'attendais a être reçu d'une autre façon, avec une certaine marge pour évoluer et apprendre. Mais voilà, je pense aussi qu'un défi comme ça aide a grandir professionnellement et c'était mon idée quand j'ai accepté. Même si le principal a la base était de guider l'équipe en soit même, intégrer des méthodologies Agile, etc etc.

[Marco46]

Ok donc pour le problème de passation c'est en fait une contrainte de charge et de calendrier. Il faut juste faire attention à ce que ça ne soit pas repoussé éternellement

Pour le contexte d'entreprise c'est sur qu'une petite entreprise et une petite équipe comme ça c'est beaucoup plus dur parce qu'il faut tout savoir faire mais d'un autre côté ça permet de faire évoluer les choses beaucoup plus vite et ça permet donc de faire des cycles d'essais / erreurs sans se taper une réunionite aiguë avec 20 personnes de 10 services différents pour se rendre compte que t'as oublié le responsable du service bidule dans la boucle qui bloque tout parce qu'il est vexé. Donc c'est toujours pareil, avantages / inconvénients, ya du pour et ya du contre. Pour évoluer rapidement et apprendre en mettant les mains dans le cambouis c'est certainement la meilleure des situations (paradoxalement) mais également la plus coûteuse en temps (tu vas avoir de belles journées ).

Pour ton problème d'architecture je te recommande fortement de faire des petites applis séparées plutôt qu'un gros monstre qui fait tout. C'est plus facile à gérer à tous les niveaux. Ne perd pas de vue que les applis web modernes avec des frameworks / libs comme React, Angular, Vue, etc ... Sont des applications à part entière indépendantes du backend. Donc mécaniquement tu as forcément 2 applis au minimum, un front et un back. Il faut impérativement les traiter comme des applis différentes avec des cycles de vie différents, des dépôts de code différents (je passe sur la stratégie monorepo c'est un peu chaud à gérer au début), des numéros de versions différents etc ... Et le tout sera aggrégé dans chaque environnement pour former la solution.

Pour être plus concret, si ton besoin c'est un front public read-only et un autre privé contenant le CMS il te faut donc 2 applis fronts séparées sur des domaines différents et des serveurs différents. Ce sera alors un jeu d'enfant d'empêcher l'accès au serveur CMS via un filtrage IP ou/et une authentification via certificat clients sur votre CMS. Pour le fait que les clients puissent écrire dans le CMS aussi, si c'est pour plus tard, tu verras ça plus tard, il faut prendre les choses dans l'ordre et éviter de tirer des plans sur la comète.

Pour ce qui est du backend j'ai envie de te dire pareil, tu peux parfaitement avoir 2 backends, un public et un privé qui tapent tous les deux dans la même base de données.

Donc au final tu aurais 4 applis, 2 backends et de 2 frontends. Reste la question de la mutualisation du code commun (surtout entre les 2 backends), il y a plusieurs stratégies, le plus simple quand on démarre ça reste la bonne vieille lib (projet à part, versionnée à part, etc ...).

Je te conseille de rester le plus simple possible et de faire évoluer les choses par itérations courtes en traitant les problèmes les uns après les autres. Je te conseille également d'automatiser au maximum (tooling, tests, build, déploiement, etc ...) même si de prime abord on à l'impression de consommer du temps à autre chose que du développement de feature, assez rapidement on gagne un temps phénoménal.

Je ne sais pas si ça t'aide.

[ReptilPt]

Je te réponds 6 mois en retard, mais oui tu as beaucoup aider avec ta réponse

[Marco46]

Par curiosité comment ça a évolué ? Ca peut peut être servir à d'autres personnes, c'est tout l'intérêt d'un forum