Forum Programmation.c++ Comment synchroniser environnement de développement entre machines ?

Posté par  . Licence CC By‑SA.
Étiquettes :
2
2
mar.
2021

Bonjour,

Dans ma boîte, on développe différents logiciels pour de l'embarqué qui sont compilés sur différentes machines (station de travail, environnement d'intégration continue etc).
Entre les bouts de code en C/C++, python, JS, etc, la gestion des librairies commence à se compliquer et comme tout est fait à la main pour synchroniser les environnement de développement, c'est un peu pénible à court terme et je pense très hasardeux à long terme.

On a également plusieurs projets en parallèle, donc le besoin de basculer assez facilement de l'un à l'autre. Actuellement par chance, les dépendances sont à peut-près compatibles mais ça va pas durer.

Jusqu'à présent, on utilise une Machine Virtuelle mais c'est très gros à échanger et pratiquement jamais mis à jour correctement alors j'essaye de migrer ça vers des environnement virtuels et des containers qui pourront être archivés via git etc.

Pour les parties python, je mets en place des environnements virtuels python qui me semblent être la méthode assez classique.

Plus globalement et pour les parties C/C++, je suis parti sur des containers qui contiennent les libs et les compilos/interpréteurs. Les sources sont accessibles par l'intermédiaire d'un volume et j'ai fait quelques bidouilles pour avoir les mêmes UID/GID que l'utilisateur de l'hôte.
Ça marche assez bien pour avoir un environnement pour builder une version "officielle" (un clique et ça sort un package tout chaud) mais je suis moins convaincu pour la phase développement avec ses erreurs de compile, les phases de debug, etc. On utilise Eclipse principalement et quelques outils graphiques.

Je voyais deux options mais aucune ne me satisfait vraiment:
1. Installer Eclipse (et autres outils graphique) côté hôte pour travailler sur le code et lancer uniquement la compilation dans le container. Je trouve ça assez bien car très peut de différences par rapport au monde sans container. Là où ça me semble tordu, c'est que je vais avoir des erreurs de compile qui vont me donner des chemins correspondants au monde du container et pas de l'hôte par exemple.
2. Installer Eclipse côté container. Là, les messages d'erreur pointeront bien sur les fichiers, mais par contre il faudra lancer tous les outils en "export display" ou via une console dans le container, ce qui me semble beaucoup moins transparent à l'utilisation.

Alors voilà (enfin) ma question:
Quelles sont les bonnes pratiques et quelles autres options existent pour "dupliquer" des environnements de développement entre plusieurs machines?

