{"id":55870,"date":"2020-01-30T00:00:00","date_gmt":"2020-01-29T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/ot-skriptov-k-sobstvennoj-platforme-kak-my-avtomatizirovali-razrabotku-v-tsian"},"modified":"2020-02-18T14:04:02","modified_gmt":"2020-02-18T11:04:02","slug":"ot-skriptov-k-sobstvennoj-platforme-kak-my-avtomatizirovali-razrabotku-v-tsian","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/ot-skriptov-k-sobstvennoj-platforme-kak-my-avtomatizirovali-razrabotku-v-tsian","title":{"rendered":"Des scripts \u00e0 notre propre plateforme : comment nous avons automatis\u00e9 le d\u00e9veloppement chez CIAN","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Des
\n
\nLors de RIT 2019, notre coll\u00e8gue Alexandre Korotkov a pr\u00e9sent\u00e9 rapport<\/a><\/noindex> sur l'automatisation du d\u00e9veloppement chez CIAN : pour simplifier la vie et le travail, nous utilisons notre propre plateforme Integro. Elle suit le cycle de vie des t\u00e2ches, d\u00e9charge les d\u00e9veloppeurs des op\u00e9rations r\u00e9p\u00e9titives et r\u00e9duit consid\u00e9rablement le nombre de bugs en production. Dans cet article, nous compl\u00e9terons la pr\u00e9sentation d'Alexandre et raconterons comment nous sommes pass\u00e9s de simples scripts \u00e0 l'int\u00e9gration de produits open source via notre plateforme et ce qu'une \u00e9quipe d'automatisation fait chez nous.
\n\u00a0<\/a><\/noindex><\/p>\n

Niveau z\u00e9ro<\/h2>\n

\n\u00ab Le niveau z\u00e9ro n'existe pas, je ne sais pas ce que c'est \u00bb<\/b>
\nMa\u00eetre Shifu du film \u00ab Kung Fu Panda \u00bb<\/i><\/p>\n

L'automatisation chez CIAN a commenc\u00e9 14 ans apr\u00e8s la cr\u00e9ation de l'entreprise. \u00c0 l'\u00e9poque, l'\u00e9quipe de d\u00e9veloppement comptait 35 personnes. C'est difficile \u00e0 croire, non ? Bien s\u00fbr, d'une certaine mani\u00e8re, l'automatisation existait d\u00e9j\u00e0, mais une direction distincte pour l'int\u00e9gration continue et la livraison de code a commenc\u00e9 \u00e0 se former pr\u00e9cis\u00e9ment en 2015.\u00a0<\/p>\n

\u00c0 ce moment-l\u00e0, nous avions un \u00e9norme monolithe en Python, C# et PHP, d\u00e9ploy\u00e9 sur des serveurs Linux\/Windows. Pour d\u00e9ployer ce monstre, nous avions un ensemble de scripts que nous ex\u00e9cutions manuellement. Il y avait aussi la construction du monolithe, qui causait douleur et souffrance \u00e0 cause des conflits lors de la fusion des branches, des corrections de d\u00e9fauts et de la reconstruction \u00ab avec un autre ensemble de t\u00e2ches dans le build \u00bb. Globalement, le processus ressemblait \u00e0 cela :<\/p>\n

\"Des
\n
\nCela ne nous convenait pas, et nous voulions construire un processus de construction et de d\u00e9ploiement r\u00e9p\u00e9table, automatis\u00e9 et contr\u00f4l\u00e9. Pour cela, nous avions besoin d'un syst\u00e8me CI\/CD, et nous h\u00e9sitions entre la version gratuite de Teamcity et Jenkins gratuit, car nous avions d\u00e9j\u00e0 travaill\u00e9 avec eux et les deux satisfaisaient nos besoins en termes de fonctionnalit\u00e9s. Nous avons choisi Teamcity comme produit plus r\u00e9cent. \u00c0 l'\u00e9poque, nous n'utilisions pas encore une architecture microservices et ne pr\u00e9voyions pas un grand nombre de t\u00e2ches et de projets.<\/p>\n

Nous arrivons \u00e0 l'id\u00e9e d'un syst\u00e8me propre.<\/h2>\n

\nLa mise en \u0153uvre de Teamcity a \u00e9limin\u00e9 une partie du travail manuel : il reste encore \u00e0 cr\u00e9er des Pull Requests, \u00e0 faire avancer les t\u00e2ches dans Jira et \u00e0 choisir les t\u00e2ches pour les versions. Avec \u00e7a, Teamcity ne pouvait d\u00e9j\u00e0 plus g\u00e9rer. Il fallait choisir la voie d'une automatisation suppl\u00e9mentaire. Nous avons envisag\u00e9 des options de scripts dans Teamcity ou le passage \u00e0 des syst\u00e8mes d'automatisation tiers. Mais au final, nous avons d\u00e9cid\u00e9 qu'il fallait la flexibilit\u00e9 maximale, que seule une solution interne pouvait offrir. C'est ainsi qu'est n\u00e9e la premi\u00e8re version de notre syst\u00e8me d'automatisation interne appel\u00e9 Integro.<\/p>\n

Teamcity s'occupe de l'automatisation au niveau du lancement des processus de construction et de d\u00e9ploiement, tandis qu'Integro s'est concentr\u00e9 sur l'automatisation de haut niveau des processus de d\u00e9veloppement. Il fallait combiner le travail sur les t\u00e2ches dans Jira avec le traitement du code source associ\u00e9 dans Bitbucket. \u00c0 ce stade, des workflows sp\u00e9cifiques ont commenc\u00e9 \u00e0 appara\u00eetre au sein d'Integro pour travailler avec diff\u00e9rents types de t\u00e2ches.\u00a0<\/p>\n

Avec l'augmentation de l'automatisation dans les processus commerciaux, le nombre de projets et d'ex\u00e9cutions dans Teamcity a augment\u00e9. Cela a engendr\u00e9 un nouveau probl\u00e8me : un seul instance gratuite de Teamcity ne suffisait plus (3 agents et 100 projets), nous avons ajout\u00e9 une autre instance (encore 3 agents et 100 projets), puis une autre. Au final, nous avons obtenu un syst\u00e8me compos\u00e9 de plusieurs clusters, difficile \u00e0 g\u00e9rer :<\/p>\n

\"Des
\n
\nLorsque la question d'une quatri\u00e8me instance s'est pos\u00e9e, nous avons compris qu'il ne pouvait plus \u00eatre question de continuer ainsi, car les co\u00fbts cumul\u00e9s de maintenance de 4 instances d\u00e9passaient largement les limites acceptables. Il fallait envisager l'achat d'une Teamcity payante ou opter pour la gratuite Jenkins. Nous avons effectu\u00e9 des calculs sur les instances et les plans d'automatisation et avons d\u00e9cid\u00e9 que nous allions vivre avec Jenkins. Apr\u00e8s quelques semaines, nous avons migr\u00e9 vers Jenkins et nous nous sommes d\u00e9barrass\u00e9s d'une partie des tracas li\u00e9s \u00e0 la maintenance de plusieurs instances de Teamcity. Cela nous a permis de nous concentrer sur le d\u00e9veloppement d'Integro et d'adapter Jenkins \u00e0 nos besoins.<\/p>\n

Avec l'augmentation de l'automatisation de base (sous la forme de la cr\u00e9ation automatique de Pull Requests, de la collecte et de la publication de la couverture de code et d'autres v\u00e9rifications), il est devenu imp\u00e9ratif de s'\u00e9loigner des publications manuelles et de confier ce travail aux robots. De plus, l'entreprise a commenc\u00e9 sa transition vers des microservices, n\u00e9cessitant des publications fr\u00e9quentes, chacune s\u00e9par\u00e9ment. Ainsi, nous avons progressivement adopt\u00e9 les publications automatiques de nos microservices (le monolithe est encore publi\u00e9 manuellement en raison de la complexit\u00e9 du processus). Mais, comme c'est souvent le cas, une nouvelle complexit\u00e9 est apparue.\u00a0<\/p>\n

Automatisons les tests<\/h2>\n

\n\"Des
\n
\nEn raison de l'automatisation des publications, les processus de d\u00e9veloppement se sont acc\u00e9l\u00e9r\u00e9s, en partie gr\u00e2ce au passage de certaines \u00e9tapes de test. Cela a entra\u00een\u00e9 une perte temporaire de qualit\u00e9. Cela peut sembler banal, mais avec l'acc\u00e9l\u00e9ration des publications, il fallait \u00e9galement changer la m\u00e9thodologie de d\u00e9veloppement du produit. Il \u00e9tait n\u00e9cessaire de r\u00e9fl\u00e9chir \u00e0 l'automatisation des tests, \u00e0 l'instauration d'une responsabilit\u00e9 personnelle (il s'agit de \u00ab l'acceptation d'une id\u00e9e dans la t\u00eate \u00bb, pas de sanctions financi\u00e8res) des d\u00e9veloppeurs pour le code publi\u00e9 et les bugs qu'il contient, ainsi qu'\u00e0 une d\u00e9cision sur la publication ou non d'une t\u00e2che via le d\u00e9ploiement automatique.\u00a0<\/p>\n

En r\u00e9solvant les probl\u00e8mes de qualit\u00e9, nous avons pris deux d\u00e9cisions importantes : nous avons commenc\u00e9 \u00e0 r\u00e9aliser des tests canari et avons mis en place une surveillance automatique des erreurs avec une r\u00e9ponse automatique en cas de d\u00e9passement. La premi\u00e8re solution a permis de rep\u00e9rer des erreurs \u00e9videntes avant que le code n'atteigne pleinement la production, la seconde a diminu\u00e9 le temps de r\u00e9action aux probl\u00e8mes en production. Des erreurs, bien s\u00fbr, il y en a, mais nous passons une plus grande partie de notre temps et de nos efforts non pas \u00e0 corriger, mais \u00e0 minimiser.\u00a0<\/p>\n

\u00c9quipe d'automatisation<\/h2>\n

\nNous avons actuellement une \u00e9quipe de 130 d\u00e9veloppeurs, et nous continuons \u00e0 cro\u00eetre<\/a><\/noindex>. L'\u00e9quipe d'int\u00e9gration et de livraison continues de code (ci-apr\u00e8s d\u00e9nomm\u00e9e \u00e9quipe CI\/CD) se compose de 7 personnes et travaille dans 2 directions : le d\u00e9veloppement de la plateforme d'automatisation Integro et DevOps.\u00a0<\/p>\n

Le DevOps est responsable des environnements Dev\/Beta du site CIAN, de l'environnement Integro, aide les d\u00e9veloppeurs \u00e0 r\u00e9soudre des probl\u00e8mes et \u00e9labore de nouvelles approches pour l'extension des environnements. La direction du d\u00e9veloppement Integro s\u2019occupe \u00e0 la fois d\u2019Integro elle-m\u00eame et de services connexes, tels que des plugins pour Jenkins, Jira, Confluence, et d\u00e9veloppe \u00e9galement des utilitaires et des applications pour les \u00e9quipes de d\u00e9veloppeurs.\u00a0<\/p>\n

L'\u00e9quipe DI travaille en collaboration avec l'\u00e9quipe Plateforme, qui s'occupe de l'architecture, des biblioth\u00e8ques et des approches de d\u00e9veloppement au sein de l'entreprise. De plus, tout d\u00e9veloppeur au sein de CIAN peut contribuer \u00e0 l'automatisation, par exemple en r\u00e9alisant de la micro-automatisation selon les besoins de l'\u00e9quipe ou en partageant une id\u00e9e innovante pour am\u00e9liorer encore l'automatisation.<\/p>\n

Le g\u00e2teau \u00e0 plusieurs couches de l'automatisation chez CIAN<\/h2>\n

\n\"Des
\n
\nTous les syst\u00e8mes impliqu\u00e9s dans l'automatisation peuvent \u00eatre divis\u00e9s en plusieurs couches :<\/p>\n

    \n
  1. Syst\u00e8mes externes (Jira, Bitbucket, etc.). Ils sont utilis\u00e9s par les \u00e9quipes de d\u00e9veloppement.\n<\/li>\n
  2. Plateforme Integro. Les d\u00e9veloppeurs n'y travaillent g\u00e9n\u00e9ralement pas directement, mais elle soutient le bon fonctionnement de l'ensemble de l'automatisation.\n<\/li>\n
  3. Services de d\u00e9ploiement, d'orchestration et de d\u00e9couverte (par exemple, Jenkins, Consul, Nomad). Gr\u00e2ce \u00e0 eux, nous d\u00e9ployons le code sur les serveurs et garantissons la collaboration entre les services.\n<\/li>\n
  4. Niveau physique (serveurs, syst\u00e8mes d'exploitation, logiciels connexes). Notre code fonctionne \u00e0 ce niveau. Cela peut \u00eatre un serveur physique ou virtuel (LXC, KVM, Docker).\n<\/li>\n<\/ol>\n

    \nSur la base de ce concept, nous d\u00e9limitons les zones de responsabilit\u00e9 au sein de l'\u00e9quipe DI. Les deux premiers niveaux rel\u00e8vent de la direction du d\u00e9veloppement Integro, tandis que les deux derniers niveaux rel\u00e8vent de la responsabilit\u00e9 de DevOps. Cette r\u00e9partition permet de se concentrer sur les t\u00e2ches sans interf\u00e9rer avec la collaboration, car nous sommes proches les uns des autres et \u00e9changeons constamment des connaissances et des exp\u00e9riences.<\/p>\n

    Integro<\/h2>\n

    \nFocalisons-nous sur Integro et commen\u00e7ons par la pile technologique :<\/p>\n