J'ai récemment assisté au DevOpsForum 2019, hébergé par Logrocon. Lors de cette conférence, les participants ont tenté de trouver des solutions et de nouveaux outils pour une interaction efficace entre les spécialistes des affaires et des services de développement et de technologie de l'information.
La conférence a été un succès : il y a eu vraiment beaucoup de rapports utiles, des formats de présentation intéressants et beaucoup de communication avec les intervenants. Et il est particulièrement important que personne n’ait essayé de me vendre quoi que ce soit, ce dont se sont rendus coupables ces derniers temps les intervenants lors de grandes conférences.
Un extrait des discours de Raiffeisenbank, Alfastrakhovanie, l'expérience de Mango Telecom dans la mise en œuvre de l'automatisation et d'autres détails sous la coupe.
Je m'appelle Yana, je travaille comme testeur, je fais de l'automatisation, ainsi que du DevOps, et j'aime aller à des conférences et des rencontres. Au cours des deux dernières années, j'ai assisté aux conférences d'Oleg Bunin (HighLoad++, TeamLead Conf), aux événements Jug (Heisenbug, JPoint), TestCon Moscou, DevOps Pro Moscou, Big Data Moscou.
Tout d'abord, j'attire l'attention sur le programme de la conférence. Je regarde moins le sujet du rapport que l'orateur. Même si le rapport s'avère très technologique et intéressant, ce n'est pas un fait que vous pourrez appliquer certaines des meilleures pratiques du rapport dans votre entreprise. Et puis il faut un haut-parleur.
La lumière au bout du pipeline à la Raiffeisenbank
Habituellement, je cherche en marge des intervenants qui m’intéressent. Lors du DevOpsForum 2019, un intervenant de la Raiffeisenbank, Mikhail Bizhan, a suscité mon intérêt. Au cours de son discours, il a expliqué comment ils rendent progressivement leurs équipes accros au DevOps, pourquoi ils en ont besoin et comment vendre l'idée de la transformation DevOps aux entreprises. Eh bien, en général, j'ai parlé de la façon de voir la lumière au bout du pipeline.
Mikhail Bizhan, directeur de l'automatisation chez Raiffeisenbank
Désormais, ils n’ont plus de « DevOps » dans leur entreprise. Autrement dit, il travaille, mais pas dans toutes les équipes. Lors de la mise en œuvre de DevOps, ils s'appuient sur la préparation des équipes, tant en termes d'ingénieurs spécifiques qu'en termes de besoin du produit et de maturité de la plateforme sur laquelle ce produit est construit. Misha a expliqué comment expliquer à une entreprise pourquoi DevOps est nécessaire.
Le segment bancaire dispose de plusieurs moteurs de croissance : le coût des services et l'expansion de la clientèle. Augmenter le coût des services n’est pas un très bon moteur, mais accroître la clientèle est le contraire. Si les concurrents lancent un produit objectivement cool, tous les clients y vont, puis avec le temps, le marché se stabilise. Par conséquent, l’introduction de nouveaux produits sur le marché et la rapidité de leur introduction sont les principales priorités des banques. C’est exactement à cela que sert DevOps, et les entreprises le comprennent.
La prochaine remarque importante : DevOps ne réduit pas toujours les délais de mise sur le marché. DevOps ne peut pas fonctionner seul, il fait simplement partie du processus de création et de mise sur le marché d'un produit, du développement à la production (du code au client). Mais tout ce qui précède le code n’est pas directement lié au DevOps. Autrement dit, les spécialistes du marketing peuvent étudier le marché pendant des années et passer toute leur vie à rattraper leurs concurrents. Il est nécessaire de comprendre rapidement ce dont le client a besoin et de planifier la mise en œuvre de telle ou telle fonctionnalité - c'est souvent ce qui ne suffit pas pour que DevOps fonctionne et que l'entreprise atteigne son objectif. C'est pourquoi Raiffeisenbank a tout d'abord convenu avec les entreprises qu'il était nécessaire d'apprendre à utiliser DevOps. L'automatisation pour le plaisir de l'automatisation n'aidera pas beaucoup dans la lutte pour de nouveaux clients.
En général, Misha estime que DevOps doit être mis en œuvre, mais avec sagesse. Et nous devons être préparés au fait qu’au début de la transformation, la productivité de l’équipe diminuera, elle gagnera moins d’argent, mais cela sera ensuite justifié.
Automatisation des tests chez Mango Telecom
Un autre rapport intéressant pour moi en tant que testeur a été donné par Egor Maslov de Mango Telecom. La présentation s'intitulait « Automatisation du cycle complet de tests dans une équipe SCRUM ». Egor pense que DevOps a été créé spécifiquement pour SCRUM, mais en même temps, introduire DevOps dans une équipe SCRUM est assez problématique. Cela se produit parce que l'équipe SCRUM court toujours quelque part, elle n'a pas le temps de se laisser distraire par les innovations et de reconstruire le processus. Le problème réside aussi dans le fait que SCRUM n’implique pas de séparation des sous-équipes au sein de l’équipe (équipe de tests, équipe de développement, etc.). Eh bien, en plus, pour automatiser un processus existant, une documentation est nécessaire, et dans SCRUM, le plus souvent, il n'y a pas de documentation complète - "le produit est plus important qu'une sorte d'écriture".
Après être passés à SCRUM, les testeurs ont commencé à consulter les développeurs sur la manière de tester les fonctionnalités. Peu à peu, le volume de fonctionnalités a augmenté, il n'y avait pas de documentation et ils ont commencé à détecter de nombreux bugs dans les fonctionnalités qui n'étaient pas couvertes par les tests et en général, il n'était plus clair qui l'avait testé et quand. En un mot : confusion et hésitation. Nous avons décidé de passer à l'automatisation des tests. Mais même à ce moment-là, l’échec fut total. Ils ont embauché des spécialistes en automatisation externalisés qui écrivaient sur une pile inconnue des testeurs internes. Le cadre des autotests a bien sûr fonctionné, mais après le départ des sous-traitants, cela a duré deux semaines. Ensuite, il y a eu une tentative d’introduire le test automatique numéro deux. Tout est parti du fait qu'il faut tout construire au sein de l'entreprise, seul (le bon vecteur : monter une expertise en interne), dans le cadre de SCRUM, et créer au passage une documentation. La pile pour l'automatisation doit être égale à la pile du produit (ici je l'ajoute, ne testez pas votre projet JavaScript avec autre chose). À la fin du sprint, ils ont fait une démonstration du fonctionnement de l'autotest avec toute l'équipe (utile). Ainsi, l'implication de tous les membres de l'équipe dans le processus d'automatisation a augmenté, ainsi que la confiance dans les autotests et la chance que cet autotest soit définitivement utilisé (et ne sera pas commenté dans un mois en raison d'échecs constants).
À propos, au DevOpsForum 2019, il y avait un microphone ouvert - un format de discours connu depuis longtemps et, à mon avis, utile. Vous vous promenez ainsi, écoutez des rapports, puis décidez que lors de la conférence, cela vaut la peine de discuter d'un certain sujet ou d'un problème, en partageant une expérience pertinente pour résoudre le problème.
J'ai aussi remarqué que les organisateurs faisaient un flot de courts reportages. Chaque rapport ne dure pas plus de 10 minutes, suivi de questions. Vous pourrez ainsi aborder plusieurs sujets à la fois et poser des questions aux intervenants qui vous intéressent.
Entre les présentations, j'ai parcouru les stands des partenaires de la conférence et j'ai volé/gagné beaucoup de choses. Oh, j'adore le document !
Table ronde et problématiques DevOps avec le directeur du développement d'Alfastrakhovanie
La cerise sur le gâteau du DevOpsForum 2019 a été pour moi la séance plénière d'une heure avec des experts DevOps. Quatre participants à la session ont été invités à aborder DevOps sous différents angles : Anton Isanin (Alfastrakhovanie, directeur du développement), Nailya Zamashkina (Fintech Lab, directeur opérationnel), Oleg Egorkin (Rostelecom, coach Agile) et Anton Martyanov (expert indépendant, s'est penché sur DevOps d'un point de vue commercial).
Les experts se sont assis plus près des gens et puis les choses ont commencé à bouger : pendant une heure entière, les participants du public ont posé leurs questions, et les experts ont pris le dessus. Il y avait parfois de vrais débats. Les questions étaient très différentes, par exemple : les ingénieurs DevOps sont-ils vraiment nécessaires, pourquoi ne peuvent-ils pas être formés en tant qu'administrateurs système, DevOps devrait-il être proposé à tout le monde, quelle est sa valeur, etc.
Ensuite, j'ai parlé personnellement avec Anton Isanin. Nous avons discuté de la nécessité d'introduire la culture DevOps dans chaque foyer et révélé le côté obscur de la transformation DevOps.
Imaginons que tout le monde se réunisse et décide que DevOps est nécessaire à la fois au produit, à l'entreprise et à l'équipe. Allons le mettre en œuvre. Tout s'est bien passé. Nous avons expiré. DevOps nous a rapproché du client, nous pouvons désormais répondre rapidement à tous ses souhaits. En conséquence, nous disposons d'un grand service opérationnel avec des réglementations et des exigences strictes, qui détecte constamment des défauts dans le produit et crée un tas de demandes. De plus, tous les défauts se voient attribuer le statut « urgent », même si le client souhaitait de manière inattendue colorer le bouton en jaune au lieu de vert. Le projet se développe, le nombre de versions augmente et, par conséquent, le nombre de défauts et d'incompréhensions des nouvelles fonctionnalités par les clients. Les opérations embauchent 10 personnes supplémentaires pour suivre le signalement des défauts, et le développement embauche 15 personnes supplémentaires pour suivre leur résolution. Et au lieu d'introduire de nouvelles fonctionnalités, l'équipe travaille avec une infinité de SD, expliquant en même temps les fonctionnalités à l'utilisateur et au support. En conséquence, les opérations et le développement fonctionnent, mais le client et l'entreprise sont mécontents : les nouvelles fonctionnalités restent bloquées. Il s’avère que DevOps semble exister, mais il ne semble pas exister.
Concernant la nécessité de mettre en œuvre DevOps, Anton a clairement indiqué que cela dépend directement de la taille de l'entreprise. Si le service d'un client par an rapporte un milliard à l'entreprise, DevOps n'est pas nécessaire (à condition que vous n'ayez pas besoin de déployer régulièrement de nouvelles modifications sur ce client). Tout est recouvert de chocolat. Mais si l'entreprise se développe et que davantage de clients apparaissent, vous devez alors vous y conformer. En règle générale, il n'y a pas d'opérations sympas dans l'entreprise au départ. Nous coupons d'abord le produit, et ensuite seulement nous comprenons que pour que le produit fonctionne, nous devons garder un œil sur les serveurs et surveiller les fournitures. C'est à ce moment-là qu'Ops voit le jour. Il reste à comprendre que les Ops, en tant que division distincte, commenceront à ériger de nombreux obstacles au développement et que toutes les livraisons commenceront à stagner. Autrement dit, dans ce cas, la culture DevOps est déjà pertinente, mais il ne faut pas oublier son côté obscur.
Source: habr.com