{"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\/pt\/blog\/administrirovanie\/ot-skriptov-k-sobstvennoj-platforme-kak-my-avtomatizirovali-razrabotku-v-tsian","title":{"rendered":"De scripts a uma plataforma pr\u00f3pria: como automatizamos o desenvolvimento na CIAN","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"De
\n
\nNa RIT 2019, nosso colega Alexander Korotkov fez relat\u00f3rio<\/a><\/noindex> sobre automa\u00e7\u00e3o do desenvolvimento na CIAN: para simplificar a vida e o trabalho, usamos nossa pr\u00f3pria plataforma Integro. Ela rastreia o ciclo de vida das tarefas, aliviando os desenvolvedores de opera\u00e7\u00f5es rotineiras e reduzindo significativamente a quantidade de bugs em produ\u00e7\u00e3o. Neste post, complementamos a apresenta\u00e7\u00e3o de Alexander e contamos como passamos de simples scripts para a integra\u00e7\u00e3o de produtos open source por meio de nossa pr\u00f3pria plataforma e o que uma equipe separada de automa\u00e7\u00e3o faz por n\u00f3s.
\n\u00a0<\/a><\/noindex><\/p>\n

N\u00edvel zero<\/h2>\n

\n\u00abN\u00e3o existe n\u00edvel zero, eu n\u00e3o conhe\u00e7o isso\u00bb<\/b>
\nMestre Shifu do filme \u00abKung Fu Panda\u00bb<\/i><\/p>\n

A automa\u00e7\u00e3o na CIAN come\u00e7ou 14 anos ap\u00f3s a funda\u00e7\u00e3o da empresa. Na \u00e9poca, a equipe de desenvolvimento contava com 35 pessoas. Dificil acreditar, n\u00e9? Claro, de alguma forma a automa\u00e7\u00e3o existia, mas a dire\u00e7\u00e3o separada para integra\u00e7\u00e3o cont\u00ednua e entrega de c\u00f3digo come\u00e7ou a se formar precisamente em 2015.\u00a0<\/p>\n

Naquele momento, t\u00ednhamos um enorme mon\u00f3lito em Python, C# e PHP, implantado em servidores Linux\/Windows. Para implantar esse monstro, t\u00ednhamos um conjunto de scripts que execut\u00e1vamos manualmente. Tamb\u00e9m havia a constru\u00e7\u00e3o do mon\u00f3lito, causando dor e sofrimento devido a conflitos de mesclagem, corre\u00e7\u00e3o de defeitos e recompila\u00e7\u00e3o 'com um conjunto diferente de tarefas no build'. Simplificadamente, o processo parecia assim:<\/p>\n

\"De
\n
\nIsso n\u00e3o nos satisfazia, e quer\u00edamos construir um processo de constru\u00e7\u00e3o e implanta\u00e7\u00e3o repet\u00edvel, automatizado e gerenciado. Para isso, precis\u00e1vamos de um sistema CI\/CD e est\u00e1vamos escolhendo entre a vers\u00e3o gratuita do Teamcity e o Jenkins gratuito, pois j\u00e1 trabalh\u00e1vamos com ambos e ambos nos davam suporte em termos de funcionalidades. Escolhemos o Teamcity por ser um produto mais recente. Naquela \u00e9poca, ainda n\u00e3o us\u00e1vamos uma arquitetura de microsservi\u00e7os e n\u00e3o esper\u00e1vamos um grande n\u00famero de tarefas e projetos.<\/p>\n

Chegamos \u00e0 ideia de um sistema pr\u00f3prio<\/h2>\n

\nA implementa\u00e7\u00e3o do Teamcity eliminou apenas parte do trabalho manual: ainda era necess\u00e1rio criar Pull Requests, avan\u00e7ar tarefas pelos status no Jira e escolher tarefas para o lan\u00e7amento. A sistema Teamcity n\u00e3o conseguia mais lidar com isso. Era necess\u00e1rio escolher um caminho de automa\u00e7\u00e3o adicional. Consideramos op\u00e7\u00f5es de trabalhar com scripts no Teamcity ou mudar para sistemas de automa\u00e7\u00e3o de terceiros. Mas, no final, decidimos que precis\u00e1vamos da m\u00e1xima flexibilidade, que s\u00f3 uma solu\u00e7\u00e3o interna poderia oferecer. Assim surgiu a primeira vers\u00e3o do sistema interno de automa\u00e7\u00e3o chamado Integro.<\/p>\n

Teamcity foca na automa\u00e7\u00e3o ao n\u00edvel de iniciar processos de constru\u00e7\u00e3o e implanta\u00e7\u00e3o, enquanto o Integro se concentrou na automa\u00e7\u00e3o de alto n\u00edvel dos processos de desenvolvimento. Era necess\u00e1rio integrar o trabalho com tarefas no Jira e o processamento do c\u00f3digo fonte relacionado no Bitbucket. Nesta fase, o Integro come\u00e7ou a desenvolver seus pr\u00f3prios fluxos de trabalho para lidar com tarefas de diferentes tipos.\u00a0<\/p>\n

Devido ao aumento da automa\u00e7\u00e3o nos processos de neg\u00f3cios, o n\u00famero de projetos e execu\u00e7\u00f5es no Teamcity cresceu. Assim, surgiu um novo problema: uma inst\u00e2ncia gratuita do Teamcity n\u00e3o era mais suficiente (3 agentes e 100 projetos), adicionamos mais uma inst\u00e2ncia (mais 3 agentes e 100 projetos) e depois mais uma. No final, conseguimos um sistema com v\u00e1rios clusters, o que tornou a gest\u00e3o complicada:<\/p>\n

\"De
\n
\nQuando surgiu a quest\u00e3o de uma quarta inst\u00e2ncia, percebemos que n\u00e3o poder\u00edamos continuar assim, pois os custos totais para manter 4 inst\u00e2ncias j\u00e1 estavam insustent\u00e1veis. Surgiu a d\u00favida de comprar o Teamcity pago ou optar pelo Jenkins gratuito. Fizemos c\u00e1lculos sobre as inst\u00e2ncias e planos de automa\u00e7\u00e3o e decidimos que ir\u00edamos trabalhar com Jenkins. Ap\u00f3s algumas semanas, migramos para o Jenkins e aliviamos parte da dor de cabe\u00e7a relacionada \u00e0 manuten\u00e7\u00e3o de v\u00e1rias inst\u00e2ncias do Teamcity. Isso nos permitiu focar no desenvolvimento do Integro e na adapta\u00e7\u00e3o do Jenkins para nossas necessidades.<\/p>\n

Com o aumento da automa\u00e7\u00e3o b\u00e1sica (na forma de cria\u00e7\u00e3o autom\u00e1tica de Pull Requests, coleta e publica\u00e7\u00e3o de cobertura de c\u00f3digo e outras verifica\u00e7\u00f5es), surgiu um forte desejo de eliminar ao m\u00e1ximo os lan\u00e7amentos manuais e entregar esse trabalho aos rob\u00f4s. Al\u00e9m disso, dentro da empresa, come\u00e7amos a migra\u00e7\u00e3o para microservi\u00e7os, que exigiam lan\u00e7amentos frequentes, e feitos separadamente. Assim, gradualmente chegamos aos lan\u00e7amentos autom\u00e1ticos de nossos microservi\u00e7os (o monolito ainda \u00e9 lan\u00e7ado manualmente devido \u00e0 complexidade do processo). Mas, como costuma acontecer, surgiu uma nova dificuldade.\u00a0<\/p>\n

Automatizamos os testes<\/h2>\n

\n\"De
\n
\nDevido \u00e0 automa\u00e7\u00e3o dos lan\u00e7amentos, os processos de desenvolvimento foram acelerados, parcialmente em fun\u00e7\u00e3o da omiss\u00e3o de algumas etapas de teste. Isso resultou em uma perda tempor\u00e1ria de qualidade. Pode soar banal, mas junto com a acelera\u00e7\u00e3o dos lan\u00e7amentos, t\u00ednhamos que mudar tamb\u00e9m a metodologia de desenvolvimento do produto. Era necess\u00e1rio pensar na automa\u00e7\u00e3o dos testes, no refor\u00e7o da responsabilidade pessoal (aqui falamos sobre \"aceitar a ideia na mente\", e n\u00e3o sobre multas financeiras) do desenvolvedor pelo c\u00f3digo produzido e pelos bugs nele, al\u00e9m de uma decis\u00e3o sobre a libera\u00e7\u00e3o\/n\u00e3o libera\u00e7\u00e3o das tarefas por meio do deploy autom\u00e1tico.\u00a0<\/p>\n

Ao resolver problemas de qualidade, chegamos a duas decis\u00f5es importantes: come\u00e7amos a realizar testes can\u00e1rios e implementamos monitoramento autom\u00e1tico de erros em segundo plano com resposta autom\u00e1tica quando os limites s\u00e3o excedidos. A primeira decis\u00e3o permitiu detectar erros \u00f3bvios antes que o c\u00f3digo chegasse \u00e0 produ\u00e7\u00e3o, enquanto a segunda reduziu o tempo de resposta a problemas na produ\u00e7\u00e3o. Erros, claro, acontecem, mas gastamos a maior parte do tempo e esfor\u00e7o n\u00e3o na corre\u00e7\u00e3o, mas na minimiza\u00e7\u00e3o.\u00a0<\/p>\n

Equipe de automa\u00e7\u00e3o<\/h2>\n

\nAtualmente, temos uma equipe de 130 desenvolvedores, e continuamos crescendo<\/a><\/noindex>. A equipe de integra\u00e7\u00e3o e entrega cont\u00ednua de c\u00f3digo (daqui em diante \u2014 equipe Deploy e Integra\u00e7\u00e3o ou DI) \u00e9 composta por 7 pessoas e trabalha em 2 frentes: desenvolvimento da plataforma de automa\u00e7\u00e3o Integro e DevOps.\u00a0<\/p>\n

DevOps \u00e9 respons\u00e1vel pelos ambientes Dev\/Beta do site CIAN, ambientes Integro, ajuda os desenvolvedores a resolver problemas e desenvolve novas abordagens para escalonamento de ambientes. A \u00e1rea de desenvolvimento Integro lida tanto com a Integro em si quanto com servi\u00e7os relacionados, como plugins para Jenkins, Jira, Confluence, al\u00e9m de desenvolver utilit\u00e1rios e aplicativos auxiliares para equipes de desenvolvedores.\u00a0<\/p>\n

A equipe DI trabalha em conjunto com a equipe de Plataforma, que lida com o desenvolvimento da arquitetura, bibliotecas e abordagens de desenvolvimento dentro da empresa. Al\u00e9m disso, qualquer desenvolvedor dentro da CIAN pode contribuir para a automa\u00e7\u00e3o, por exemplo, criando microautoma\u00e7\u00e3o para atender \u00e0s necessidades da equipe ou compartilhando uma ideia legal de como melhorar ainda mais a automa\u00e7\u00e3o.<\/p>\n

Camadas de automa\u00e7\u00e3o na CIAN<\/h2>\n

\n\"De
\n
\nTodos os sistemas envolvidos na automa\u00e7\u00e3o podem ser divididos em v\u00e1rias camadas:<\/p>\n

    \n
  1. Sistemas externos (Jira, Bitbucket, etc.). Eles s\u00e3o utilizados pelas equipes de desenvolvimento.\n<\/li>\n
  2. Plataforma Integro. Na maioria das vezes, os desenvolvedores n\u00e3o interagem diretamente com ela, mas \u00e9 ela que suporta a opera\u00e7\u00e3o de toda a automa\u00e7\u00e3o.\n<\/li>\n
  3. Servi\u00e7os de entrega, orquestra\u00e7\u00e3o e descoberta (como Jenkins, Consul, Nomad). Com eles, implantamos o c\u00f3digo nos servidores e garantimos a opera\u00e7\u00e3o conjunta dos servi\u00e7os.\n<\/li>\n
  4. N\u00edvel f\u00edsico (servidores, SO, software relacionado). \u00c9 neste n\u00edvel que nosso c\u00f3digo opera. Isso pode ser em um servidor f\u00edsico ou virtual (LXC, KVM, Docker).\n<\/li>\n<\/ol>\n

    \nCom base neste conceito, dividimos as zonas de responsabilidade dentro da equipe DI. Os dois primeiros n\u00edveis est\u00e3o sob a responsabilidade da \u00e1rea de desenvolvimento Integro, enquanto os dois \u00faltimos n\u00edveis ficam sob a responsabilidade do DevOps. Essa divis\u00e3o permite focar nas tarefas e n\u00e3o interfere na intera\u00e7\u00e3o, uma vez que estamos pr\u00f3ximos uns dos outros e constantemente trocamos conhecimentos e experi\u00eancias.<\/p>\n

    Integro<\/h2>\n

    \nVamos focar na Integro e come\u00e7ar pela pilha tecnol\u00f3gica:<\/p>\n