Merci d'avance

  • # La classique

    Posté par  . Évalué à 1 (+1/-2). Dernière modification le 02/03/21 à 11:20.

    Salut,

    Quelque chose ne va pas avec la combo git+jira+jenkins+confluence ?

    • [^] # Re: La classique

      Posté par  . Évalué à 1 (+0/-0).

      Salut,

      C'est ce qu'on utilise. Une doc dans confluence pour décrire comment installer l'environnement dans la VM et les sources dans git, mais c'est très manuel et donc rarement à jour et testé.
      En pratique la VM est rarement à jour et reste lourde à échanger.

      Est-ce que tu as en tête un autre exemple d'utilisation de ce trio?

      • [^] # Re: La classique

        Posté par  . Évalué à 2 (+0/-0).

        Salut,

        Est-ce que tu as en tête un autre exemple d'utilisation de ce trio?

        Désolé, j'ai probablement édité pendant ta rédaction, et c'est devenu un quatuor.

        Et on peut rajouter un petit dernier pour l'orchestration : nexus.

        Bon.

        Jira gère les tâches, git les branches (avec des libs éventuellement différentes), jenkins build tout seul, nexus a les bonnes versions de librairies pour les branches, confluence te permet de faire la doc une fois que c'est en cours de CI.

        Manque peut-être les tests là dedans.

        • [^] # Re: La classique

          Posté par  . Évalué à 1 (+0/-0).

          Alors pour "notre code" c'est déjà plus ou moins ce qu'on fait.
          Mais si tu rajoutes une chaîne de compile un peu spécifique, des outils en plus pour pouvoir lancer les scripts d'automatisation etc … il y a besoin d'installer ces outils.

          Faire un script pour gérer ça, pourquoi pas, mais quand il y a des incompatibilités entre différents projets, ça va se compliquer. C'est pour ça qu'isoler les environnements avec des VM ou des containers me semblaient une bonne option.

          • [^] # Re: La classique

            Posté par  . Évalué à 2 (+0/-0). Dernière modification le 02/03/21 à 12:35.

            Salut,

            J'ai peur de ne pas voir le problème. jenkins+nexus ça compile des branches git avec des environnements différents sans trop de soucis à ma connaissance.

            On peut évidemment rajouter aussi sonar par exemple, pour les tests UI.

            Mais si tu rajoutes une chaîne de compile un peu spécifique

            Du genre ? ;)

            Edit : vu ta réponse plus bas

            • [^] # Re: La classique

              Posté par  . Évalué à 1 (+0/-0).

              Bon moi j'en suis encore à stash(git) + jira + bamboo(jenkins) + confluence dans ma petite caverne =)

              Nexus je connaissais pas. J'ai regardé ça vite fait (https://fr.sonatype.com/nexus/repository-pro - j'espère que c'est le bon nexus, une recherche renvoie une tripoté de truc qui ont rien à voir) et ça m'a l'air d'avoir un intérêt pour du déploiement de container pour de la "grosse" prod.
              De mon côté, on a peut être 10/15 machines à synchroniser, faire un "docker pull" pour avoir le dernier environnement me parait suffisant.

              J'ai peur de ne pas voir le problème
              Mon problème reste qu'en utilisant des containers, le CI, les builds prod c'est pas mal, mais je trouve que pour les phases de développement, ça reste pas pratique de bosser dans un container (faire une compile, du debug etc).
              Dans ce que tu me listes, il me semble que ce problème est toujours là à moins de n'utiliser l'environnement de developpement que pour taper du code et laisser le CI faire le build mais ça me semble pas trop optimal…

              • [^] # Re: La classique

                Posté par  . Évalué à 2 (+0/-0). Dernière modification le 02/03/21 à 17:01.

                Salut,

                Dans ce que tu me listes, il me semble que ce problème est toujours là à moins de n'utiliser l'environnement de developpement que pour taper du code et laisser le CI faire le build mais ça me semble pas trop optimal…

                Peut-être qu'on ne se comprend pas ;)

                J'installe une fois (juste une) l'environnement de dev. Il permet de builder, tester, débuger, en local… bref un "truc" "normal".

                Un fois prêt, ça part en "code review" (et tant mieux si A utilise eclipse et B intellij au passage).

                Ensuite, ça passe à la moulinette automatique pour faire le trajet dev > preprod > prod. Il n'y a plus d'environnement de développement là dedans, et c'est validé à chaque étape. Si ça ne passe pas, retour sur le bureau. Sinon, c'est livré.

                • [^] # Re: La classique

                  Posté par  . Évalué à 1 (+0/-0).

                  Peut-être qu'on ne se comprend pas ;)

                  Ça n'en a pas l'air en effet :)

                  Je vais reprendre un exemple plus concret.

                  Mon environnement de dev c'est en gros:
                  - python 2, python 3, virtualenv
                  - une toolchain gcc avec un sysroot (c'est pour de l'embarqué)
                  - Eclipse
                  - plusieurs librairies
                  - des outils (git, curl, wget, unzip, cpio, zip, sudo etc)
                  - un user avec des droits root via sudo
                  - quelques variables d'environnement bien définies

                  C'est documenté dans un wiki confluence.

                  1. J'installe ça sur ma machine de dev.
                  2. Je fais mon dev, je debugge tout va bien. Je pousse ça sur GIT qui lance un build sur un CI >> Là, il faut déjà avoir un agent de CI avec tout ça configuré, donc il faut au moins avoir un deuxième environnement installé
                  3. Roberte ma voisine, fait une modif. et ajoute une dépendance qu'elle installe chez elle. Elle pousse tout sous GIT et lance un build sur le CI >> Là il faut que l'agent du CI ait été mis à jour
                  4. Si je refais une modif chez moi, pareil il faut mettre à jour l'environnement

                  En mettant la configuration de l'environnement dans un docker, elle peut être poussée sous GIT et récupérée avec le code sur une machine ou un CI. Ça évite les mises à jour manuelle sur chaque machine.

                  Je pense que ça correspond à ton utilisation de jenkins+nexus.

                  Mon problème est était le côté pas pratique de bosser avec un container pour développer (ca résout une bonne partie de mon problème: https://linuxfr.org/nodes/123450/comments/1843266), mais j'ai l'impression que tu n'utilises pas de container pour développer …

                  J'installe une fois (juste une) l'environnement de dev. Il permet de builder, tester, débuger, en local… bref un "truc" "normal".

                  Voilà avec un peu de chance, tu devrais mieux comprendre ce qu'il y a dans ma tête … et m'expliquer ce que j'ai pas compris dans la tienne ;)

                  • [^] # Re: La classique

                    Posté par  . Évalué à 2 (+0/-0).

                    Salut,

                    Peut-être qu'on ne se comprend pas ;)

                    Ça n'en a pas l'air en effet :)

                    Dans le cadre d'utilisation que je présente, tout est modulaire. Il y a libA-v1, libA-v1.1, libB-v2, projetC-v2 qui va utiliser libA-v1 uniquement, projetC-v2.1 qui lui va avoir besoin de libA-v1.1 et libB-v2

                    La CI se charge de mettre à jour libA-v1, libA-v1.1, libB-v2 lorsque modification. Si projetC-v2 a besoin de libA-v1-patch42, à nouveau la CI va rebuilder tout ça. Et mettre les nouvelles versions corrigées sur nexus. Du coup, construire un env de dev dans une VM ou autre, ça me semble un peu surtaillé (attention, je l'ai fait, pour une raison simple : dev avec pour cible windows alors que j'étais sous linux ; ce choix peut totalement se justifier).

                    J'aime bien qu'on me laisse choisir mes outils, si cela est possible, et pas me les imposer de force. ;)

                    • [^] # Re: La classique

                      Posté par  . Évalué à 1 (+0/-0).

                      Salut,

                      Je pense que tu parles de bibliothèque (que tu compiles) alors que je parle d'outils de développement (gcc, python et éventuellement bibliothèques système qui sont sous forme binaire) et d'outils d'édition (Eclipse, DDD etc).

                      Pour les outils/bibliothèques binaires, je me repose sur la distribution pour gérer ça. C'est là où je vois l’intérêt des VM/container.
                      Dans le cas où tout est compilé, effectivement, ça a peu d'intérêt sauf pour du multi-plateforme.

                      • [^] # Re: La classique

                        Posté par  . Évalué à 2 (+0/-0).

                        Salut,

                        Je pense que tu parles de bibliothèque (que tu compiles) alors que je parle d'outils de développement (gcc, python et éventuellement bibliothèques système qui sont sous forme binaire) et d'outils d'édition (Eclipse, DDD etc).

                        Oui, et désolé, je ne vois toujours pas la logique, sauf si tu ne peux vraiment pas mettre deux versions d'outils et que tu as absolument besoin de scinder.

                        C'est probablement là qu'on ne se comprend pas ;)

                        • [^] # Re: La classique

                          Posté par  . Évalué à 1 (+0/-0).

                          Oui, et désolé, je ne vois toujours pas la logique, sauf si tu ne peux vraiment pas mettre deux versions d'outils et que tu as absolument besoin de scinder.

                          Je pense qu'il y a des cas où je pourrais avoir des "dépendances" manquantes suivant l'OS mais c'est vrai que j'ai du mal à trouver un exemple pas trop tiré par les cheveux… :)

                          Je vais resté sur les VM/containers car ça me permet de cloner/réinitialiser un environnement de dev sans interférence avec l'hôte. Ça me "rassure" aussi un peu d'être indépendant de toutes les configurations potentielles du poste hôte.

                          • [^] # Re: La classique

                            Posté par  . Évalué à 2 (+0/-0). Dernière modification le 04/03/21 à 16:10.

                            Salut,

                            mais c'est vrai que j'ai du mal à trouver un exemple pas trop tiré par les cheveux… :)

                            Ah mais si ce n'est que ça, c'est super facile pour se comprendre !

                            Je n'ai jamais eu à le refaire, mais dans un de mes premiers boulots (je radote très certainement), y'avait du VB, codé avec les pieds. Les UAC sont arrivés et ont tout défoncé.

                            Panique à bord, fix vite fait (deux fois, le second améliorant le précédent ; quand on aime on ne compte pas ;) ). Et zou, un an sous la douche environ.

                            Je pouvais partir de presque 0 vu que le VB était à mettre à la poubelle (son rôle n'étant que d'être passe-plat entre bdd et fortran).

                            Là, même si je l'avais déjà la VM mais tirais pour l'avoir moins, la VM m'a servi. D'un côté le visu VB, de l'autre la ré-implémentation avec un objectif : pas perdre les utilisateurs : Les paramètres seront (presque) au même endroit. Par contre ça va prendre du temps….

  • # Ansible + GNU environment modules

    Posté par  . Évalué à 2 (+1/-0). Dernière modification le 02/03/21 à 11:42.

    Pas exactement le même cas d'utilisation que le tien (je ne gère pas vraiment des librairies mais plutôt des outils) mais bon, ça peut aider

    Ansible:
    - pour installer la même version d'un outil sur plusieurs machines à la fois
    - les outils sont installés sous /opt/<nom de l'outil>/<version>
    <version> peut être la version "officielle" (i.e 1.2.3) ou la date + le git hash
    par exemple : /opt/iverilog/2020-07-22-5ebd08c7

    GNU modules

    Pour l'exemple au dessus (iverilog , compilé depuis github, version/hash 5ebd08c7), je vais créer un "module" iverilog/2020-07-22-5ebd08c7 qui definira le chemin de recherche (PATH) et tout autre variable. (j'ai même un script qui crée le fichier "module" depuis le fichier de variable Ansible)

    Pour accéder à cette version, depuis le shell : module load iverilog/2020-07-22-5ebd08c7

    Pour chaque project, dans le répertoire principal, on a un fichier init.sh qui "charge" les différents modules et sélectionne le bon environement virtuel pour Python.

    Comme ca, on maintient une liste d'outil stables tout en permettant à chacun de changer de version d'outils en cas de bug ou de test de nouvelles fonctionnalité

    Marche au poil avec Jenkins…

    • [^] # Re: Ansible + GNU environment modules

      Posté par  . Évalué à 1 (+0/-0).

      Ça parait pas mal, par contre je sais pas si ça va couvrir un de mes cas d'utilisation.

      On a de vielles applis compilées avec un vieux compilo, de vieilles libs dans une vielle distribution avec pas mal de poussière dessus. Pour plusieurs raisons (effort de migration, libs plus dispo dans une nouvelle version, etc), on ne va pas mettre à jour le code pour être compatible avec un système à jour.
      Dans ce cas, je ne suis pas sûr qu'on puisse toujours installer tous les outils nécessaires à un "viel environnement" sur un PC de dev à jour. Comme exemple, j'ai un outil qui veut que /bin/sh pointe sur /bin/bash, des scripts qui attendent un user particulier avec des droits root, …
      C'est un peu pour ça que je cherchais plus du côté des VM/container.

      Mais je connais pas Ansible, il faut que je regarde un peu pour pas dire trop de bêtises.

      • [^] # Re: Ansible + GNU environment modules

        Posté par  . Évalué à 4 (+2/-0). Dernière modification le 02/03/21 à 12:51.

        Mais je connais pas Ansible, il faut que je regarde un peu pour pas dire trop de bêtises.

        Ansible est fait pour configurer et mettre à jour un parc de machines… on peut l'utiliser pour faire autre chose mais ça devient assez rapidement un choix très discutable. Je l'ai utilisé pendant 3 ans et même dans le cas d'utilisation “canonique” je trouve cet outil assez faible pas très convainquant.

        Mes principaux griefs:

        1. Au final on écrit beaucoup de shells scripts quand-même, donc hormis quelques cas d'école très particuliers Ansible n'offre pas de fonctionnalité très intéressante. (Juste le parallélisme sur les machines.)

        2. Tout ce qui est méta-programmation / traitement de données (par exemple calculer les paramètres réseau, ajuster la taille des disques et des caches…) est juste imbitable, intestable, bref c'est sur ce point un très mauvais choix.

      • [^] # Re: Ansible + GNU environment modules

        Posté par  . Évalué à 1 (+0/-0).

        Pour info, Ansible te permet de mettre des conditions sur differents paramêtres comme l'OS, sa version,etc…
        Comme ça, j'arrive à gérer des postes de travails et des serveurs sous Ubuntu (18.04,20.04) et Centos 7 sans trop de difficultée (les difficultées sont principalement due à Centos 7 qui a pas mal d'outils par default qui commencent à viellir).
        Donc une fois l'OS installé sur le materiel (ou la VM), je peux réinstaller tout l'environment d'un dévelopeur via Ansible et les differentes versions d'outils (si elles étaient compatibles avec l'OS) se retrouvent installées.

    • [^] # Re: Ansible + GNU environment modules

      Posté par  . Évalué à 1 (+0/-0). Dernière modification le 08/04/21 à 04:55.

      Me suis fait la même remarque qu'il avait besoin de playbooks Ansible :-)
      …ou juste de dokerfiles (ce type de conteneur pouvant être plus adaptés que des vm)
      …ou encore peut-être regarder du côté de Vagrant ou similaire s'il faut rester en vm.

  • # Ton organisation paraît déjà assez bonne

    Posté par  . Évalué à 3 (+1/-0).

    Il me semble que tu n'as que quelques points à améliorer. Si ceci est ton principal problème avec ta solution à base de containers:

    1. Installer Eclipse (et autres outils graphique) côté hôte pour travailler sur le code et lancer uniquement la compilation dans le container. Je trouve ça assez bien car très peut de différences par rapport au monde sans container. Là où ça me semble tordu, c'est que je vais avoir des erreurs de compile qui vont me donner des chemins correspondants au monde du container et pas de l'hôte par exemple.

    tu vas être content. Tu peux très facilement exposer ton code sous le chemin dans le conteneur. Par exemple avec docker, tu peux essayer

    docker run -it --rm -v "$(pwd):$(pwd)" debian:stretch su -
    

    pour voir que ton dossier courant est visible avec le même chemin dans le conteneur.

    Après il me semble que si votre solution à base de machine virtuelles marche bien à ceci près que:

    Jusqu'à présent, on utilise une Machine Virtuelle mais c'est très gros à échanger et pratiquement jamais mis à jour correctement alors j'essaye de migrer ça vers des environnement virtuels et des containers qui pourront être archivés via git etc.

    tout ce qu'il manque pour vivre au paradis est de construire une chaîne de livraison continue qui produit une machine virtuelle à jour à intervalles réguliers. Même si elle fait dans les 10 Go, cela ne prend normalement que quelques minutes à télécharger.

    (Il me semble que Vagrant sait faire cela mais on peut s'en tirer avec quelques scripts shells et la CLI de VirtualBox, si c'est VirtualBox que vous utilisez. En plus c'est possible d'utiliser ces machines comme agents Jenkins!)

    • [^] # Re: Ton organisation paraît déjà assez bonne

      Posté par  . Évalué à 1 (+0/-0).

      docker run -it --rm -v "(pwd):(pwd)" debian:stretch su -

      C'est vrai que monter le volume au même emplacement pourrait résoudre le problème des chemins différents. C'est tout con, j'y avais pas pensé …

      tout ce qu'il manque pour vivre au paradis est de construire une chaîne de livraison continue qui produit une machine virtuelle à jour à intervalles réguliers. Même si elle fait dans les 10 Go, cela ne prend normalement que quelques minutes à télécharger.

      J'avais testé un peu Vagrant il y a qq années, ça pourrait être une solution pour avoir une VM un peu plus standardisée. Mais si les containers conviennent à tout le monde, ça peut peut-être suffire.

      Après il y a des devs OS et des devs applis qui n'ont pas forcement les mêmes besoins de performances. Une VM pour certain(e)s et un container pour d'autre ça peut aussi être une solution, mais ça fera un peu double maintenance à moins d'avoir un autre truc au dessus qui génère automatiquement VM et container à partir d'une config (ansible par exemple: https://linuxfr.org/nodes/123450/comments/1843259)

      • [^] # Re: Ton organisation paraît déjà assez bonne

        Posté par  . Évalué à 3 (+1/-0).

        C'est vrai que monter le volume au même emplacement pourrait résoudre le problème des chemins différents. C'est tout con, j'y avais pas pensé …

        Ce n'est pas sans piège toutefois, au niveau des permissions. Rien qui soit en principe gênant pour une compilation cependant. (Par exemple pour une clef ssh qui doit avoir une permission au plus -rw------- pour être utilisée par le client SSH va demander plus de travail pour être utilisable.)

        et un container pour d'autre ça peut aussi être une solution, mais ça fera un peu double maintenance à moins d'avoir un autre truc au dessus qui génère automatiquement

        Oui ici il y a deux approches je pense: soit on fait un joli paquet qui tire toutes les dépendances nécessaires quand on l'installe soit on s'en tire avec un simple shell-script.

        Aujourd'hui un shell-script est souvent une meilleure solution que ce qu'on peut croire a priori pour configurer une machine. La raison et que, dans beaucoup de cas, le gestionnaire de paquets n'est qu'un moyen parmi d'autres d'installer des logiciels sur une machine. (Source: ouvrir une dizaine de Dockerfiles de projets libres pour faire ce constat.) Outre le gestionnaire de paquets canonique du système on a tous les gestionnaires relatifs à un langage – type npm, pip, gem, opam, quicklisp, maven, … et même la bonne vieille tarball. Avec des pratiques de type “serveur constant” la possibilité de faire une mise à jour proprement est beaucoup moins importante – en général on repart de zéro au lieu de mettre à jour l'existant.

        C'est possible de faire un script qu'on copie puis exécute dans le container ou dans la vm avec vagrant ou un outillage ad-hoc. Utiliser ansible n'a ici pas grand intérêt: pour les conteneurs c'est plutôt contre nature et il va falloir se lancer dans des contorsions peu intéressantes pour effectivement utiliser ansible pour créer une image docker, et ce script ansible ne va probablement utiliser 4 modules ansibles pour installer des paquets puis appeler une dizaine de shell-scripts pour faire tout le reste… autant utiliser directement un shell-script et éliminer toute une séries de dépendances. (On a ordinairement déjà assez de risques pour casser un “build” sans s'offrir le luxe de dépendances peu utiles! :-) )

  • # un mix des solutions plus haut

    Posté par  . Évalué à 3 (+1/-0).

    -> ansible et ses playbooks, tu peux lui demander de creer un environnement, un conteneur, une VM avec certains prerequis interne

    tu héberges les playbook (fichier de config) sur git,
    le développeur clone les playbook et lance son fichier de config

    et hop, il a la VM avec les outils qui vont bien dedans

    • [^] # Re: un mix des solutions plus haut

      Posté par  . Évalué à 2 (+1/-0).

      Ça va faire un bel empilage :)
      J'aime bien l'idée, mais après ça fait pas mal d'outil à gérer et à maintenir.

      bamboo/jenkins
      |_ ansible
      |__ vagrant
      |___ VirtualBox / KVM
      |__ docker

      Faut trouver le bon équilibre !

  • # Docker ?

    Posté par  . Évalué à 2 (+0/-0). Dernière modification le 02/03/21 à 15:27.

    Pour un peu le même besoin dans la mienne j'ai créé un docker qui propose la cross compilation ARM de notre produit.

    Elle embarque un script qui est capable de cloner le repo git, compiler, et préparer un réprtoire output/ avec tout dedans bien rangé. Utilisable manuellement par les devs ou en CI.

    EDIT : j'ai peut-être lu ton post un peu trop rapidement, toi tu parles d'embarquer Eclipse par exemple. Du coup il va te falloir plus qu'un Docker je pense.

    En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

    • [^] # Re: Docker ?

      Posté par  . Évalué à 1 (+0/-0).

      Oui c'est à peu prêt le même besoin de mon côté et c'est aussi ce que j'ai dans mon "proto" actuel.

      Par contre, on n'est pas trop "container aware" chez nous, donc j'ai un peu peur que ça perdre un peu du monde.

      De ton côté, comment se passe l'utilisation par les devs?
      Les devs sont plutôt à l'aise avec et ils se débrouillent pour configurer leur environnements de dev etc ?
      C'est prémaché avec un script qui lance automatiquement le container de manière transparente?

      … toi tu parles d'embarquer Eclipse par exemple. Du coup il va te falloir plus qu'un Docker je pense.

      C'est quoi qui est plus fort qu'un docker?

      • [^] # Re: Docker ?

        Posté par  . Évalué à 2 (+0/-0). Dernière modification le 02/03/21 à 19:24.

        C'est prémaché avec un script qui lance automatiquement le container de manière transparente?

        C'est ce que j'ai fait. En tête il y a un Makefile, tout simplement (j'aime les Makefile). De la construction du docker à l'utilisation, c'est juste des commandes make.

        C'est quoi qui est plus fort qu'un docker?

        En fait j'ai jamais utilisé Docker pour des applications graphiques, je ne sais même pas si c'est possible. Du coup je pensais à la virtualisation.

        En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

        • [^] # Re: Docker ?

          Posté par  . Évalué à 1 (+0/-0).

          C'est vrai que c'est chouette les Makefile :) J'avais un script pour l'instant mais je vais le basculer en Makefile.

          En fait j'ai jamais utilisé Docker pour des applications graphiques, je ne sais même pas si c'est possible. Du coup je pensais à la virtualisation

          Si c'est possible mais il faut avoir toute la couche graphique donc ça alourdit forcement un peu l'image. Après un export display et c'est bon. J'imagine qu'un VNC ou un NX doivent marcher aussi.

  • # Vagrant a été conçu pour régler ce problème

    Posté par  . Évalué à 2 (+1/-0). Dernière modification le 02/03/21 à 21:09.

    (Edit: zut j'avais pas vu que c'est déjà mentionné dans les réponses, désolé !)

    Est-ce vous avez essayé Vagrant ?

    C'est certes basé sur des machines virtuelles, mais ça normalise et automatise leur fabrication.

  • # Développement distant

    Posté par  . Évalué à 1 (+0/-0).

    Pour du code c++, j'utilise CLion (qui n'est pas libre) et dont le mode distant reste pas top (il y a une synchronisation +/- efficace et automatique) et je ne sais pas ce que ça vaut dans le cas où client et serveur ne sont pas homogènes (comprendre x86_64).

    Il y a aussi vscode qui propose un mode distant plus propre: tout se passe sur le serveur. Mais le support du C++ n'était pas top dans mon souvenir, et il faudra peut-être passer par un plug-in payant et pas libre de JetBrains pour avoir un truc acceptable…

    Dans la même veine, eclipse che. (Je n'avais pas réussi à installer…)

    Sinon, bravo pour ton travail jusque là, ça va porter ses fruits, c'est sûr!

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n’en sommes pas responsables.