{"id":93885,"date":"2020-09-10T19:42:23","date_gmt":"2020-09-10T17:42:23","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/continuous-integration-kak-praktika-a-ne-jenkins-andrej-aleksandrov"},"modified":"2020-09-10T19:42:23","modified_gmt":"2020-09-10T17:42:23","slug":"continuous-integration-kak-praktika-a-ne-jenkins-andrej-aleksandrov","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/continuous-integration-kak-praktika-a-ne-jenkins-andrej-aleksandrov","title":{"rendered":"Integra\u00e7\u00e3o Cont\u00ednua como pr\u00e1tica, e n\u00e3o Jenkins. Andrey Alexandrov","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Integra\u00e7\u00e3o<\/p>\n

<\/p>\n

Vamos discutir por que ferramentas de CI e CI s\u00e3o coisas bem diferentes.<\/p>\n

<\/p>\n

Qual dor o CI pretende resolver, de onde surgiu a ideia, quais as \u00faltimas evid\u00eancias de que funciona, como entender se voc\u00ea tem uma pr\u00e1tica real e n\u00e3o apenas um Jenkins instalado.<\/p>\n

<\/a><\/noindex><\/p>\n

A ideia de fazer uma apresenta\u00e7\u00e3o sobre Integra\u00e7\u00e3o Cont\u00ednua surgiu h\u00e1 um ano, quando estava em entrevistas em busca de emprego. Falei com 10-15 empresas, e apenas uma conseguiu explicar claramente o que \u00e9 CI e como percebeu que n\u00e3o o tinha. As outras falavam coisas sem sentido sobre Jenkins \ud83d\ude42 Bem, temos Jenkins, ele faz compila\u00e7\u00f5es, CI! Na apresenta\u00e7\u00e3o, tentarei explicar o que realmente \u00e9 Integra\u00e7\u00e3o Cont\u00ednua e por que Jenkins e ferramentas semelhantes t\u00eam rela\u00e7\u00e3o muito fraca com isso.<\/p>\n

<\/p>\n

\"Integra\u00e7\u00e3o<\/p>\n

<\/p>\n

E ent\u00e3o, o que normalmente vem \u00e0 mente ao ouvir a palavra CI? A maioria das pessoas pensar\u00e1 em Jenkins, Gitlab CI, Travis, etc.<\/p>\n

<\/p>\n

\"Integra\u00e7\u00e3o<\/p>\n

<\/p>\n

Mesmo se fizermos uma busca, esses ferramentas aparecer\u00e3o.<\/p>\n

<\/p>\n

\"Integra\u00e7\u00e3o<\/p>\n

<\/p>\n

Se voc\u00ea perguntar a algu\u00e9m, logo ap\u00f3s listar as ferramentas, eles dir\u00e3o que CI \u00e9 quando sua Pull Request em um commit dispara uma compila\u00e7\u00e3o e a execu\u00e7\u00e3o de testes.<\/p>\n

<\/p>\n

\"Integra\u00e7\u00e3o<\/p>\n

<\/p>\n

Integra\u00e7\u00e3o Cont\u00ednua n\u00e3o \u00e9 sobre ferramentas, n\u00e3o \u00e9 sobre compila\u00e7\u00f5es com testes em uma branch! Integra\u00e7\u00e3o Cont\u00ednua \u00e9 a pr\u00e1tica de integrar c\u00f3digo novo com muita frequ\u00eancia e para isso n\u00e3o \u00e9 necess\u00e1rio criar Jenkins, GitLab, etc.<\/p>\n

<\/p>\n

\"Integra\u00e7\u00e3o<\/p>\n

<\/p>\n

Antes de entendermos como \u00e9 um CI pleno, vamos primeiro nos aprofundar no contexto das pessoas que o criaram e sentir a dor que estavam tentando resolver.<\/p>\n

<\/p>\n

\"Integra\u00e7\u00e3o<\/p>\n

<\/p>\n

E a dor que resolveram foi a da colabora\u00e7\u00e3o em equipe!<\/p>\n

<\/p>\n

\"Integra\u00e7\u00e3o<\/p>\n

<\/p>\n

Vamos olhar exemplos das dificuldades que os desenvolvedores enfrentam ao trabalhar em equipe. Aqui temos um projeto, a branch master no git e dois desenvolvedores.<\/p>\n

<\/p>\n

\"Integra\u00e7\u00e3o<\/p>\n

<\/p>\n

E eles come\u00e7aram a trabalhar como todos j\u00e1 est\u00e3o acostumados. Pegaram uma tarefa no Jira, criaram uma feature branch e come\u00e7aram a escrever c\u00f3digo.<\/p>\n

<\/p>\n

\"Integra\u00e7\u00e3o<\/p>\n

<\/p>\n

Um terminou a feature mais r\u00e1pido e fez o merge na master.<\/p>\n

<\/p>\n

\"Integra\u00e7\u00e3o<\/p>\n

<\/p>\n

O outro levou mais tempo, fez o merge depois e encontrou um conflito. Agora, em vez de escrever as features necess\u00e1rias para o neg\u00f3cio, o desenvolvedor gasta seu tempo e esfor\u00e7o resolvendo conflitos.<\/p>\n

<\/p>\n

\"Integra\u00e7\u00e3o<\/p>\n

<\/p>\n

Quanto mais complicado for unir sua funcionalidade ao reposit\u00f3rio principal, mais tempo gastaremos com isso. E este \u00e9 apenas um exemplo bastante simples. Imagine se houver 10, 15 ou at\u00e9 100 pessoas na empresa contribuindo para um \u00fanico reposit\u00f3rio. Voc\u00ea enlouqueceria tentando resolver todos esses conflitos. <\/p>\n

<\/p>\n

\"Integra\u00e7\u00e3o<\/p>\n

<\/p>\n

H\u00e1 um caso um pouco diferente. Temos um reposit\u00f3rio principal e v\u00e1rios desenvolvedores que est\u00e3o fazendo algo.<\/p>\n

<\/p>\n

\"Integra\u00e7\u00e3o<\/p>\n

<\/p>\n

Eles criaram um branch cada um.<\/p>\n

<\/p>\n

\"Integra\u00e7\u00e3o<\/p>\n

<\/p>\n

Um deles fez o merge, tudo certo, completou a tarefa.<\/p>\n

<\/p>\n

\"Integra\u00e7\u00e3o<\/p>\n

<\/p>\n

O segundo desenvolvedor, enquanto isso, completou sua tarefa. Suponha que ele a tenha enviado para revis\u00e3o. Em muitas empresas, existe a pr\u00e1tica de revis\u00e3o. Por um lado, essa pr\u00e1tica \u00e9 boa e \u00fatil, mas, por outro, pode nos atrasar em muitos aspectos. N\u00e3o vamos nos aprofundar nisso, mas aqui est\u00e1 um \u00f3timo exemplo do que pode ocorrer com uma hist\u00f3ria problem\u00e1tica de revis\u00e3o. Voc\u00ea submeteu um pull request para revis\u00e3o. O desenvolvedor n\u00e3o tem mais nada a fazer. O que ele come\u00e7a a fazer? Ele come\u00e7a a pegar outras tarefas. <\/p>\n

<\/p>\n

\"Integra\u00e7\u00e3o<\/p>\n

<\/p>\n

Durante esse tempo, o segundo desenvolvedor fez mais alguma coisa. <\/p>\n

<\/p>\n

\"Integra\u00e7\u00e3o<\/p>\n

<\/p>\n

O primeiro completou a terceira tarefa. <\/p>\n

<\/p>\n

\"Integra\u00e7\u00e3o<\/p>\n

<\/p>\n

E ap\u00f3s um tempo consider\u00e1vel, sua revis\u00e3o foi testada, e ele tenta fazer o merge. E o que acontece? Ele encontra uma enorme quantidade de conflitos. Por qu\u00ea? Porque enquanto seu pull request ficou pendente de revis\u00e3o, o c\u00f3digo j\u00e1 foi alterado significativamente. <\/p>\n

<\/p>\n

Al\u00e9m do problema dos conflitos, h\u00e1 tamb\u00e9m o problema das comunica\u00e7\u00f5es. Enquanto voc\u00ea tem um branch pendente de revis\u00e3o, enquanto ele est\u00e1 esperando, enquanto voc\u00ea leva um tempo consider\u00e1vel para finalizar a funcionalidade, voc\u00ea para de acompanhar o que mais est\u00e1 mudando na base de c\u00f3digo do seu servi\u00e7o. Pode ser que o que voc\u00ea est\u00e1 tentando resolver j\u00e1 tenha sido resolvido ontem, e voc\u00ea poderia reutilizar algum m\u00e9todo. Mas voc\u00ea n\u00e3o ver\u00e1 isso, porque sempre estar\u00e1 trabalhando com um branch desatualizado. E esse branch desatualizado sempre resulta em voc\u00ea ter que resolver um conflito de merge. <\/p>\n

<\/p>\n

Portanto, se estamos trabalhando em equipe, ou seja, n\u00e3o apenas uma pessoa mexendo no reposit\u00f3rio, mas sim de 5 a 10 pessoas, quanto mais tempo demoramos para adicionar nosso c\u00f3digo ao reposit\u00f3rio principal, mais sofremos com a necessidade de fazer um merge no final. E quanto mais conflitos houver, e quanto mais antiga for a vers\u00e3o com a qual estamos trabalhando, mais problemas teremos.<\/p>\n

<\/p>\n

\"Integra\u00e7\u00e3o<\/p>\n

<\/p>\n

Trabalhar em conjunto \u00e9 doloroso! Sempre estamos atrapalhando uns aos outros. <\/p>\n

<\/p>\n

\"Integra\u00e7\u00e3o<\/p>\n

<\/p>\n

Esse problema foi notado h\u00e1 mais de 20 anos. A primeira men\u00e7\u00e3o \u00e0 pr\u00e1tica de Integra\u00e7\u00e3o Cont\u00ednua que encontrei foi na programa\u00e7\u00e3o extrema.<\/p>\n

<\/p>\n

Programa\u00e7\u00e3o extrema \u00e9 o primeiro framework \u00e1gil. A p\u00e1gina foi criada em 1996. A ideia era usar algumas pr\u00e1ticas de programa\u00e7\u00e3o, planejamento e outras coisas para que o desenvolvimento fosse o mais flex\u00edvel poss\u00edvel, para que pud\u00e9ssemos reagir mais rapidamente a mudan\u00e7as e requisitos de nossos clientes. E h\u00e1 24 anos, come\u00e7aram a perceber que, se voc\u00ea faz algo por muito tempo \u00e0 parte, gasta mais tempo com isso devido a conflitos. <\/p>\n

<\/p>\n

\"Integra\u00e7\u00e3o<\/p>\n

<\/p>\n

Agora vamos analisar a express\u00e3o \"Integra\u00e7\u00e3o Cont\u00ednua\" palavra por palavra. Se traduzirmos literalmente, \u00e9 integra\u00e7\u00e3o cont\u00ednua. Mas o qu\u00e3o cont\u00ednua ela \u00e9 n\u00e3o est\u00e1 muito claro, ela \u00e9, na verdade, bastante intermitente. E o quanto ela \u00e9 uma integra\u00e7\u00e3o tamb\u00e9m n\u00e3o \u00e9 muito \u00f3bvio. <\/p>\n

<\/p>\n

E por isso trago agora cita\u00e7\u00f5es da programa\u00e7\u00e3o extrema. Vamos analisar as duas palavras separadamente. <\/p>\n

<\/p>\n

Integra\u00e7\u00e3o \u2014 Como j\u00e1 mencionei, buscamos que cada engenheiro trabalhe com a vers\u00e3o mais atual do c\u00f3digo, para que ele adicione seu c\u00f3digo o mais frequentemente poss\u00edvel \u00e0 branch principal, para que sejam pequenas branches. Porque se forem grandes, podemos facilmente ficar presos por uma semana com conflitos de merge. Especialmente se estivermos em um ciclo de desenvolvimento longo, como o waterfall, onde o desenvolvedor foi trabalhar por um m\u00eas em algum enorme recurso. E, no est\u00e1gio de integra\u00e7\u00e3o, pode ficar preso por muito tempo. <\/p>\n

<\/p>\n

Integra\u00e7\u00e3o \u2014 \u00e9 quando pegamos nossa branch e a integramos ao master, fazemos o merge. H\u00e1 uma variante suprema, quando habilitamos o desenvolvedor transbase, onde buscamos que escrevamos direto no master sem branches desnecess\u00e1rias.<\/p>\n

<\/p>\n

Em resumo, a integra\u00e7\u00e3o \u00e9 pegar seu c\u00f3digo e lev\u00e1-lo para o master. <\/p>\n

<\/p>\n

\"Integra\u00e7\u00e3o<\/p>\n

<\/p>\n

O que se entende por \"continuous\" aqui, o que \u00e9 continuidade? A pr\u00e1tica implica que o desenvolvedor busca integrar seu c\u00f3digo o mais r\u00e1pido poss\u00edvel. Esse \u00e9 seu objetivo ao executar qualquer tarefa - fazer com que seu c\u00f3digo apare\u00e7a no mestre o mais r\u00e1pido poss\u00edvel. Em um mundo ideal, os desenvolvedores fariam isso a cada poucas horas. Ou seja, voc\u00ea pega uma pequena tarefa, mescla-a no mestre. Tudo \u00f3timo. Voc\u00ea almeja isso. E deve fazer isso continuamente. Assim que voc\u00ea faz algo, voc\u00ea imediatamente o insere no mestre. <\/p>\n

<\/p>\n

E o desenvolvedor que faz algo \u00e9 respons\u00e1vel pelo que ele fez, garantindo que funcione e que nada seja quebrado. Aqui geralmente surge a quest\u00e3o dos testes. Queremos executar alguns testes em nosso commit, em nosso merge, para garantir que tudo funcione. E \u00e9 aqui que o Jenkins pode ajudar.<\/p>\n

<\/p>\n

Mas com as hist\u00f3rias: vamos fazer as mudan\u00e7as pequenas, vamos fazer as tarefas pequenas, e vamos tentar fazer a tarefa e imediatamente integr\u00e1-la no mestre - aqui nenhum Jenkins vai ajudar. Porque o Jenkins vai te ajudar exclusivamente a executar os testes. <\/p>\n

<\/p>\n

Voc\u00ea pode se virar sem eles. Isso n\u00e3o vai te atrapalhar em nada. Porque o objetivo da pr\u00e1tica \u00e9 mesclarse o mais frequentemente poss\u00edvel, para n\u00e3o gastar uma quantidade enorme de tempo em conflitos futuros. <\/p>\n

<\/p>\n

Vamos imaginar que estamos no ano de 2020, mas por algum motivo estamos sem internet. E estamos trabalhando localmente. N\u00e3o temos Jenkins. Isso \u00e9 normal. Voc\u00ea ainda pode criar uma branch local. Voc\u00ea escreveu algum c\u00f3digo nela. Fez uma tarefa em 3-4 horas. Mudou para o mestre, fez git pull, mesclou sua branch. Pronto. Se voc\u00ea fizer isso frequentemente \u2013 parab\u00e9ns, voc\u00ea tem Integra\u00e7\u00e3o Cont\u00ednua!<\/p>\n

<\/p>\n

\"Integra\u00e7\u00e3o<\/p>\n

<\/p>\n

Quais s\u00e3o as evid\u00eancias no mundo moderno de que vale a pena investir esfor\u00e7o nisso? Porque, no geral, \u00e9 complexo. Se voc\u00ea tentar trabalhar assim, vai perceber que isso envolve algum planejamento, e voc\u00ea precisar\u00e1 dedicar mais tempo \u00e0 decomposi\u00e7\u00e3o das tarefas. Porque se voc\u00ea for fazer man..., n\u00e3o conseguir\u00e1 se mesclar rapidamente e, consequentemente, acabar\u00e1 em apuros. Voc\u00ea n\u00e3o ter\u00e1 mais as pr\u00e1ticas. <\/p>\n

<\/p>\n

E isso ser\u00e1 caro. N\u00e3o ser\u00e1 poss\u00edvel trabalhar a partir de amanh\u00e3 em Continuous Integration. Todos voc\u00eas v\u00e3o demorar muito para se acostumar, v\u00e3o levar muito tempo para aprender a decompor tarefas, e v\u00e3o levar muito tempo para se acostumar a refazer a pr\u00e1tica de revis\u00e3o, se \u00e9 que a t\u00eam. Porque nosso objetivo \u00e9 que o merge aconte\u00e7a hoje. E se voc\u00eas fazem a revis\u00e3o ao longo de tr\u00eas dias, ent\u00e3o voc\u00eas t\u00eam problemas e o Continuous Integration n\u00e3o funciona. <\/p>\n

<\/p>\n

Mas temos algumas evid\u00eancias atuais que nos dizem que vale a pena investir nessa pr\u00e1tica?<\/p>\n

<\/p>\n

\"Integra\u00e7\u00e3o<\/p>\n

<\/p>\n

A primeira coisa que me veio \u00e0 mente foi o State of DevOps. \u00c9 uma pesquisa que a equipe realiza h\u00e1 7 anos. Atualmente, eles fazem isso como uma organiza\u00e7\u00e3o independente, mas sob o Google.<\/p>\n

<\/p>\n

E a pesquisa deles, em 2018, mostrou uma correla\u00e7\u00e3o entre empresas que tentam usar branches de curta dura\u00e7\u00e3o, que se integram rapidamente e com frequ\u00eancia; elas t\u00eam indicadores de desempenho de TI muito melhores.<\/p>\n

<\/p>\n

Quais s\u00e3o esses indicadores? S\u00e3o 4 m\u00e9tricas que eles coletam de todas as empresas em seus question\u00e1rios: frequ\u00eancia de deploy, tempo para mudan\u00e7as, tempo para restaurar o servi\u00e7o e taxa de falhas nas mudan\u00e7as.<\/p>\n

<\/p>\n

E, em primeiro lugar, h\u00e1 essa correla\u00e7\u00e3o; sabemos que as empresas que fazem merges frequentemente t\u00eam m\u00e9tricas muito melhores. Eles dividem as empresas em v\u00e1rias categorias: empresas lentas, que produzem algo lentamente, performers medianos, high performers e a elite. A elite \u00e9 composta por Netflix, Amazon, que s\u00e3o super \u00e1geis, fazem tudo rapidamente, de forma bonita e com qualidade.<\/p>\n

<\/p>\n

\"Integra\u00e7\u00e3o<\/p>\n

<\/p>\n

A segunda hist\u00f3ria aconteceu literalmente h\u00e1 um m\u00eas. No Technology Radar, surgiu uma nota maravilhosa sobre o Gitflow. O Gitflow se diferencia dos outros por ter branches que vivem por um longo tempo. Existem branches de release que duram muito, e branches de features que tamb\u00e9m vivem muito. Essa pr\u00e1tica no Technology Radar foi movida para HOLD. Por qu\u00ea? Porque as pessoas enfrentam a dor da integra\u00e7\u00e3o. <\/p>\n

<\/p>\n

Se voc\u00ea tem uma branch que vive muito tempo, ela acaba se estragando, e come\u00e7amos a gastar mais tempo para fazer alguma mudan\u00e7a nela. <\/p>\n

<\/p>\n

E recentemente, o autor do Gitflow disse que se voc\u00ea est\u00e1 buscando a Integra\u00e7\u00e3o Cont\u00ednua, se deseja integrar com a maior frequ\u00eancia poss\u00edvel, ent\u00e3o o Gitflow \u00e9 uma m\u00e1 ideia. Ele acrescentou em um artigo que se voc\u00ea tem um backend onde pode se esfor\u00e7ar para isso, o Gitflow \u00e9 desnecess\u00e1rio, pois o Gitflow vai desaceler\u00e1-lo e criar problemas de integra\u00e7\u00e3o. <\/p>\n

<\/p>\n

Isso n\u00e3o significa que o Gitflow seja ruim e que n\u00e3o deva ser utilizado. Ele \u00e9 para outros casos. Por exemplo, quando voc\u00ea precisa suportar v\u00e1rias vers\u00f5es de um servi\u00e7o ou aplicativo, ou seja, quando \u00e9 preciso dar suporte por um per\u00edodo prolongado. <\/p>\n

<\/p>\n

Mas se voc\u00ea conversar com pessoas que sustentam tais servi\u00e7os, ouvir\u00e1 muitas queixas sobre como essa vers\u00e3o era 3.2, que foi lan\u00e7ada h\u00e1 4 meses, e que essa corre\u00e7\u00e3o n\u00e3o foi inclu\u00edda. Agora, para integr\u00e1-la, \u00e9 necess\u00e1rio fazer uma por\u00e7\u00e3o de altera\u00e7\u00f5es. E ent\u00e3o eles ficam presos novamente, passando uma semana tentando mesclar uma nova funcionalidade. <\/p>\n

<\/p>\n

Como Alexander Kovalev corretamente observou no chat, correla\u00e7\u00e3o n\u00e3o \u00e9 o mesmo que causalidade. \u00c9 isso mesmo. Ou seja, n\u00e3o h\u00e1 uma rela\u00e7\u00e3o direta de que se voc\u00ea tem Integra\u00e7\u00e3o Cont\u00ednua, todas as m\u00e9tricas ser\u00e3o \u00f3timas. Mas h\u00e1 uma correla\u00e7\u00e3o positiva, onde se um existe, o outro provavelmente tamb\u00e9m existe. N\u00e3o \u00e9 uma certeza, mas \u00e9 prov\u00e1vel. \u00c9 apenas uma correla\u00e7\u00e3o. <\/p>\n

<\/p>\n

\"Integra\u00e7\u00e3o<\/p>\n

<\/p>\n

Parece que j\u00e1 estamos fazendo algo, parece que estamos mesclando, mas como saber se realmente temos Integra\u00e7\u00e3o Cont\u00ednua, que estamos mesclando com frequ\u00eancia suficiente?<\/p>\n

<\/p>\n

Jez Humble \u00e9 o autor do Handbook, Accelerate, do site Continuous Delivery e do livro \"Continuous Delivery\". Ele prop\u00f5e o seguinte teste:<\/p>\n

<\/p>\n