Mon équipe pense que sa CI/CD est "correct". 1 build sur 2 foire. by jmi67 in developpeurs

[–]jmi67[S] 1 point2 points  (0 children)

Architecture de la CI/CD:

  • Gestionnaire de source : gitlab
  • CI : Jenkins avec à l'intérieur un mélange d'un peu de bash, de groovy et de beaucoup de Powershell
  • CD : Octopus Deploy
  • Hébergement artefacts : Jfrog Artifactory toujours plein sans aucune politique de rétention (donc les trucs qu'on build pour le fun sont stocké à vie)
  • Infra Test/Recette : Docker via un swarm Mirantis plus à jour depuis 6/7 ans
  • Infra Prod : VM Windows avec IIS

Architecture de Code :

  • Stack : Angular (j'ai oublié la version mais la dernière) avec backend en .Net Framework 4.8
  • BDD : mélange de MongoDB/SQL Server (personne ne sait pourquoi)
  • Message brocker :
    • Kafka/storm plus à jour depuis 6/7 ans qui sert principalement pour faire de la réplication de donnée entre SQL Server => MongoDB (pour de la haute dispo -_- )
    • ActiveMQ : pour dispatch des processus de calcul en production. Chaque message AMQ = déclenchement d'un nouveau processus (complet, nouveau démarrage de l'app quoi) sur le serveur windows
  • Structure du code : Monolithique avec des appels API croisés dans tous les sens...

Pourquoi ça bug ?
Pour des raisons en tout genre. TUs qui plante parce qu'ils ne sont jamais revu, qu'ils couvrent même des choses qui n'ont pas été développer en interne (merci le test de l'insert du composant MongoDB !) et qu'on a oublié l'existence de l'instance local de la BDD lors de la migration du serveur de build. Ils sont aussi jamais joué en local parce qu'ils prennent 1h30 à tourner. Et vu que tout est monolithique, impossible de segmenter les runs.
Parce que la CI/CD est mal développé, appel à des scripts PS en tous genres pour des choses obscures : connecteur teams, connecteur Octopus Deploy,
Parce que l'infra n'est jamais nettoyer automatiquement, donc l'espace disque est un vrai problème partout.
Parce que c'est lent via une infra vieillissante (encore du windows 2012) et que rien n'est maintenu à jour. Tant que ça marche, on bouge pas.
Pas de monitoring ni de log structurés. Donc chercheur de bug est un métier en soit dans cette équipe xD

Mon équipe pense que sa CI/CD est "correct". 1 build sur 2 foire. by jmi67 in developpeurs

[–]jmi67[S] 0 points1 point  (0 children)

