Comment et pourquoi nous enseignons aux non-ingénieurs à utiliser GitHub chez Thread

Chez Thread, l’une de nos principales convictions est que la technologie permet de grands changements. C’est important pour notre produit, mais également pour notre travail en interne.

En raison de cette façon de travailler, nous essayons de tout représenter dans les données - produits, mesures, styles, fournisseurs, emplacements dans notre entrepôt, résolutions de tickets d’assistance, et bien d’autres choses auxquelles vous n’avez même jamais pensé.

Tous ces modèles de données entraînent un coût, car ils nécessitent un moyen pour les membres de l'entreprise qui les utilisent de gérer les données. Cela signifie la construction d'interfaces d'édition, avec validation, conception de base de données et travail frontal. Souvent, nous n’avons tout simplement pas le temps de le faire: les nouvelles fonctionnalités sont prioritaires et un ingénieur peut en outre mettre à jour quelques fichiers de données en cas de besoin, non?

Bien qu’il s’agisse d’une solution beaucoup plus rapide à court terme, un ingénieur devra changer de contexte, regarder la publication sortir et s’assurer que tout se passe bien - que tout nuit à la productivité. Mais ce qui est peut-être encore plus important, la personne qui a besoin des données mises à jour n’a plus la propriété du processus et dépend du calendrier de quelqu'un d’autre.

En fin de compte, ce processus peut être utile pour extraire rapidement une fonctionnalité, mais provoque beaucoup trop de friction pour fonctionner à long terme.

Une meilleure solution

Je me souviens de la première fois que GitHub avait lancé son éditeur Web - je n’ai pas été impressionné. Pourquoi quelqu'un éditerait-il du code dans un navigateur Web? Pourquoi devrais-je utiliser un éditeur qui ne pourrait changer qu'un fichier par commit? Bien des années plus tard, j'ai réalisé que je ne suis pas le marché cible de l'éditeur.

Chez Thread, nous enseignons régulièrement aux personnes extérieures à l'équipe technique comment contribuer à notre base de code via l'interface Web de GitHub, afin qu'elles maîtrisent la mise à jour des données dont elles ont besoin pour travailler efficacement.

Nous avons maintenant eu plus de contributeurs à notre base de code qui occupent des rôles non techniques que tous les ingénieurs et sous-traitants qui ont contribué au fil des ans.

Cela a-t-il fonctionné?

En tant qu’ingénieur de l’équipe produit, je suis en mesure de concentrer mes efforts sur la création de fonctionnalités avantageuses pour nos clients et le déplacement des métriques, plutôt que sur la création d’autres interfaces CRUD. Je peux également envoyer les tests A / B plus rapidement, car nous pouvons souvent ignorer l’outillage interne de la version test au profit de la modification de données via des fichiers de données. Lorsque nous arrivons à la phase de livraison d'un projet, nous pouvons ensuite mettre l'heure dans les interfaces d'édition, car nous aurons non seulement une idée de la valeur de la fonctionnalité, mais également une meilleure idée de la façon dont nos utilisateurs internes aimeraient la interfaces pour travailler.

Ce n’est pas non plus limité aux fichiers de données; De nombreuses pages de thread.com sont essentiellement du code HTML statique, des pages telles que notre FAQ sur la livraison, notre politique de retour ou nos conditions générales. En apprenant à utiliser GitHub, notre équipe des opérations peut les tenir à jour sans demander d’aide. Notre équipe de talent est également en mesure d’éditer notre site d’emplois, en réagissant quotidiennement aux questions courantes qui se posent lorsque vous parlez à des candidats.

Tout cela signifie que les membres de notre équipe en dehors de l'équipe d'ingénierie sont en mesure de s'approprier beaucoup plus leur travail et ont moins de friction pour effectuer les changements que leur expérience leur dit nécessaires.

Comment faisons-nous ça?

La première chose à faire est de lancer de temps en temps des tutoriels sur GitHub lorsque nous avons quelques nouveaux débutants à enseigner. Nous couvrons les bases de ce qu'est un référentiel, en le comparant aux historiques de révision de documents sur Google Docs, à la signification d'un fichier et à la nature d'une branche. Nous n’en parlons que de manière générale, car nous ne couvrons pas du tout l’interface de ligne de commande dans notre format de didacticiel actuel.

