Initialiser le mouvement devops dans une petite PME

Bonjour à tous,

Je me permets de faire appel à la communauté car je travaille dans une petite PME (4 développeurs) en full-télétravail. Un des développeurs est fondateur de la boite, nous avons 2 jeunes développeurs (arrivée au 1er trimestre 2020) pour qui il s’agit du premier emploi dans le secteur et moi pour qui il s’agit également du premier emploi dans le monde du développement mais en poste depuis 3 ans.

Nous commercialisons un logiciel qui est codé en PHP et Javascript. Actuellement nous avons un fonctionnement qui je pense atteint ses limites et nous cherchons une nouvelle organisation qui pourrait tendre vers du CI/CD.

En termes de compétences, personne n’a été initié à ce type d’organisation, ni la conteneurisation, ni même les tests (on part de très loin). Pour l’historique ce projet est né de 3 associés qui ont voulu sortir très (trop) rapidement ce logiciel. Il a donc été créé par mon chef actuel qui est autodidacte et manque de compétences d’organisation (c’est un point qu’il valide). Le projet ayant toujours été tenu à bout de bras par une seul personne, mon arrivée à un peu chamboulé la chose même si à 2 ça marchait encore bien cependant avec l’arrivée des 2 derniers développeurs on se rend compte que ça devient trop brouillon, voir critique en termes de déploiement.

Aujourd’hui nous sommes conscients que ça ne va pas, et que même si c’est compliqué d’allouer du temps on cherche à renforcer notre organisation. Cependant on a du mal à trouver les solutions adaptées à notre structure, qui nous correspondent étant donné le nombre de possibilité. On veut éviter de gros investissements également.

Actuellement nous travaillons en local avec WAMP, avons un serveur preprod en VPS qui possède sa base de données et donne accès au build de notre branche git recette. Il y a également des sous-branches de recettes lors de développement de gros module qui possèdent leur sous-domaine sur le serveur.

Enfin nous avons un serveur de production dans le Cloud, qui lui possède sa base de données, l’application en production, le serveur mail, redmine qui est notre outil de gestion de projet.

Bon beaucoup de blabla pour contextualiser. Il reste cependant à définir nos principaux besoins. Dans un premier temps nous souhaiterions intégrer gitlab sur notre serveur preprod pour dans un premier temps nous permettre de faire de la revue de code et dans un second temps être un outil pour le déploiement continu. Ensuite nous allons commencer à intégrer des tests dans l’implication, d’abord sur les couches bas niveaux, des fonctionnalités clefs de l’application et au fur et à mesure sur les nouveaux développements.

J’espère obtenir quelques conseils de votre en part en tout cas si vous en êtes ici, merci d’avoir pris le temps de me lire.

1 J'aime

Bonjour @DarkBizzu,

Je pense que vos priorités sont les bonnes.

  • Mettre une forge logicielle, Gitlab est très bien. Je vous conseille de la prendre en managed pour ne pas perdre de temps à l’administrer. (je fais un peu de pub pour le chef du forum @cchaudier et “son” service SAS froggit vous êtes typiquement sa cible de client. https://lydra.fr/tag/froggit/)

  • Mettre des tests (unitaires si possible ou black box) sur l’application. Sans tests la CI perd quand même énormément d’intérêt. Cibler les tests sur les parties les plus importantes (métier) ou qui présentent le plus de risque de bug.
    Passer l’appli dans un sonarlint pour avoir une idée rapide de la qualité de code et corriger les trucs critiques si besoin. (A terme ça pourra être aussi dans la CI avec un service SAS).

  • Suivant ou vous en êtes, si le code est vraiment pas bon (archi, modularisation, tests pas facile à ajouter…) envisager une réécriture partielle ou complète plutôt que de faire du sparadrap et du code spaghetti à pleurer, qui vont vous mener vers un truc non maintenable à plus ou moins court terme. (un rex ici: https://ifttd.io/faut-il-etre-a-la-mode-pour-etre-a-la-pointe/)

  • Mettre en place un début de CI, même si il y a peu de tests c’est pas inutile de les tourner systématiquement à chaque Merge Request.

Si vous n’avez pas de compétences sur le sujet, je vous conseille de vous faire accompagner par un consultant indépendant pour aller vite, il pourra vous aider sur la mise en place technique mais aussi organisationnel, parce que les meilleurs outils servent à rien si mal utilisés ou si les personnes ne sont pas formées). Il y en a des bons qui traînent sur ce forum. :wink:

2 J'aime

Merci d’avoir pris le temps de me répondre, vos réponses vont permettre d’alimenter notre réflexion. Juste quelque chose que je n’ai pas expliqué c’est que l’une des contraintes est de ne pas héberger le code de l’application autre part que sur notre serveur. Ce qui du me paraît incompatible avec votre première proposition qui est t’utiliser gitlab ou froggit en managed sauf si je me trompe? En tout cas encore merci pour la réponse

Vous pouvez installer gitlab chez vous on premise. Mais sincèrement, pour vous dégager du temps de maintenance… vaut mieux payer un abonnement et avoir des dépôts privés sur du managé.

2 J'aime

J’éviterai aussi d’installer / gérer GitLab. En tout cas, je ne commencerai pas par là. Il est tout à fait possible d’avoir des repos GitLab ou GitHub ou (:rooster:cocorico / Grenoble Tuleap) privés auxquels vous seuls avez accès. C’est même gratuit (ou pas cher avec Tuleap, je ne sais pas avec froggit).

Les étapes sont possiblement:

  • Mettre le code sous GIT
  • Commencer à utiliser la mécanique des Pull Requests / Merge Requests
  • Adopter une bonne hygiène pour les commits
  • Implémenter un linter php (très simple, cela permettra de créer la base pour une CI)
  • Continuer (création de packages / versions, tests, …)

Maintenir ton instance n’est pas anodin en effet.
Y’a une release par mois, des sauvegardes à gérer, l’administration des utilisateurs et l’admin de certaines fonctionnalités peut demander certaines compétences/ressources (mail, DNS, mise à jour, etc.).

Dans ma précédente boite (3 personnes) j’étais le seul dev avec 2 admins : il m’ont popé un GitLab dans une VM interne (backupé), ça à bien marché… mais ils ne la mettaient pas à jour.

Quand j’ai voulu faire la MàJ au bout de 6 mois, je suis resté bloqué sur une des versions intermédiaire : la suivante échouait.
Au bout d’une journée j’ai arrêté de chercher, faute de vraiment comprendre l’installation…

1 J'aime