Saisies

Dans cet article, je veux partager mon expérience de la façon dont nous avons résolu le problème des tâches de «gel» dans notre entreprise.

Je travaille dans une startup, qui, comme toutes les startups, connaît une phase de croissance de 10 personnes il y a un an à 35 personnes aujourd'hui, et le nombre de programmeurs est passé de 5 à 25 personnes pendant cette période et la plupart d'entre eux sont venus au cours des six derniers mois.

La structure de l'entreprise, malgré sa jeunesse, je l'appellerais démodée, car personne n'a jamais été impliqué dans les processus de construction. Avec la croissance, nous nous sommes séparés en une équipe de développement, une équipe de test et une équipe de devops, et tout a fonctionné plus ou moins.

Le processus de développement, s'il peut être appelé un «processus», était comme ceci:

Le travail du développeur a pris fin dès que le code a passé la revue de code et il l'a mis à mort dans le développement.

Le travail du testeur s'est terminé quand il a testé et smerzhil dans la branche principale.
Les Devops ont parfois cliqué sur le bouton "Déployer vers Prod", après que le responsable du projet quotidien a déclaré: "Ils n'ont pas été déployés depuis longtemps, peut-être que nous serons annulés aujourd'hui?"

À quoi bon:

• Beaucoup d'automatisation, par exemple, les statuts dans Jira sont synchronisés avec les étiquettes de branche dans GitLab, une tâche dans Jira se ferme après un déploiement vers prod, le code est automatiquement déployé pour tester et mettre en scène des environnements avec une fusion dans develop et master, respectivement.
• Tout est couvert de haut en bas avec des tests.
• Les programmeurs rédigent eux-mêmes des plans de test et testent la fonctionnalité principale.

Les problèmes:

• Les testeurs ne peuvent rien faire pendant une semaine, car les tâches se bloquent dans l'état code_review. À la fin de la semaine, les programmeurs font toujours cette revue et le lundi, les testeurs ont beaucoup de travail.
• Depuis la révision du code, tout est corrigé dans develop et si quelque chose contient un bug, nous ne pouvons rien déployer. Alors qu'un développeur corrige ce bogue, un autre peut puer une autre fonctionnalité qui contient également un bogue. Pour cette raison, nous attendions une semaine ou deux jusqu'à ce que ce brunch se stabilise et le testeur ait le temps de le piétiner en maître avant que l'un des développeurs n'engage autre chose à développer.
• Déployez les fonctionnalités dans de grands ensembles, ce qui augmente les risques de mal tester ou d'attraper quelque chose pendant le déploiement.

Je décrirai deux cas qui nous ont clairement montré qu'il est impossible de travailler plus avant.

Ainsi, par exemple, l'un des vendredis, nous avons eu 15 brunchs dans le code_review de statut, et lundi, ils ont tous changé le statut en ready_for_test. Les testeurs ont dit au Daily combien ils nous aiment. Et pendant trois mois, nous n'avons pas pu vendre, pour diverses raisons, quelques fonctionnalités assez importantes.

Tout d'abord, nous avons trouvé beaucoup de code_review. Il s'est avéré que ce problème peut être résolu tout simplement grâce aux règles suivantes:

1. Seules trois tâches peuvent avoir le statut code_review. Il s'agit de la règle la plus importante qui ne peut être violée.
2. Si le programmeur a terminé le développement et veut traduire la tâche en code_review, il cherche à voir s'il peut le faire (voir règle 1).
3. S'il y a déjà trois tâches dans l'état code_review, il aide d'abord son collègue à réviser le code. Et si dans le processus de révision, il a des commentaires ou des suggestions de changement, alors il va faire une programmation en binôme avec un collègue dont il examine la tâche.

L'idée principale est de ne pas laisser le code se figer lorsqu'il est déjà écrit et de fournir aux testeurs un flux de travail uniforme pendant une semaine.

Nous l'avons implémenté en une heure: nous nous sommes réunis, avons discuté et sommes allés faire un examen et faire de la programmation en binôme.

