{"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":"Dagli script alla nostra piattaforma: come abbiamo automatizzato lo sviluppo in CIAN","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Dagli
\n
\nDurante il RIT 2019, il nostro collega Alexander Korotkov ha parlato relazione<\/a><\/noindex> dell'automazione nello sviluppo in CIAN: per semplificare la vita e il lavoro, utilizziamo la nostra piattaforma Integro. Essa monitora il ciclo di vita delle attivit\u00e0, solleva gli sviluppatori dalle operazioni routinarie e riduce significativamente il numero di bug in produzione. In questo post, completeremo la presentazione di Alexander e racconteremo come siamo passati da semplici script all'integrazione di prodotti open source tramite la nostra piattaforma e di cosa si occupa un team separato dedicato all'automazione.
\n\u00a0<\/a><\/noindex><\/p>\n

Livello zero<\/h2>\n

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

L'automazione in CIAN \u00e8 iniziata 14 anni dopo la fondazione dell'azienda. All'epoca, il team di sviluppo era composto da 35 persone. Fa fatica a crederci, vero? Certamente, in qualche forma l'automazione esisteva gi\u00e0, ma un segmento dedicato all'integrazione continua e alla consegna del codice ha iniziato a prendere forma nel 2015.\u00a0<\/p>\n

A quel tempo avevamo un enorme monolite scritto in Python, C# e PHP, distribuito su server Linux\/Windows. Per il deploy di questo mostro avevamo un insieme di script che eseguivamo manualmente. C'era anche la compilazione del monolite, che portava dolore e sofferenza a causa dei conflitti durante la fusione dei rami, delle correzioni dei difetti e della ricompilazione \u00abcon un altro insieme di attivit\u00e0 nella build\u00bb. Il processo semplificato appariva cos\u00ec:<\/p>\n

\"Dagli
\n
\nQuesto non ci soddisfaceva, e volevamo costruire un processo di compilazione e deploy ripetibile, automatizzato e gestito. Per questo avevamo bisogno di un sistema CI\/CD, e dovevamo scegliere tra la versione gratuita di Teamcity e Jenkins gratuito, dato che avevamo gi\u00e0 esperienza con entrambi e soddisfacevano entrambe le nostre esigenze funzionali. Abbiamo scelto Teamcity come prodotto pi\u00f9 recente. A quel tempo, non utilizzavamo ancora un'architettura a microservizi e non prevedevamo un numero elevato di attivit\u00e0 e progetti.<\/p>\n

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

\nL'implementazione di Teamcity ha ridotto solo una parte del lavoro manuale: \u00e8 rimasta ancora la creazione di Pull Request, la gestione delle attivit\u00e0 negli stati in Jira e la selezione delle attivit\u00e0 per il rilascio. Su questo aspetto, il sistema Teamcity non era in grado di gestire. Era necessario scegliere una strada per ulteriori automazioni. Abbiamo considerato opzioni di scripting in Teamcity o la transizione a sistemi di automazione esterni. Ma alla fine abbiamo deciso che avevamo bisogno della massima flessibilit\u00e0, che solo una soluzione interna poteva offrire. 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 focalizzata sull'automazione di alto livello dei processi di sviluppo. Era necessario integrare il lavoro con le attivit\u00e0 in Jira con la gestione del codice sorgente correlato in Bitbucket. In questa fase, in Integro sono iniziati a emergere flussi di lavoro propri per gestire attivit\u00e0 di diversi tipi.\u00a0<\/p>\n

Con l'aumento dell'automazione nei processi aziendali, \u00e8 cresciuto 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 un'altra ancora. Alla fine, abbiamo ottenuto un sistema composto da pi\u00f9 cluster, difficile da gestire:<\/p>\n

\"Dagli
\n
\nQuando \u00e8 emersa la necessit\u00e0 di una quarta istanza, ci siamo resi conto che non era pi\u00f9 possibile continuare in questo modo, poich\u00e9 i costi complessivi per supportare 4 istanze stavano gi\u00e0 oltrepassando ogni limite. Si \u00e8 presentata la questione dell'acquisto di Teamcity a pagamento o della scelta di Jenkins gratuito. Abbiamo effettuato calcoli sulle istanze e sui piani di automazione e abbiamo deciso di optare per Jenkins. Dopo qualche settimana, siamo passati a Jenkins e abbiamo alleviato parte del mal di testa associato al supporto di pi\u00f9 istanze di Teamcity. Cos\u00ec siamo riusciti a concentrarci sullo sviluppo di Integro e sull'ottimizzazione di Jenkins per le nostre esigenze.<\/p>\n

Con l'aumento dell'automazione di base (attraverso la creazione automatica di Pull Request, la raccolta e pubblicazione della copertura del codice e altri controlli) \u00e8 nata la forte volont\u00e0 di abbandonare il pi\u00f9 possibile i rilascio manuali e delegare questo lavoro ai robot. Inoltre, all'interno dell'azienda \u00e8 iniziato il passaggio ai microservizi, che richiedevano rilasci frequenti, separati l'uno dall'altro. Cos\u00ec siamo arrivati progressivamente ai rilasci automatici dei nostri microservizi (mentre il monolite viene ancora rilasciato manualmente a causa della complessit\u00e0 del processo). Ma, come accade spesso, \u00e8 emersa una nuova difficolt\u00e0.\u00a0<\/p>\n

Automatizziamo i test<\/h2>\n

\n\"Dagli
\n
\nGrazie all'automazione dei rilasci, i processi di sviluppo si sono accelerati, parzialmente a causa della saltazione di alcune fasi di testing. Questo ha comportato una temporanea perdita di qualit\u00e0. Sembra banale, ma insieme all'accelerazione dei rilasci era necessario cambiare anche la metodologia di sviluppo del prodotto. \u00c8 stato necessario riflettere sull'automazione dei test, sull'assegnazione della responsabilit\u00e0 personale (qui si parla di 'accettazione dell'idea nella mente', e non di multe monetarie) per il codice rilasciato e i relativi bug, cos\u00ec come sulla decisione di rilasciare o non rilasciare una task attraverso un deploy automatico.\u00a0<\/p>\n

Affrontando i problemi di qualit\u00e0, siamo giunti a due importanti decisioni: abbiamo iniziato a effettuare test canarini e abbiamo implementato il monitoraggio automatico degli errori in background con una risposta automatica al superamento di una soglia. La prima decisione ha permesso di identificare errori evidenti prima che il codice arrivasse in produzione, la seconda ha ridotto il tempo di risposta ai problemi in produzione. Gli errori, ovviamente, ci sono, ma dedichiamo la maggior parte del nostro tempo e delle nostre energie non a correggerli, bens\u00ec a minimizzarli.\u00a0<\/p>\n

Il team di automazione<\/h2>\n

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

Il team DevOps \u00e8 responsabile degli ambienti Dev\/Beta del sito CIAN, dell'ambiente Integro, aiuta gli sviluppatori nella risoluzione dei problemi e sviluppa nuove strategie per scalare gli ambienti. La direzione dello sviluppo di Integro si occupa sia di Integro stessa, sia di servizi correlati, come plugin per Jenkins, Jira, Confluence, e sviluppa anche strumenti e applicazioni di supporto per i team di sviluppatori.\u00a0<\/p>\n

Il team DI lavora a stretto contatto con il team della Piattaforma, che si occupa dello sviluppo dell'architettura, delle librerie e delle metodologie di sviluppo all'interno dell'azienda. Inoltre, qualsiasi sviluppatore all'interno di CIAN pu\u00f2 contribuire all'automazione, ad esempio, realizzando microautomazioni per le esigenze del team o condividendo idee brillanti su come migliorare ulteriormente l'automazione.<\/p>\n

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

\n\"Dagli
\n
\nTutti i sistemi coinvolti nell'automazione possono essere suddivisi in pi\u00f9 livelli:<\/p>\n

    \n
  1. Sistemi esterni (Jira, Bitbucket, ecc.). Questi sono utilizzati dai team di sviluppo.\n<\/li>\n
  2. Piattaforma Integro. Di solito, gli sviluppatori non lavorano direttamente con essa, ma \u00e8 fondamentale per il funzionamento di tutta l'automazione.\n<\/li>\n
  3. Servizi di distribuzione, orchestrazione e discovery (ad esempio, Jenkins, Consul, Nomad). Ci aiutano a distribuire il codice sui server e a garantire il corretto funzionamento dei servizi tra di loro.\n<\/li>\n
  4. Livello fisico (server, OS, software correlato). A questo livello opera il nostro codice. Pu\u00f2 trattarsi di un server fisico o virtuale (LXC, KVM, Docker).\n<\/li>\n<\/ol>\n

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

    Integro<\/h2>\n

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