L'équipe d'ingénierie de GitHub migre vers Codespaces,

Ce qui fait passer le temps de clonage de 20 minutes à 90 secondes

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 à...