{"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\/it\/blog\/administrirovanie\/ot-skriptov-k-sobstvennoj-platforme-kak-my-avtomatizirovali-razrabotku-v-tsian","title":{"rendered":"Da script a piattaforma proprietaria: come abbiamo automatizzato lo sviluppo in CIAN","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Da
\n
\nDurante il RIT 2019, il nostro collega Aleksandr Korotkov ha parlato rapporto<\/a><\/noindex> dell'automazione dello sviluppo in TCIAN: per semplificare la vita e il lavoro, utilizziamo la nostra piattaforma Integro. Essa tiene traccia del ciclo di vita delle attivit\u00e0, solleva gli sviluppatori dalle operazioni routinarie e riduce notevolmente il numero di bug in produzione. In questo post, completeremo la presentazione di Aleksandr e racconteremo come abbiamo passato dalla semplice scrittura di script all'integrazione di prodotti open source attraverso la nostra piattaforma e quali sono le attivit\u00e0 della nostra squadra di automazione.
\n\u00a0<\/a><\/noindex><\/p>\n

Livello zero<\/h2>\n

\n\u00abNon esiste un livello zero, non ne so nulla\u00bb<\/b>
\nMaster Shifu dal film \u00abKung Fu Panda\u00bb<\/i><\/p>\n

L'automazione in TCIAN \u00e8 iniziata 14 anni dopo la fondazione dell'azienda. Allora, nel team di sviluppo c'erano 35 persone. Difficile da credere, vero? Certo, in qualche modo l'automazione esisteva, ma un'area separata per l'integrazione continua e la distribuzione del codice ha iniziato a formarsi nel 2015.\u00a0<\/p>\n

A quel tempo avevamo un enorme monolite composto da Python, C# e PHP, distribuito su server Linux\/Windows. Per il deployment di questo mostro avevamo un set di script che eseguivamo manualmente. C'era anche la costruzione del monolite, che portava dolore e sofferenza a causa dei conflitti durante la fusione dei branch, delle correzioni di difetti e della ricostruzione con \u2018un diverso set di attivit\u00e0 nel build\u2019. In modo semplificato, il processo appariva cos\u00ec:<\/p>\n

\"Da
\n
\nQuesto non ci soddisfava e volevamo costruire un processo di build e deployment ripetibile, automatizzato e gestito. Per fare ci\u00f2, avevamo bisogno di un sistema CI\/CD e sceglievamo tra la versione gratuita di Teamcity e Jenkins gratuito, poich\u00e9 avevamo gi\u00e0 lavorato con entrambi e ci soddisfacevano per il set di funzionalit\u00e0. Abbiamo scelto Teamcity come prodotto pi\u00f9 recente. All'epoca non utilizzavamo ancora un'architettura a microservizi e non prevedevamo un numero elevato di attivit\u00e0 e progetti.<\/p>\n

Arriviamo all'idea di un nostro sistema<\/h2>\n

\nL'implementazione di Teamcity ha eliminato solo una parte del lavoro manuale: sono rimasti ancora la creazione di Pull Request, il passaggio delle attivit\u00e0 tra gli stati in Jira, la selezione delle attivit\u00e0 per il rilascio. Su questo aspetto, il sistema Teamcity non riusciva gi\u00e0 a gestire. Era necessario scegliere una strada per un'ulteriore automazione. Abbiamo valutato opzioni per lavorare con script in Teamcity o passare a sistemi di automazione esterni. Alla fine, abbiamo deciso che era necessaria la massima flessibilit\u00e0, che solo una soluzione interna poteva fornire. Cos\u00ec \u00e8 nata la prima versione del sistema di automazione interno chiamato Integro.<\/p>\n

Teamcity si occupa dell'automazione a livello di avvio dei processi di build e deployment, mentre Integro si \u00e8 concentrata sull'automazione di alto livello dei processi di sviluppo. Era necessario unire il lavoro con le attivit\u00e0 in Jira al trattamento del codice sorgente correlato in Bitbucket. In questo stadio, all'interno di Integro hanno cominciato a apparire i propri workflow per lavorare con diversi tipi di attivit\u00e0.\u00a0<\/p>\n

A causa dell'aumento dell'automazione nei processi aziendali, \u00e8 aumentato anche il numero di progetti e run in Teamcity. Cos\u00ec \u00e8 emerso un nuovo problema: un'istanza gratuita di Teamcity non era pi\u00f9 sufficiente (3 agenti e 100 progetti), abbiamo aggiunto un'altra istanza (altri 3 agenti e 100 progetti), poi ancora un'altra. Alla fine abbiamo ottenuto un sistema composto da pi\u00f9 cluster, difficile da gestire:<\/p>\n

\"Da
\n
\nQuando \u00e8 emersa la questione di una quarta istanza, abbiamo capito che non potevamo continuare cos\u00ec, poich\u00e9 i costi totali per il supporto di 4 istanze superavano ogni limite. \u00c8 emersa la questione dell'acquisto di Teamcity a pagamento o della scelta di Jenkins gratuito. Abbiamo effettuato calcoli sulle istanze e i piani di automazione e abbiamo deciso che avremmo usato Jenkins. Dopo un paio di settimane, siamo passati a Jenkins, liberandoci di parte del mal di testa associato al supporto di pi\u00f9 istanze di Teamcity. Cos\u00ec abbiamo potuto concentrarci sullo sviluppo di Integro e sull'ottimizzazione di Jenkins per le nostre esigenze.<\/p>\n

Con l'aumento dell'automazione di base (nella forma di creazione automatica di Pull Request, raccolta e pubblicazione della Code coverage e di altre verifiche), si \u00e8 consolidato il desiderio di abbandonare completamente i rilasci manuali e di delegare questo lavoro ai robot. In aggiunta, all'interno dell'azienda \u00e8 iniziato il passaggio ai microservizi, che richiedevano rilasci frequenti, ciascuno separatamente. Cos\u00ec, gradualmente siamo arrivati ai rilasci automatici dei nostri microservizi (per il monolite, al momento, continuiamo a rilasciarlo manualmente a causa della complessit\u00e0 del processo). Ma, come spesso accade, \u00e8 emersa una nuova difficolt\u00e0.\u00a0<\/p>\n

Automatizziamo i test<\/h2>\n

\n\"Da
\n
\nGrazie all'automazione dei rilasci, i processi di sviluppo si sono velocizzati, parzialmente a scapito di alcune fasi di test. Questo ha portato a una temporanea perdita di qualit\u00e0. Pu\u00f2 sembrare banale, ma con la velocizzazione dei rilasci era necessario cambiare anche la metodologia di sviluppo del prodotto. \u00c8 stato essenziale considerare l'automazione dei test, promuovere la responsabilit\u00e0 personale (qui si parla di \u00abaccettare l'idea nella propria mente\u00bb, non di penali monetarie) per gli sviluppatori riguardo al codice che producono e ai bug presenti, oltre a decidere sul rilascio o meno delle task attraverso il deploy automatico.\u00a0<\/p>\n

Affrontando i problemi di qualit\u00e0, siamo arrivati a due decisioni importanti: abbiamo iniziato a effettuare test canary e implementato un monitoraggio automatico per gli errori con reazione automatica al superamento della soglia. La prima decisione ha permesso di trovare errori evidenti prima che il codice arrivasse in produzione, mentre la seconda ha ridotto il tempo di risposta ai problemi in produzione. Certo, gli errori ci sono, ma spendiamo la maggior parte del tempo e delle energie non per correggerli, ma per minimizzarli.\u00a0<\/p>\n

Team di automazione<\/h2>\n

\nAttualmente abbiamo un team di 130 sviluppatori e continuiamo a crescere<\/a><\/noindex>. Il team di integrazione e consegna continua del codice (da ora in poi, team Deploy and Integration o DI) \u00e8 composto da 7 persone e lavora in due direzioni: sviluppo della piattaforma di automazione Integro e DevOps.\u00a0<\/p>\n

DevOps si occupa degli ambienti Dev\/Beta del sito CIAN, dell'ambiente Integro, supporta gli sviluppatori nella risoluzione dei problemi e sviluppa nuovi approcci per scalare gli ambienti. La direzione dello sviluppo di Integro si occupa sia di Integro sia dei servizi correlati, ad esempio, plugin per Jenkins, Jira, Confluence, e sviluppa anche utility e applicazioni di supporto per i team di sviluppo.\u00a0<\/p>\n

Il team DI collabora con il team Piattaforma, che si occupa dello sviluppo dell'architettura, delle librerie e degli approcci allo sviluppo all'interno dell'azienda. Inoltre, qualsiasi sviluppatore all'interno di CIAN pu\u00f2 contribuire all'automazione, ad esempio, realizzando micro-automazioni secondo le esigenze del team o condividendo idee interessanti per migliorare ulteriormente l'automazione.<\/p>\n

La torta stratificata dell'automazione in CIAN<\/h2>\n

\n\"Da
\n
\nTutti i sistemi coinvolti nell'automazione possono essere suddivisi in diversi strati:<\/p>\n

    \n
  1. Sistemi esterni (Jira, Bitbucket e altri). Questi sono gestiti dai team di sviluppo.\n<\/li>\n
  2. Piattaforma Integro. Gli sviluppatori non lavorano direttamente su di essa, ma \u00e8 fondamentale per il funzionamento di tutta l'automazione.\n<\/li>\n
  3. Servizi di consegna, orchestrazione e scoperta (ad esempio, Jenkins, Consul, Nomad). Questi aiutano a deployare il codice sui server e a garantire che i servizi funzionino tra loro.\n<\/li>\n
  4. Livello fisico (server, OS, software correlato). Su questo livello il nostro codice opera. Pu\u00f2 essere un server fisico o virtuale (LXC, KVM, Docker).\n<\/li>\n<\/ol>\n

    \nIn base a questo concetto, dividiamo le aree di responsabilit\u00e0 all'interno del team DI. I primi due livelli appartengono alla direzione dello sviluppo di Integro, mentre gli ultimi due livelli sono sotto la responsabilit\u00e0 di DevOps. Questa divisione consente di concentrarsi sui compiti e non ostacola l'interazione, poich\u00e9 siamo vicini l'uno all'altro e ci scambiamo costantemente conoscenze ed esperienze.<\/p>\n

    Integro<\/h2>\n

    \nConcentriamoci su Integro e iniziamo con lo stack tecnologico:<\/p>\n