Imaginez une situation fantastique - le directeur de l'entreprise décide de mettre en œuvre DevOps. Lui-même, sans pression des techniciens. Sans un exemple convaincant de concurrents. La direction elle-même a reconnu qu'il était impossible d'améliorer la qualité, la prévisibilité, la transparence et la répétabilité des produits dans les processus de développement et de mise en œuvre de logiciels sans outils DevOps.
Présenté? Cela at-il fonctionné? Vous avez réussi le test de l'imagination la plus riche!
En fait, bien sûr, ce n'est pas le cas. Le plus souvent, la gestion n'est pas à la hauteur de nos tâches informatiques. Par conséquent, vous devez convaincre. Mais comment?
Lorsqu'un argument est donné pour accroître la culture de la communication entre les programmeurs et les administrateurs système, il est facile de se heurter à un contre-argument: êtes-vous non civilisé maintenant, ou quoi? Ou ils peuvent même vous rappeler les coûts que l'entreprise avait déjà engagés il y a un an ou deux lorsque vous avez déménagé ensemble pour Agile. Existe-t-il chaque année une fonctionnalité informatique qui peut faire avancer les processus de manière révolutionnaire?
Quant à l'amélioration de la qualité du produit, vous pouvez également balbutier. Mais attention. Étant donné que la tâche de programmation sans erreur n'a pas encore été annulée. Oui, il n'y a aucun bogue de quelque façon que ce soit, mais c'est pourquoi la société a un "département entier de testeurs", non?
La prévisibilité des processus est généralement un tel facteur subjectif, ce qui est assez difficile à justifier et à éviter les blagues sur Wang et Nostradamus.
De plus, si nous parlons d'une entreprise typique, alors dans une telle entreprise, très probablement, il y a déjà une équipe informatique établie. Et cette équipe au rythme habituel (sauf Agile) travaille ensemble depuis de nombreuses années et brûle à peine du désir (encore) de changer quelque chose. Tout convient à tout le monde, sauf, bien sûr, le leadership. Qui voit que dans leur logiciel toutes les erreurs sont constamment diffusées, les conditions de sortie des nouvelles versions sont décalées.
Bien sûr, une autre option peut être envisagée lorsqu'une personne arrive dans l'entreprise avec une expérience dans DevOps, représentant clairement quel est le problème et comment il doit être résolu. Et qui est capable de transmettre son opinion aux dirigeants. Cependant, n'espérons pas un oncle miracle.
Et beaucoup se cassent là-dessus. Ils commencent à dire que personne ne les soutient, qu'il est impossible de mettre en œuvre quoi que ce soit dans ce marais, puis vont simplement dans une autre entreprise, où le cycle se répète.
Il s'avère qu'un cercle vicieux? Non, nous arrivons progressivement à la conclusion qu'avec une entreprise, vous devez parler uniquement dans une langue qu'il comprend - dans la langue de l'argent. Pour ce faire, nous obtenons l'atout principal des jambes à manches larges - la réduction du Time-to-Market. Nous devons montrer que grâce à DevOps, de nouvelles versions du produit seront publiées comme des petits pains. Et laissons tout le reste des avantages ci-dessus de l'implémentation de DevOps pour la présentation finale, que nous créerons pour le réalisateur, quand tout ira bien. Beaucoup diront que c'est trop évident. Non!
Nous avons besoin de quelque chose qui nous prendra un minimum de temps et de ressources (après tout, personne ne permettra d'annuler des mois-homme pour la mise en œuvre d'un certain DevOps et n'achètera pas de nouveaux serveurs de toute urgence pour nous), mais en même temps donnera un résultat très tangible (cela réduira en fait le Time-to -Marché).
Vous devez d'abord trouver un goulot d'étranglement, mais il en est toujours un (la première étape de la théorie des contraintes de Goldratt). Après la mise en œuvre réussie d'Agile (et tout cela n'a de sens qu'après la mise en œuvre d'Agile), en termes de développement logiciel, ils doivent encore tester manuellement. Même avec un pool à main levée, les tests de régression peuvent prendre de deux à trois semaines. Et de la façon dont les testeurs «aiment» effectuer des tests de régression, je sais tout.
Nous avons donc déterminé que les tests constituent le goulot d'étranglement. Ensuite, vous devez commencer par son automatisation. Beaucoup le remarqueront: plus facile à dire qu'à faire. Des millions de lignes de code ont déjà été écrites, et c'est bien si les programmeurs couvrent au moins quelque chose avec des tests unitaires. En fait, tout n'est pas aussi effrayant qu'il n'y paraît. L'expérience montre que 80% du résultat positif sous la forme d'une sérieuse diminution du Time-to-Market est atteint grâce à 20% des efforts. C'est combien coûte les tests d'automatisation dans notre cas.
Absolument selon la loi de Pareto, oui.
Et surtout, vous pouvez commencer à tester l'automatisation avant que la direction accepte d'allouer des ressources pour la mise en œuvre des parties restantes de DevOps. Un petit projet pilote qui peut être réalisé seul en une à deux semaines.
Mais en même temps, une telle situation nous donne une chance de remporter une victoire spectaculaire et, surtout, rapide. Après quoi, ayant une attitude positive et la bénédiction de la direction, vous pouvez déjà demander de l'argent et des ressources.
Pour commencer, bien sûr, vos programmeurs utilisent déjà une sorte de logiciel serveur pour les versions quotidiennes. Cela peut être TeamCity, ou Bamboo, ou Jenkins, - cela n'a pas d'importance. L'essentiel est qu'il existe déjà une partie de l'automatisation et qu'elle doit être utilisée, et sinon, il est facile de la déployer en une journée.
Vous devez d'abord automatiser les tests de fumée. Mais comment comprendre quoi automatiser? Oui, regardez ce que vous avez régulièrement cassé lorsque vous publiez des modifications au cours des six derniers mois.
Ensuite, vous devez créer plusieurs tests pour vérifier le fonctionnement des principaux processus métier. Comment les identifier? Pour demander à vos analystes / directeurs / représentants commerciaux quel type de panne le directeur en colère se précipite dans le bureau du programmeur et définit les tâches à voix haute.
Une semaine, enfin, un maximum de deux pour créer de tels tests. Le résultat est un retour très rapide pour les erreurs globales.
Et pendant que le projet est en mode preuve de concept, vous n'avez pas besoin de préparer le même déploiement de serveur automatique pour les tests et autres arcs, mais faites tout manuellement. Cette beauté peut alors se faire avec plaisir en compagnie d'admins.
Ce à quoi cela mènera n'est pas difficile à deviner. Les développeurs verront immédiatement (et corrigeront) leurs erreurs. Les testeurs seront épargnés de la routine consistant à effectuer des tests de régression longs et fastidieux. Ils auront quelques jours pour tester uniquement les parties du code qui ont été modifiées. Oui, exactement. Si ce n'est pas le cas, revenez au début et discutez à nouveau avec les analystes / directeurs / représentants commerciaux des processus critiques de l'entreprise.
Le goulot d'étranglement à cause duquel les freins principaux se sont levés a été éliminé. Il ne reste plus qu'à publier quelques nouvelles versions dans un environnement productif, à supprimer les statistiques «était / était» et à transmettre ces chiffres à la direction. Profit!
Après une victoire aussi convaincante, vous pouvez déjà parler de l'automatisation du déploiement des stands (au moins pour les tests). Ensuite, demandez des fonds pour la surveillance et d'autres délices DevOps. Il ne faut pas oublier que les autres composants du système n'auront plus d'effet wow pour les entreprises.
Exemple de studio
À la fin de l'article, je pense qu'il serait approprié de donner un exemple de projet achevé avec succès pour la mise en œuvre de DevOps, qui a été mis en œuvre par notre entreprise.
Un grand détaillant détient environ 20% de l'activité dans une boutique en ligne. Dans le même temps, il est nécessaire de réagir très rapidement à la situation du marché et d'apporter les modifications nécessaires au logiciel. Et souvent. Et de haute qualité. Tout montant sur le site peut affecter la conversion, les risques sont exprimés en argent réel.
Pour réduire le temps de mise à jour et d'amélioration de la qualité, une plate-forme d'autotest spécialisée a été créée sur laquelle les tâches de routine pour tester les modifications et la régression du site Web ont été automatisées. De plus, le processus d'interaction du groupe de tests automatisés avec les équipes de développement a été construit. Cela a permis aux développeurs d'identifier et de corriger immédiatement les défauts du système mis à jour, sans attendre le test d'acceptation final.
Les représentants du détaillant ont trouvé l'expérience réussie et ont décidé de l'appliquer à d'autres logiciels.
Et un autre petit exemple, mais de la pratique d'une grande compagnie d'assurance. Avant l'introduction de l'automatisation des tests, les versions étaient publiées tous les six mois. Pas parce que l'entreprise l'exigeait tellement - cela n'a pas fonctionné plus souvent. Et le client voulait juste. Ainsi, deux mois après le début de l'introduction des outils de test automatique, l'équipe informatique est passée à des itérations de deux semaines des versions.
Assez important pour commencer à faire ça, non?
Sergey Stramnov, architecte de prévente du Jet Infosystems Software Solutions Center