S'il arrive que quelqu'un oublie (et parfois quelqu'un oublie nécessairement) la première règle, alors la phrase «Nous avons plus de 3 RP dans code_review» s'envole immédiatement dans la salle de chat. Passons en revue !!! ". Dans le même temps, il n'y a pas de personne spéciale qui s'assurerait qu'il n'y a pas plus de trois requêtes pull, cela est fait par les développeurs eux-mêmes.

Malgré le fait que ces changements ont empêché le gel des tâches, nous avons toujours eu des problèmes avec les déploiements et les fuites de bogues en développement. Depuis la révision du code, nous avons toujours fusionné dans la branche de développement et il a été automatiquement déployé dans l'environnement de test pour les tests.

Cette solution était une sorte de correctif, puis il était nécessaire d'apporter des modifications de base aux processus.

La principale chose que nous avons décidé de faire est de déplacer les zones de responsabilité. Désormais, la société ne dispose pas d'une équipe de développement, d'une équipe de test ou d'une équipe de développement distinctes qui se transfèrent les tâches et ne sont responsables que de leur part.

Nous avons organisé les développeurs en plusieurs équipes: une pour chaque client, car nous avons un produit principal, mais il est personnalisé pour chaque client depuis assez longtemps (nous sommes un hybride d'une entreprise de produits et services). Désormais, la livraison des fonctionnalités au prod est de la responsabilité de l'équipe. Il n'y a pas d'équipes de test et de devops familiers, mais il existe QA en tant que service et DevOps en tant que service.

QA as a service est une équipe qui ne teste pas, mais assure la qualité des produits. Les ingénieurs QA aident les développeurs à rédiger des plans de test et à participer aux sessions de test. Nous les avons donc libérés des tests manuels et ils ont eu le temps d'écrire des tests de bout en bout et de développer des outils pour les aider. Nous avons également mis en place un système de suivi.

DevOps as a service est une équipe qui développe des scripts de déploiement, prend en charge le travail des environnements de test et automatise diverses tâches.

Le nouveau processus de développement est le suivant:

1. Il y a une tâche, du client, du chef de produit ou de l'un des sommets.
2. Au stade de la planification du sprint, nous l'intégrons dans le développement.
3. Le développeur écrit le code dans une branche distincte pour la tâche et lorsqu'il a terminé le traduit dans l'état code_review.
4. Un de mes collègues fait une revue.
5. Lorsque la tâche a passé l'examen, le développeur fusionne dans la branche avec la tâche tout ce qui est engagé à développer et déploie cette branche dans l'environnement de test.
6. Il planifie ensuite un rallye que nous appelons Test Session et y invite un ingénieur QA et des collègues si nécessaire.
7. L'ingénieur QA vérifie et affine le plan de test avant la session de test.
8. Lors de la session de test, le développeur parcourt l'intégralité du plan de test sous forme de démonstration. Parfois, un plan de test est divisé en plusieurs parties, puis nous testons en parallèle. L'essentiel est que cela se fasse ensemble dans une salle séparée pour les réunions.
9. Si après le test, les bogues n'ont pas été trouvés, le développeur fusionne son code dans la branche de développement et immédiatement dans la branche principale (c'est quelque chose que nous n'avons pas encore changé, car nous devons encore mettre à jour les scripts de déploiement). À l'avenir, nous prévoyons de ne laisser que la branche principale.
10. Après cela, le développeur démarre le déploiement sur le transfert, juste pour vérifier que le déploiement s'exécute toujours sur un environnement identique au produit.
11. Si tout va bien, déployez immédiatement sur le prod. La décision de déployer ou non est prise par l'équipe de développement, mais QA a le droit d'arrêter les déploiements si elle considère que des tests supplémentaires sont nécessaires, ou qu'il est nécessaire d'attendre s'il est nécessaire de corriger un bogue critique sur la prod.

Fait intéressant, cette transformation a lancé des changements supplémentaires non pas dans le processus de développement, mais dans la planification et a changé les sujets dont nous parlons dans le Quotidien.

Maintenant, parce que le développeur est responsable de la livraison de la user story au prod, lors de la planification, nous avons commencé à écrire la user story de manière à ce que chacun soit indépendant des autres, et pourrait également être déployé indépendamment, une telle unité déployable. L'histoire de l'utilisateur s'est agrandie, mais elle a diminué.

Également sur la planification, nous n'évaluons pas le temps de développement, mais parlons du moment où nous prévoyons de déployer une fonctionnalité.

Au Quotidien, nous ne disons pas que "j'ai terminé le développement", mais nous disons "aujourd'hui, je vais déployer la fonctionnalité X", ou "aujourd'hui je retire l'environnement de test, qui a le temps de m'aider avec la session de test?".

En conséquence, nous avons développé des équipes de développement indépendantes qui possèdent leurs propres environnements de test et planifient quoi et quand se déployer.