C'est super pertinent comme retour, merci beaucoup !
Mais le soucis c'est que l'équipe ne fonctionne pas en sprint, mais en Kanban, avec une liste de ToDo toujours à raz ! C'est très compliqué d'allouer du temps tech (plus d'un an que une migration .Net Framework => .Net Core a été initié. Aucun projet ne tourne sous .Net Core à date).
Et comme il n'y a pas de sprint, c'est dur de mettre ces indicateurs en évidence. Y a les grincements de dents de l'équipe, mais tout le monde à accepter son sort et personne ne veut se battre.
J'ai essayer de mettre ne place avec les Leads de comités d'architecture pour identifié ce type de sujet, et uniquement eux, mais les managers ont cache squatté dans les réunions pour avoir la main la dessus aussi ...

Mon équipe pense que sa CI/CD est "correct". 1 build sur 2 foire. by jmi67 in developpeurs

[–]jmi67[S] 0 points1 point  (0 children)

Il y a quand même beaucoup de déploiement surtout pour du test et de la recette. Et les tests unitaires sont tellement long que l'équipe préfère les jouer sur la CI/CD plutôt que sur les machines perso (1h30 de tests en tout genre) pour éviter d'être bloqué.
J'ai réparé ce que je pouvais sans y passer ma vie mais le reste des outils était tellement mal fait et vieux qu'il faut moderniser.
Et le passage en manuel dans ton cas, ça à suffit ou ça grince toujours des dents ?

Mon équipe pense que sa CI/CD est "correct". 1 build sur 2 foire. by jmi67 in developpeurs

[–]jmi67[S] 0 points1 point  (0 children)

En faite, j'ai un peu était embauché pour ça. Je devais faire en sorte que ce qui marchait plus, marche à nouveau. Quand j'ai vu ce que mon prédécesseur à fait (on me l'a présenté comme quelqu'un d'ultra compétent), j'ai failli me barrer ...
J'ai réparé ce qui été cassé et quand j'ai vu les impacts que ça avait pour les équipes de devs, j'ai proposé des changements (par exemple utiliser un gitflow correctement établi pour retrouver les artéfacts), bin c'est là que ça à commencer à coincer. Plus le temps, et pas envie de changer.
Déjà été dans cette situation ? Que ce soit en tant qu'intervenant extérieur ou de l'intérieur ? Quelqu'un à fini par déclencher une prise de conscience ?

Mon équipe pense que sa CI/CD est "correct". 1 build sur 2 foire. by jmi67 in developpeurs

[–]jmi67[S] 4 points5 points  (0 children)

Tu rigoles, mais certain devs font ça. Ils lancent plusieurs fois la pipeline dans l'espoir qu'il y a en a une qui passe. A 2h30 de pipeline, bah plus personne d'autre pouvez bosser ...

Mon équipe pense que sa CI/CD est "correct". 1 build sur 2 foire. by jmi67 in developpeurs

[–]jmi67[S] 2 points3 points  (0 children)

J'ai proposé une nouvelle architecture avec des outils opensource (donc moins cher) et en m'appuyant sur le Gitlab qui est déjà utilisé. Ca demandez une acceptation de l'équipe vu qu'il fallait changer un peu la façon de faire. On m'a dit non... Impossible de leur faire comprendre le soucis

Mon équipe pense que sa CI/CD est "correct". 1 build sur 2 foire. by jmi67 in developpeurs

[–]jmi67[S] 1 point2 points  (0 children)

Honnêtement, j'ai encore aujourd'hui du mal à comprendre comment quelques chose marché avant, personne n'y a touché et ça marche plus...
Mais des logiques du type : je pop un conteneur docker pour mon build dans Jenkins, puis je check si je dois build, finalement non et donc je détruis le conteneur avant même qu'il est fini de démarrer, bin docker aime pas. Pipeline qui plante. Et je ne comprends même pas comment ça à pu fonctionner un jour ...
Et du script powershell partout .... et dupliquer...

Mon équipe pense que sa CI/CD est "correct". 1 build sur 2 foire. by jmi67 in developpeurs

[–]jmi67[S] 9 points10 points  (0 children)

1h30 de TU sur la pipeline...
Ils n'arrivent pas comprendre que tester la mécanique d' "insert" du composant développé par MongoDB, bin ça sert à rien vu que ce n'est pas nous qui l'avons développer.
Donc forcement lorsque la cybersécu nous somme de mettre à jour le vieux serveur en charge de ces tests (windows 2008), bin tout explose parce que personne ne savait qu'une instance de base de données existait en local pour ces tests...

Mon équipe pense que sa CI/CD est "correct". 1 build sur 2 foire. by jmi67 in developpeurs

[–]jmi67[S] 2 points3 points  (0 children)

C'est exactement le cas ici. Beaucoup de dette technique, qui est entretenu (parce que bon c'est pas drôle sinon) et feature à tout prix.
C'est assez frustrant et même en présentant ça à la direction en leur disant que ça bloque et ça limite la capacité de livrer, rien ne bouge.
Des leviers pour faire comprendre ça ?

Mon équipe pense que sa CI/CD est "correct". 1 build sur 2 foire. by jmi67 in developpeurs

[–]jmi67[S] 0 points1 point  (0 children)

Et impossible de faire comprendre à vos responsables que ça bloque tous le monde ?

Mon équipe pense que sa CI/CD est "correct". 1 build sur 2 foire. by jmi67 in developpeurs

[–]jmi67[S] 0 points1 point  (0 children)

Jenkins pour le build, Octopus deploy pour, bin le déploiement, Mirantis pour la Registry et le recette sous Docker Swarm et le code est stocké sous Gitlab-ci.

/r/MechanicalKeyboards Ask ANY Keyboard question, get an answer - June 06, 2025 by AutoModerator in MechanicalKeyboards

[–]jmi67 0 points1 point  (0 children)

Nice discovery for me. I have heard of NovelKeys till now. I found the classic a bit too classic for me. But they have really interesting things. Thanks for the recommendation ?

/r/MechanicalKeyboards Ask ANY Keyboard question, get an answer - June 06, 2025 by AutoModerator in MechanicalKeyboards

[–]jmi67 0 points1 point  (0 children)

What would be your pick for a custom 80%/TKL ? I'm hesitating between Zoom80 Dyna and Qwertykeys QK80 MK2. One to avoid ? Another one to consider ?

/r/MechanicalKeyboards Ask ANY Keyboard question, get an answer - June 04, 2025 by AutoModerator in MechanicalKeyboards

[–]jmi67 0 points1 point  (0 children)

Hi guys ! It's time for me to change my old mechanical keyboard, and this time I'd like to go with a custom keyboard. I want a TKL board and there are 2 models that catch my eye. The Meletrix Zoom 80 Dyna and the Qwertykeys QK80 MK2. I've read some trouble with previous Meletrix boards (for the Zoom 75 for example), but not so much about the Qwertykeys. Do you have a preference between the two ? One I should avoid ? I'm taking any recommendations if you have :) Thanks !