J'ai récemment visité DevOpsForum 2019 hébergé par Logrocon. Lors de cette conférence, les participants ont tenté de trouver des solutions et de nouveaux outils pour l'interaction efficace des entreprises et des spécialistes des services de développement et de technologie de l'information.
La conférence a été un succès: il y avait 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'essaye de me vendre quoi que ce soit, que les orateurs des grandes conférences ont récemment blâmé.
Tirez parti 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 en tant que testeur, je suis engagé dans l'automatisation, ainsi que DevOps et j'aime aller à des conférences et des réunions. 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, je fais attention au programme de la conférence. Dans une moindre mesure, j'examine le contenu du rapport, dans une plus large mesure - pour 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 bonnes pratiques du rapport dans votre entreprise. Et puis vous avez besoin d'un haut-parleur.
Lumière au bout du pipeline à Raiffeisenbank
Habituellement, je vais à la recherche d'orateurs intéressants en marge. Au DevOpsForum 2019, un conférencier de Raiffeisenbank, Mikhail Bizhan, est entré dans mon domaine d'intérêt. Pendant le discours, il a expliqué comment ils installaient régulièrement leurs équipes sur DevOps, pourquoi ils en avaient 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 de RaiffeisenbankMaintenant, leur entreprise ne dispose pas de «DevOps». Autrement dit, il est vrai, mais pas dans toutes les équipes. Lors de la mise en œuvre de DevOps, ils s'appuient sur la volonté des équipes tant du point de vue d'ingénieurs spécifiques que du point de vue des besoins du produit et de la maturité de la plateforme sur laquelle ce produit est construit. Misha a expliqué comment expliquer à l'entreprise pourquoi DevOps était nécessaire.
Le segment bancaire a plusieurs relais de croissance: le coût des services et l'expansion de la clientèle. L'augmentation du coût des services n'est pas un très bon moteur, mais la croissance de la clientèle est l'inverse. Si les concurrents produisent un produit objectivement cool, tous les clients y vont, puis au fil du temps, le marché s'égalisera. Par conséquent, le lancement de nouveaux produits sur le marché et la rapidité de leur lancement sont les principaux éléments qui guident les banques. C'est exactement à cela que sert DevOps, et l'entreprise le comprend.
Remarque importante suivante: DevOps ne réduit pas toujours le délai de commercialisation. DevOps ne peut pas fonctionner seul, il n'est qu'une partie du processus de création et de lancement d'un produit sur le marché du développement à la production (du code au client). Mais tout ce qui précède le code n'a pas de relation directe avec DevOps. Autrement dit, les commerçants peuvent étudier le marché pendant des années et rattraper leurs concurrents toute leur vie. Vous devez comprendre rapidement ce dont le client a besoin et planifier la mise en œuvre d'une fonctionnalité particulière - souvent cela ne suffit pas pour que DevOps fonctionne et que l'entreprise atteigne son objectif. Par conséquent, tout d'abord, Raiffeisenbank a convenu avec l'entreprise qu'il était nécessaire d'apprendre à utiliser DevOps. L'automatisation au nom de l'automatisation n'aidera pas beaucoup dans la lutte pour les nouveaux clients.
En général, Misha pense que DevOps doit être implémenté, mais avec sagesse. Et vous devez être préparé au fait qu'au début de la transformation, l'équipe perdra de la productivité, elle gagnera moins d'argent, mais cela deviendra réalité.
Automatisation des tests chez Mango Telecom
Yegor Maslov de Mango Telecom a fait un autre rapport intéressant pour moi en tant que testeur. La présentation était intitulée "Automatisation du cycle de test complet dans l'équipe SCRUM." Egor pense que DevOps a été créé spécifiquement pour SCRUM, mais en même temps, introduire DevOps dans l'équipe SCRUM est assez problématique. En effet, l'équipe SCRUM fonctionne toujours quelque part, il n'y a pas de temps pour se laisser distraire par les innovations et reconstruire le processus. Le problème réside également dans le fait que SCRUM n'implique pas de sous-équipes (équipe de testeurs, équipe de développement, etc.). Eh bien, en outre, la documentation est nécessaire pour automatiser le processus existant, et dans SCRUM le plus souvent, il n'y a aucune documentation du tout - «un produit est plus important qu'une sorte de gribouillage».
Après être passés à SCRUM, les testeurs ont commencé à consulter les développeurs sur la façon de tester les fonctionnalités. Progressivement, le volume de fonctionnalités a augmenté, la documentation manquait et ils ont commencé à détecter de nombreux bugs dans la fonctionnalité dans lesquels il n'y avait pas de couverture de test et en général, il n'était plus clair qui et quand la testait. En un mot - confusion et chancelant. Nous avons décidé de passer à l'automatisation des tests. Mais il y a eu ensuite un échec complet. Ils ont attiré des spécialistes externalisés de l'automatisation qui ont écrit sur une pile inconnue des testeurs habituels. Le cadre de l'autotest a certainement fonctionné, mais après le départ des sous-traitants, il a vécu pendant deux semaines. Ensuite, il y a eu une tentative d'introduire l'auto-test numéro deux. Tout a commencé par le fait que tout doit être construit à l'intérieur de l'entreprise, seul (le bon vecteur: accroître l'expertise à l'intérieur), dans le cadre de SCRUM, et en cours de création de documentation. La pile pour l'automatisation doit être égale à la pile du produit (ici je vais diriger plus, eh bien, ne testez pas votre projet en JavaScript avec autre chose). À la fin du sprint, ils ont organisé une démonstration du fonctionnement de l'autotest, avec la participation de 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 possibilité que cet autotest soit utilisé avec précision (et ne sera pas commenté dans un mois en raison d'échecs constants).
Soit dit en passant, un microphone ouvert a fonctionné au DevOpsForum 2019 - un format de performances longtemps connu et, à mon avis, utile. Vous marchez comme ça, écoutez les rapports, puis décidez qu'il vaut la peine de discuter d'un sujet ou d'un problème dans le cadre de la conférence et de partager une expérience pertinente pour résoudre le problème.
J'ai également remarqué que les organisateurs ont fait un flux de courts rapports. Chaque rapport ne dure pas plus de 10 minutes, puis les questions viennent. Ainsi, vous pouvez couvrir un grand nombre de sujets à la fois et déranger les questions aux orateurs intéressés.
Entre les reportages, j'ai parcouru les tribunes des partenaires de la conférence et tiré / gagné beaucoup de choses. Eh, j'adore razdatku!Table ronde et questions DevOps avec Alfastrah Development Director
La cerise sur le gâteau DevOpsForum 2019 pour moi était une session plénière d'une heure avec des experts DevOps. Quatre participants ont été invités à regarder DevOps sous différents angles: Anton Isanin (Alfastrakhovanie, directeur du développement), Naila Zamashkina (Fintech Lab, directeur des opérations), Oleg Egorkin (Rostelecom, Agile-coach) et Anton Martyanov (indépendant expert, a examiné DevOps d'un point de vue commercial).
Les experts se sont assis plus près des gens et cela a commencé: pendant une heure, les participants du public ont posé leurs questions, et les experts ont gonflé. Parfois, un vrai débat a éclaté. Les questions étaient très différentes, par exemple: les ingénieurs DevOps sont-ils absolument nécessaires, pourquoi ne peuvent-ils pas grandir auprès des administrateurs système, si DevOps était 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é sombre de la transformation DevOps.
Imaginez que tout le monde se rassemble et décide que DevOps est nécessaire à la fois pour le produit et pour l'entreprise et l'équipe. Se précipita pour présenter. Tout a fonctionné. Expiré. DevOps nous a rapprochés du client, nous pouvons maintenant répondre rapidement à tous ses souhaits. En conséquence, nous avons une grande division Ops avec des réglementations et des exigences strictes, et elle détecte constamment les défauts du produit, crée un tas d'applications. De plus, tous les défauts ont le statut "urgent", même si le client a soudainement voulu peindre 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 de malentendus de nouvelles fonctionnalités par les clients. Ops embauche 10 autres personnes pour faire face aux défauts, et le développement en embauche 15 autres pour les suivre. Et au lieu d'introduire de nouvelles fonctionnalités, l'équipe travaille avec des SD sans fin, expliquant la fonctionnalité à l'utilisateur et en prenant en charge une. En conséquence, les opérations et le développement sont à l'œuvre, mais le client et l'entreprise ne sont pas satisfaits: les nouvelles fonctionnalités sont bloquées. Il s'avère que DevOps semble être là, mais il ne semble pas l'être.
Concernant la nécessité de mettre en œuvre DevOps, Anton a déclaré sans équivoque que cela dépend directement de la taille de l'entreprise. Si l'entretien d'un client par an rapporte à la société un milliard - DevOps n'est pas nécessaire (à condition que vous n'ayez pas besoin de déployer régulièrement de nouveaux changements sur ce client). Tout est tellement chocolat. Mais si l'entreprise se développe, plus de clients apparaissent, nous devons déjà nous conformer. En règle générale, la société n'a pas d'opérations sympas au départ. D'abord, nous avons vu le produit, et seulement alors nous comprenons que le produit devrait fonctionner, vous devez regarder les serveurs, surveiller les livraisons. Puis Ops surgit. Il reste à comprendre que les opérations, en tant qu'unité distincte, commenceront à exposer un tas d'obstacles au développement et que toutes les livraisons commenceront à ralentir. Autrement dit, dans ce cas, la culture DevOps est déjà pertinente, mais vous ne devez pas oublier son côté sombre.