Nous verrons ensuite comment éditer un fichier sur l'interface Web de GitHub, comment écrire un message de validation, ce qu'est une demande d'extraction et ce que signifient les rapports d'état de construction de Jenkins.

Enfin, nous demandons aux contributeurs non techniques de choisir un ingénieur qui est disponible sur Slack pour appuyer sur le bouton de fusion une fois que la construction est verte.

Problèmes rencontrés

Dans l’ensemble, nous pensons que c’est une victoire énorme pour l’ensemble de l’équipe. Nous prévoyons de poursuivre la formation et d’encourager davantage de contributeurs à mesure que nous grandissons, mais nous avons légèrement modifié notre processus en fonction de son évolution.

Premièrement, nous avons utilisé des rôles GitHub et des branches verrouillées pour empêcher les commits accidentels sur des maîtres. Pour ceux qui ne sont pas aussi familiarisés avec le contrôle de version et les branches en particulier, l’interface Web de GitHub n’est pas très claire quant au moment où une validation est appliquée à la branche principale ou à une nouvelle branche. Chez Thread, notre branche principale est déployée en continu, sans intervention manuelle, ce qui a entraîné la publication de plusieurs commits qui ont cassé le site et causé des temps d'arrêt.

En ce qui concerne tous les problèmes liés aux temps d'arrêt, nous avons procédé sans problème à 5 Whys et avons réalisé que, rétrospectivement, nous aurions pu résoudre ces problèmes avec les tests unitaires exécutés avant le déploiement, mais nous n'aurions probablement pas tout résolu. façon de résoudre le problème.

Deuxièmement, en réponse à ce problème, nous avons commencé à écrire des tests unitaires qui vérifient simplement la structure des données dans les fichiers de données ou à vérifier que tous nos fichiers de modèle Django sont correctement analysés en tant que modèles valides. En particulier dans le cas des fichiers de données, ceux-ci ne devraient normalement pas être testés, mais comme nous souhaitons maintenant que les fichiers soient modifiables par des personnes ne connaissant pas le code, elles peuvent être utiles pour détecter des erreurs simples. .

Enfin, comme nous utilisons généralement Python pour nos fichiers de données, nous avons constaté que la syntaxe n’était pas particulièrement intuitive et pouvait prendre un certain temps à s’habituer. Pour résoudre ce problème, nous avons écrit une documentation avec un peu plus de détails que si elle avait été écrite pour un ingénieur. Cette documentation est également disponible dans le référentiel et peut être modifiée par tous. Nous encourageons donc les non-ingénieurs à mettre à jour et à clarifier les instructions à mesure qu'ils apprennent, et à s’apprendre à modifier certaines parties du site.

Avancer

Nous considérons cette expérience comme un succès et la poursuivrons dans un avenir prévisible. Dans les cas où nous concevons des fichiers de données modifiables, nous allons essayer d’inclure des instructions détaillées dans les fichiers eux-mêmes, éventuellement avec des exemples de copie / copie.

Nous essayons déjà de faire en sorte que nos échecs de test comportent des messages d'erreur informatifs avec des détails sur la manière de corriger le problème, mais en raison de la complexité d'interprétation des résultats de test, nous n'exposons pas actuellement Jenkins à des membres non techniques de l'équipe, même s'ils peuvent techniquement le faire. connectez-vous avec l'authentification unique. C’est peut-être la prochaine occasion que nous avons d’améliorer l’expérience en matière de contribution et nous pourrions en faire l’essai dans le prochain lot de nouveaux participants qui suivent le didacticiel.

Pour terminer, j’encourage tous les développeurs à voir s’il existe des opportunités dans vos entreprises pour que des membres d’équipe non techniques contribuent à vos bases de code. La productivité des deux côtés présente des avantages, une plus grande empathie entre les équipes et un sentiment plus fort d'appropriation du travail pour ceux qui ne dépendent plus des développeurs pour leur apporter des changements. La réduction des frottements signifie également des cycles de retour d'information plus courts, ce qui peut transformer le travail que d'autres peuvent accomplir dans leur travail, le tout sans le coût élevé du temps de développement des interfaces d'édition.