J'ai récemment assisté au DevOpsForum 2019 organisé 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 entreprises et les spécialistes du développement ainsi que de la maintenance informatique.
La conférence a été un succès : il y avait vraiment beaucoup de présentations utiles, des formats d'interventions intéressants et plein d'échanges avec les intervenants. Et surtout, personne n'a essayé de me vendre quoi que ce soit, ce qui est souvent le cas lors des grandes conférences ces derniers temps.
Un résumé des présentations de Raiffeisenbank, d'AlfaStrakhovanie, l'expérience de Mango Telecom dans la mise en œuvre de l'automatisation et d'autres détails ci-dessous.
Je m'appelle Yana, je travaille en tant que testeuse, je m'occupe d'automatisation et de DevOps, et j'adore assister à des conférences et des meetups. Au cours des deux dernières années, j'ai participé aux conférences d'Oleg Bunin (HighLoad++, TeamLead Conf), aux événements Jug (Heisenbug, JPoint), à TestCon Moscow, DevOps Pro Moscow, Big Data Moscow.
En premier lieu, je fais attention au programme de la conférence. Moins à ce que traitera la présentation, plus à l'intervenant. Même si la présentation est très technique et intéressante, il n'est pas certain que tu puisses appliquer des bonnes pratiques dans ta propre entreprise. Et là, il te faut un bon intervenant.
La lumière au bout du pipeline chez Raiffeisenbank
En général, je me lance à la recherche d'intervenants qui m'intéressent dans les couloirs. Au DevOpsForum 2019, l'intervenant qui a attiré mon attention était de Raiffeisenbank - Mikhail Bijan. Lors de sa présentation, il a expliqué comment ils intègrent progressivement leurs équipes au DevOps, pourquoi cela leur est nécessaire et comment vendre l'idée de transformation DevOps à l'entreprise. Et en général, il a parlé de la façon de voir la lumière au bout du pipeline.
Mikhail Bijan, directeur de l'automatisation chez Raiffeisenbank
Actuellement, dans leur entreprise, il n'y a pas de « vrai DevOps ». C'est-à-dire qu'il y a du vrai, mais pas dans toutes les équipes. Lors de la mise en œuvre de DevOps, ils se basent sur la préparation des équipes tant en termes d'ingénieurs spécifiques que sur les besoins du produit et la maturité de la plateforme sur laquelle ce produit est construit. Misha a expliqué comment faire comprendre à l'entreprise pourquoi DevOps est nécessaire.
Le segment bancaire possède plusieurs moteurs de croissance : le coût des services et l'expansion de la clientèle. L'augmentation des coûts des services n'est pas un très bon moteur, tandis que la croissance de la clientèle l'est effectivement. Si les concurrents lancent un produit vraiment impressionnant, tous les clients s'y dirigent, puis, avec le temps, le marché s'équilibre. C'est pourquoi le lancement de nouveaux produits et la rapidité de ce lancement sont des éléments essentiels pour les banques. C'est précisément pour cela que le DevOps est nécessaire, et les entreprises le comprennent.
Une autre remarque importante : le DevOps ne réduit pas toujours le time to market. Le DevOps ne peut pas fonctionner seul, c'est seulement une partie du processus de création et de mise sur le marché d'un produit, de son développement à sa production (du code au client). Tout ce qui précède le code n'a pas de lien direct avec le DevOps. Cela signifie que les spécialistes marketing peuvent étudier le marché pendant des années et passer leur vie à rattraper leurs concurrents. Il est crucial de comprendre rapidement ce dont le client a besoin et de planifier la mise en œuvre de certaines fonctionnalités — souvent, c'est précisément ce qui manque pour que le DevOps fonctionne et que l'entreprise atteigne ses objectifs. Par conséquent, au sein de Raiffeisenbank, il a été convenu avec les entreprises qu'il est nécessaire d'apprendre à utiliser le DevOps. L'automatisation pour le simple fait d'automatiser ne sera pas d'une grande aide dans la lutte pour de nouveaux clients.
En résumé, Misha pense qu'il faut introduire le DevOps, mais avec discernement. Et il faut être prêt à ce qu'au début de la transformation, l'équipe voit sa productivité diminuer, qu'elle génère moins d'argent, mais que cela finisse par porter ses fruits.
L'automatisation des tests chez « Mango Telecom »
Egor Maslov de «Mango Telecom» a également présenté un rapport intéressant pour moi en tant que testeur. La présentation s'intitulait «Automatisation du cycle complet de test dans une équipe SCRUM». Egor estime que DevOps est fait pour SCRUM, mais il est en même temps assez difficile d'intégrer DevOps dans une équipe SCRUM. Cela s'explique par le fait que l'équipe SCRUM est constamment en mouvement, n'ayant pas le temps de se concentrer sur les innovations et de réorganiser le processus. Le problème réside également dans le fait que SCRUM ne prévoit pas la division de l'équipe en sous-equipes (équipe de testeurs, équipe de développeurs, etc.). De plus, pour automatiser un processus existant, une documentation est nécessaire, mais dans SCRUM, la documentation est souvent totalement absente — «le produit est plus important qu'un quelconque papier».
Après le passage à 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é, la documentation était absente, et ils ont commencé à rencontrer de nombreux bogues dans des fonctionnalités qui n'étaient pas couvertes par des tests, et il n'était même plus clair qui les avait testées et quand. En deux mots — désordre et flottement. Ils ont décidé de passer à l'automatisation des tests. Mais même à ce moment-là, cela a été un échec total. Ils ont fait appel à des spécialistes externes pour l'automatisation, qui utilisaient une pile inconnue pour les testeurs internes. Le framework pour les tests automatiques fonctionnait, mais une fois que les externes sont partis, il n'a duré que deux semaines. Ensuite, ils ont essayé une deuxième tentative d'implémentation des tests automatisés. Cela a commencé par le fait que tout devait être construit en interne, par leurs propres moyens (direction correcte : accroître l'expertise en interne), dans le cadre de SCRUM, et de créer de la documentation au fur et à mesure. La pile pour l'automatisation devait être identique à la pile du produit (ici, je suis d'accord, ne testez pas un projet en JavaScript avec autre chose). À la fin de chaque sprint, ils réalisaient une démonstration de la façon dont fonctionnait le test automatique, avec la participation de toute l'équipe (utile). Ainsi, l'engagement dans le processus d'automatisation de tous les membres de l'équipe augmentait, ainsi que leur confiance dans les tests automatisés et la probabilité que ce test soit effectivement utilisé (et ne soit pas commenté dans un mois en raison d'échecs constants).
D'ailleurs, lors de DevOpsForum 2019, il y avait un micro ouvert - un format de présentation bien connu et, à mon avis, utile. Tu te balades, tu écoutes les conférences, puis tu décides qu'il serait pertinent d'aborder un sujet ou un problème dans le cadre de la conférence, de partager une expérience pertinente sur la résolution d'une tâche.
J'ai également remarqué que les organisateurs avaient créé un flux de courtes présentations. Chaque présentation dure pas plus de 10 minutes, suivie de questions. Cela permet de couvrir un grand nombre de sujets et de poser des questions aux intervenants qui ont suscité de l'intérêt.
Entre les présentations, je me suis promenée parmi les stands des partenaires de la conférence et j'ai récupéré/gagné plein de petites choses. Ah, j'adore le matériel promotionnel !
Table ronde et questions sur DevOps avec le directeur de développement chez Alfastrakhovanie.
La cerise sur le gâteau de DevOpsForum 2019 pour moi a été la session plénière d'une heure avec des experts en DevOps. Quatre participants à la session avaient été invités à examiner DevOps de différents points de vue : Anton Isanin (Alfastrakhovanie, directeur de développement), Nailya Zamashkina (Fintech Lab, directrice des opérations), Oleg Egorkin (Rostelecom, coach Agile) et Anton Martyanov (expert indépendant, regardant DevOps du point de vue des affaires).
Les experts se sont assis plus près du public et là, ça a démarré : pendant une heure, les participants de la salle posaient leurs questions, et les experts se débattaient. Parfois, de véritables débats se sont engagés. Les questions étaient des plus variées, par exemple : les ingénieurs DevOps sont-ils vraiment nécessaires, pourquoi ne peut-on pas les former à partir des administrateurs systèmes, faut-il proposer DevOps à tout le monde, quelle est sa valeur, et ainsi de suite.
Ensuite, j'ai eu une discussion personnelle avec Anton Isanin. Nous avons abordé la nécessité de promouvoir la culture DevOps dans chaque foyer et avons révélé le côté sombre de la transformation DevOps.
Imaginons que tout le monde se soit réuni et a décidé que DevOps est nécessaire tant pour le produit que pour le business et l'équipe. C'est parti pour la mise en œuvre. Tout a fonctionné. On a soufflé un bon coup. DevOps nous a rapprochés du client, maintenant nous pouvons rapidement répondre à tous ses désirs. Au final, nous avons un grand département Ops avec des règlements et des exigences stricts, et il génère constamment des défauts sur le produit, créant une multitude de tickets. De plus, tous les défauts sont signalés comme « urgents », même si le client a soudainement décidé de changer la couleur d'un bouton de vert à jaune. Le projet grandit, le nombre de versions augmente et par conséquent, le nombre de défauts et d'incompréhensions concernant les nouvelles fonctionnalités pour les clients s'accroît. Ops recrute encore 10 personnes pour être en mesure de signaler les défauts, et le développement recrute 15 personnes de plus pour les résoudre. Au lieu d'implémenter de nouvelles fonctionnalités, l'équipe travaille sur des SD infinies, expliquant la fonctionnalité aux utilisateurs et également au support au passage. Au final, à la fois Ops et le développement sont occupés, mais le client et le business sont mécontents : les nouvelles fonctionnalités sont bloquées. En somme, DevOps existe en quelque sorte, mais en même temps il semble absent.
Concernant la nécessité d'implémenter DevOps, Anton a clairement affirmé que cela dépend directement de l'échelle de l'entreprise. Si le service d'un seul 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 des modifications pour ce client). Tout va comme sur des roulettes. Mais si l'entreprise croît et que le nombre de clients augmente, il faut alors s'adapter. En général, il n'y a pas de bon Ops dans l'entreprise au départ. D'abord, nous développons le produit, et ensuite nous réalisons que pour que le produit fonctionne, il faut se pencher sur la serveurs très chargés, suivre les livraisons. C'est alors que le concept d'Ops émerge. Il reste à comprendre que Ops, en tant que département distinct, va commencer à ériger de nombreuses barrières pour le développement et toutes les livraisons vont commencer à s'enliser. Donc, dans ce cas, la culture DevOps est déjà pertinente, mais il ne faut pas oublier son côté sombre.
Source : habr.com
