IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

L'équipe d'ingénierie de GitHub migre vers Codespaces,
Ce qui fait passer le temps de clonage de 20 minutes à 90 secondes

Le , par Bruno

220PARTAGES

4  0 
Cory Wilkerson, responsable de l’ingénierie des produits chez GitHub, a annoncé le 11 août la disposition de Codespaces pour les plans Team et Cloud Enterprise sur GitHub. Codespaces offre aux équipes logicielles un environnement de développement collaboratif dans le cloud. Cette version comprend de nouvelles icônes inspirées de Fluent pour le gestionnaire de tâches. Elle apporte également une nouvelle option qui permet de définir le Terminal Windows comme le terminal par défaut. « Codespaces est déployé progressivement depuis le 11 août 2021 et peut être activé dans les paramètres par les propriétaires d'organisation pour les plans Team et Enterprise Cloud. Pour les utilisateurs des plans individuels, nous prolongeons la version bêta existante de Codespaces. Pour les utilisateurs de la version bêta, l'accès sera maintenu et nous partagerons des mises à jour sur les nouveautés dans un avenir proche », a déclaré GitHub sur le blog Codespaces.


Codespaces de GitHub a presque 14 ans. Lorsque le premier commit pour GitHub a été poussé, Rails n'avait que deux ans. AWS en avait un. Azure et GCP n'existaient pas encore. Au cours de ces 14 années, le dépôt central de GitHub (github/github) a reçu plus d'un million de modifications. La grande majorité d'entre elles proviennent de développeurs qui créent et testent des applications sous macOS. Au cours des derniers mois, GitHub a abandonné son modèle macOS et est passé à Codespaces pour la majorité des développements sur GitHub. Cela a été un changement fondamental pour le flux de développement quotidien. En conséquence, le produit Codespaces est plus solide. Avec Codespaces, GitHub peut mettre à niveau les spécifications de la machine de chaque ingénieur avec un seul changement de configuration. Au début de la migration vers Codespaces, GitHub utilisait des machines virtuelles à 8 cœurs et 16 Go de RAM. Voici, ci-dessous, quelques caractéristiques de Codespaces :

  • toute la puissance de Visual Studio Code : Codespaces utilise toute la puissance de Visual Studio Code, notamment l'éditeur, le terminal, le débogueur, GitHub Copilot, le contrôle de version, la synchronisation des paramètres et tout l'écosystème des extensions. Il offre la possibilité de travailler dans le navigateur ou transférez-le projet sur le bureau ;
  • plus rapide que votre ordinateur portable : grâce aux images préconstruites, il est possible de Créer un nouvel environnement de développement pour n'importe quel projet en quelques secondes. L'image de développement de 35 Go de GitHub démarre en moins de 10 secondes. Il est également possible de faire évoluer une VM en cloud jusqu'à 32 cœurs et 64 Go de RAM ;
  • environnements de développement standardisés : avec Codespaces, il est possible de rejoindre une nouvelle équipe et commencer à coder. Standardisez les environnements, les exigences d'exécution, les spécifications matérielles, les extensions et les paramètres de l'éditeur dans les fichiers de configuration.devcontainer.json. Il est également possible d’isoler les dépendances entre les projets avec les conteneurs et docker-compose ;
  • prévisualisation du navigateur et transfert de port : Codespaces apporte la possibilité de prévisualiser les modifications dans le navigateur avec des rechargements instantanés (prise en charge de websocket et HMR) et partager des ports privés et publics avec des coéquipiers.

Au fil des ans, GitHub a investi beaucoup de temps et d'efforts pour que le développement local fonctionne bien dès le départ. L’approche scripts-to-rule-them-all a présenté une interface familière aux ingénieurs depuis un certain temps déjà. Les nouvelles recrues pouvaient cloner github/github, exécuter des scripts de configuration et d'amorçage et faire fonctionner une instance locale de GitHub en une demi-journée. Dans la plupart des cas, les choses fonctionnaient simplement, et quand ce n'était pas le cas, le script GitHub de démarrage ouvrait un problème GitHub connectant le nouvel employé au support interne. Le canal Slack #friction, animé par des ingénieurs GitHub, permettait de déboguer presque toutes les configurations du système.


Pourtant, malgré tous ces efforts, le développement local restait fragile. N'importe quel changement apparemment inoffensif pouvait rendre un environnement local inutilisable et, pire encore, nécessiter des heures de développement pour le récupérer. Les ruptures mystérieuses étaient si fréquentes et si catastrophiques que GitHub avait codifié une option pour le script de démarrage : --nuke-from-orbit. Lorsqu'il est invoqué, le script supprime autant qu'il le peut de manière responsable pour tenter de restaurer l'environnement local dans un état connu. Et bien sûr, il s'agit d'une histoire classique que toute personne travaillant dans le domaine de l'ingénierie logicielle reconnaîtra immédiatement. Les environnements de développement locaux sont fragiles. Et même lorsqu'il fonctionne parfaitement, un environnement de développement local sur mesure et à contexte unique est de plus en plus en décalage avec le monde instantané et accessible de partout dans lequel nous évoluons aujourd'hui.

La collaboration sur plusieurs branches dans plusieurs projets était pénible. Des démarrages de 45 minutes lorsqu'une branche introduisait de nouvelles dépendances, des changements de schéma ou une branche provenant d'une ZSD différente. Étant donné la rapidité avec laquelle codebase change, GitHub déploie des centaines de modifications par jour, ce qui était par le passé une source régulière de frictions techniques. En construisant Codespaces, GitHub s’engage avec plusieurs organisations d'ingénierie de premier ordre qui avaient construit des plateformes similaires à Codespaces pour résoudre ces mêmes types de problèmes. À une échelle significative, la suppression de ce type de perte de productivité devient très rapidement une opportunité de productivité très claire.


Infrastructure de développement

Dans le monde de l'infrastructure, les meilleures pratiques de l'industrie ont continué à positionner les serveurs comme une marchandise. L'idée est qu'aucun serveur n'est unique, indispensable ou irremplaçable. Toute pièce peut être retirée et remplacée par une pièce comparable sans fanfare. Si un serveur tombe en panne, ce n'est pas grave ! On le démonte et on le remplace par un autre. Cependant, les environnements de développement locaux de GitHub sont tous uniques et avec leurs propres particularités. Par conséquent, leur maintenance requiert une vigilance quasi constante. Le prochain git pull ou bootstrap peut rapidement dégrader l’environnement, nécessitant un changement de contexte coûteux pour un effort de récupération alors que vous préféreriez construire des logiciels. Il n'y a pas la convention d'un ordinateur portable chaud à portée de main.

Avec Codespaces, GitHub offre l'opportunité de traiter ses environnements de développement comme cela est fait pour l'infrastructure. Une commodité qui peut être renouvelée tout en conservant la possibilité de soigner son poste de travail. Les extensions Visual Studio Code, la synchronisation des paramètres et les dépôts dotfiles permettent de rapprocher l’environnement GitHub de son ordinateur. Dans ce contexte, un banc de travail cassé n'est qu'un inconvénient mineur : étant donné que GitHub peut provisionner un nouveau Codespaces dans un état connu et bon et ainsi, remettre le développeur au travail.

La migration vers Codespaces permet de combler les lacunes des environnements de développement existants. Le référentiel GitHub représente près de 13 Go sur le disque ; le simple clonage du référentiel prend 20 minutes. Combiné à la configuration des dépendances, le démarrage d'un espace de code GitHub prendrait plus de 45 minutes. Ces 14 années d'hypothèses centrées sur macOS par GitHub et intégrées dans le processus de démarrage allaient devoir être annulées. L'équipe d'ingénieurs de GitHub est passée à Codespaces , ce qui fait passer le temps de clonage de 20 minutes à 90 secondes.

Adoption de Codespaces

Aujourd’hui, GitHub fournit des Codespaces fonctionnels sur des hôtes Linux et offre la possibilité de se connecter à partir de Visual Studio Code pour expédier quelques travaux. L’objectif avec Codespaces est d'adopter un modèle dans lequel les environnements de développement sont provisionnés à la demande pour la tâche à accomplir (en gros, une correspondance 1:1 entre les branches et les Codespaces). GitHub a modifié la façon dont Codespaces clone github/github. Au lieu d'effectuer un clonage complet lors de l'approvisionnement, Codespaces exécute désormais un clonage superficiel, puis, après la création d'un Codespace avec les commits les plus récents, supprime l'historique du dépôt en arrière-plan. Ce faisant, le temps de clonage est passé de 20 minutes à 90 secondes.

Bien qu’un travail de fond ait été effectué, il existe cependant encore des améliorations à apporter : la mise en cache du réseau de logiciels et de services qui supportent GitHub, y compris les dépendances traditionnelles basées sur Gemfile ainsi que les services écrits en C, Go et une construction personnalisée de Ruby. La solution était une action GitHub qui s'exécutait chaque nuit, clonait le dépôt, amorçait les dépendances, construisait et poussait une image Docker du résultat. L'image publiée était ensuite utilisée comme image de base dans le devcontainer-config-as-code de github/github pour les environnements Codespaces. Les codespaces seraient désormais créés avec un taux de démarrage de plus de 95 %. Ces deux changements, ainsi qu'une poignée d'optimisations des applications et des niveaux de service, ont fait passer le temps de création des codespaces de GitHub de 45 minutes à cinq minutes. Mais cinq minutes, c'est encore très loin de l’attente des développeurs. Des études bien connues ont montré que les gens peuvent supporter environ dix secondes d'attente avant de perdre le fil. Donc, bien que des progrès aient été faits, il y a encore du chemin à parcourir.

L’approche du clone peu profond de GitHub, utile pour se lancer dans Codespaces, nécessitait toujours de payer le coût d'un clone complet à un moment donné. Une charge post-création ingrate générée avec des effets secondaires gênants. Tout projet complexe et de grande envergure serait confronté à une catégorie similaire de problèmes au cours desquels le clonage et l'amorçage créent des conflits pour les ressources disponibles. Que se passerait-il si GitHub pouvait cloner et amorcer le référentiel à l'avance, de sorte que lorsqu'un ingénieur demande un espace de code, le gros du travail soit déjà effectué. C'est là qu'interviennent les préconstructions : des pools d'espaces de code, entièrement clonés et amorcés, qui mis en relation avec les développeurs.

« Codespaces m'a permis de faire fonctionner un serveur en quelques minutes, ce qui n'arrive jamais lorsqu'on est nouvellement embauché. Quelle première semaine géniale ! », déclare Chris Westra, Ingénieur logiciel.

Si certains utilisateurs comme Chris Westra, n’observent que l’aspect technique, d’autres par contre vont au-delà. C’est le cas de cet internaute qui estime que : l’utilisation d’un tel système peut permettre à Microsoft de collecter les données analytiques (code écrit, frappes au clavier, mouvements de la souris, horaires de sommeil/travail, mesures de productivité) sur ces derniers, monétiser ces données en les utilisant pour construire un produit d'IA comme Copilot, ou construire un tableau de bord de productivité pour que les managers puissent virer les gens qui ne sont pas assez productifs. Ou alors les utiliser pour diffuser des publicités, ou faire des choses non éthiques qui finiront à long terme par nuire aux utilisateurs.

« Je ne suis pas contre le concept d'utilisation d'un client léger pour le développement, mais il ne me semble pas intelligent de le faire d'une manière telle que vous devez faire confiance à une société qui, tout au long de son existence, a constamment prouvé que vous ne devriez pas lui faire confiance, parce qu'elle n'a aucun intérêt à (et donc ne le fera jamais) agir dans votre intérêt. C'est comme si Facebook sortait son propre navigateur web et "promettait" de respecter votre vie privée ; vous seriez idiot de les croire », souligne l'internaute avisé.

Source : GitHub

Et vous ?

Avez-vous une expérience avec GitHub ?

Que pensez-vous de cette orientation de GitHub ?

Êtes-vous pour ou contre l'utilisation des clients légers pour le développement ?

Pensez-vous que l'utilisation de Codespaces peut permettre à Microsoft de collecter les données analytiques sur les utilisateurs ?

Voir aussi :

Des cybercriminels ont piraté les serveurs de GitHub pour le minage de cryptomonnaies, l'exploit pourrait faire tourner jusqu'à 100 mineurs de cryptomonnaies au cours d'une seule attaque

GitHub rétablit le dépôt youtube-dl, modifie son processus dans le traitement des demandes DCMA et met sur pied un fonds de défense des développeurs d'un million de dollars

GitHub permet désormais de créer un nombre illimité de référentiels privés avec son offre gratuite et annonce une offre unifiée pour les entreprises

Google dévoile une faille de sécurité « grave » concernant la plateforme GitHub de Microsoft, aucun correctif n'est disponible pour le moment et les utilisateurs sont invités à faire des mises à jour

Une erreur dans cette actualité ? Signalez-le nous !