{"id":32526,"date":"2019-10-31T21:47:32","date_gmt":"2019-10-31T18:47:32","guid":{"rendered":"https:\/\/prohoster.info\/blog\/protsess-razrabotki-i-testirovaniya-s-docker-i-gitlab-ci\/"},"modified":"2019-10-31T21:47:32","modified_gmt":"2019-10-31T18:47:32","slug":"protsess-razrabotki-i-testirovaniya-s-docker-i-gitlab-ci","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/protsess-razrabotki-i-testirovaniya-s-docker-i-gitlab-ci","title":{"rendered":"Processo de Desenvolvimento e Teste com Docker e Gitlab CI","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Convido a conhecer a transcri\u00e7\u00e3o do relat\u00f3rio de Alexander Sigachev da Inventos \"Processo de desenvolvimento e teste com Docker + Gitlab CI\"<\/strong><\/p>\n

<\/p>\n

Aqueles que est\u00e3o apenas come\u00e7ando a implementar o processo de desenvolvimento e teste baseado em Docker + Gitlab CI costumam fazer perguntas b\u00e1sicas. Por onde come\u00e7ar? Como organizar? Como testar?<\/p>\n

<\/p>\n

Esta apresenta\u00e7\u00e3o \u00e9 boa porque explica de maneira estruturada o processo de desenvolvimento e teste utilizando Docker e Gitlab CI. A pr\u00f3pria apresenta\u00e7\u00e3o \u00e9 de 2017. Acredito que dela podemos extrair fundamentos, metodologias, ideias e experi\u00eancias de uso. <\/p>\n

\n

\r\n \"Por\r\n
<\/div>\r\n <\/div><\/center><\/p>\n

Para quem est\u00e1 interessado, convido a continuar lendo. <\/a><\/noindex><\/p>\n

<\/p>\n

Meu nome \u00e9 Alexander Sigachev. Trabalho na empresa Inventos. Vou compartilhar minha experi\u00eancia com o Docker e como estamos progressivamente implementando em nossos projetos.<\/p>\n

<\/p>\n

Tema da apresenta\u00e7\u00e3o: O Processo de Desenvolvimento com Docker e Gitlab CI. <\/p>\n

<\/p>\n

\"Processo<\/p>\n

<\/p>\n

Esta \u00e9 a minha segunda apresenta\u00e7\u00e3o sobre Docker. Na \u00e9poca da primeira apresenta\u00e7\u00e3o, us\u00e1vamos Docker apenas em Development nas m\u00e1quinas dos desenvolvedores. O n\u00famero de funcion\u00e1rios que utilizavam Docker era de cerca de 2-3 pessoas. Gradualmente, acumulamos experi\u00eancia e avan\u00e7amos um pouco mais. Link para nossa primeira apresenta\u00e7\u00e3o<\/a><\/noindex>.<\/p>\n

<\/p>\n

O que ser\u00e1 abordado nesta apresenta\u00e7\u00e3o? Vamos compartilhar nossa experi\u00eancia sobre os desafios que encontramos e como resolvemos cada problema. Nem tudo foi perfeito, mas nos permitiu avan\u00e7ar.<\/p>\n

<\/p>\n

Nosso lema: dockerize tudo que nossas m\u00e3os alcan\u00e7am.<\/p>\n

<\/p>\n

\"Processo<\/p>\n

<\/p>\n

Quais problemas estamos resolvendo?<\/p>\n

<\/p>\n

Quando h\u00e1 v\u00e1rias equipes na empresa, o programador se torna um recurso compartilhado. Existem momentos em que o programador \u00e9 retirado de um projeto e alocado temporariamente em outro.<\/p>\n

<\/p>\n

Para que o programador consiga se adaptar rapidamente, \u00e9 necess\u00e1rio que ele fa\u00e7a o download do c\u00f3digo-fonte do projeto e inicie o ambiente o mais r\u00e1pido poss\u00edvel, o que permitir\u00e1 que ele siga avan\u00e7ando nas tarefas daquele projeto.<\/p>\n

<\/p>\n

Em geral, se come\u00e7armos do zero, a documenta\u00e7\u00e3o do projeto \u00e9 escassa. As informa\u00e7\u00f5es sobre como configurar est\u00e3o dispon\u00edveis apenas para os veteranos. Os funcion\u00e1rios configuram seu ambiente de trabalho em um ou dois dias. Para acelerar isso, utilizamos o Docker.<\/p>\n

<\/p>\n

A pr\u00f3xima raz\u00e3o \u00e9 a padroniza\u00e7\u00e3o das configura\u00e7\u00f5es em Desenvolvimento. Pela minha experi\u00eancia, os desenvolvedores sempre tomam a iniciativa. Em um caso a cada cinco, um dom\u00ednio personalizado \u00e9 introduzido, como vasya.dev. Ao lado, est\u00e1 o vizinho Petya, que tem o dom\u00ednio petya.dev. Eles est\u00e3o desenvolvendo um site ou algum componente do sistema, usando esse nome de dom\u00ednio.<\/p>\n

<\/p>\n

Quando o sistema se expande e esses nomes de dom\u00ednio come\u00e7am a aparecer nas configura\u00e7\u00f5es, ocorre um conflito nos ambientes de Desenvolvimento e o caminho do site \u00e9 reescrito.<\/p>\n

<\/p>\n

A mesma coisa acontece com as configura\u00e7\u00f5es do banco de dados. Algu\u00e9m n\u00e3o se preocupa com a seguran\u00e7a e trabalha com a senha root vazia. Em outro caso, durante a instala\u00e7\u00e3o, o MySQL pediu uma senha e a senha era apenas 123. Muitas vezes ocorre que as configura\u00e7\u00f5es do banco de dados mudam constantemente, dependendo do commit do desenvolvedor. Algu\u00e9m corrigiu, algu\u00e9m n\u00e3o corrigiu a configura\u00e7\u00e3o. Havia estrat\u00e9gias em que n\u00f3s externaliz\u00e1vamos alguma configura\u00e7\u00e3o de teste para .gitignore<\/code> e cada desenvolvedor tinha que instalar o banco de dados. Isso complicava o processo de in\u00edcio. Al\u00e9m de tudo, \u00e9 preciso lembrar do banco de dados. O banco de dados precisa ser inicializado, \u00e9 necess\u00e1rio definir a senha, definir o usu\u00e1rio, criar a tabela e assim por diante.<\/p>\n

<\/p>\n

Outro problema \u00e9 as diferentes vers\u00f5es das bibliotecas. Muitas vezes, o desenvolvedor trabalha em diferentes projetos. H\u00e1 um projeto legado que come\u00e7ou h\u00e1 cinco anos (a partir de 2017 - nota do editor). No in\u00edcio, come\u00e7ou-se com o MySQL 5.5. Existem tamb\u00e9m projetos modernos, onde tentamos implementar vers\u00f5es mais recentes do MySQL, como 5.7 ou superiores (em 2017 - nota do editor).<\/p>\n

<\/p>\n

Quem trabalha com MySQL sabe que essas bibliotecas trazem depend\u00eancias. \u00c9 bastante problem\u00e1tico executar 2 bancos de dados juntos. Pelo menos, \u00e9 problem\u00e1tico conectar clientes antigos a um novo banco de dados. Isso, por sua vez, gera v\u00e1rios problemas.<\/p>\n

<\/p>\n

O pr\u00f3ximo problema \u00e9 quando o desenvolvedor trabalha em uma m\u00e1quina local, ele usa recursos locais, arquivos locais, e RAM local. Toda a intera\u00e7\u00e3o durante o desenvolvimento das solu\u00e7\u00f5es ocorre no que funciona em uma \u00fanica m\u00e1quina. Um exemplo disso \u00e9 quando temos 3 servidores backend em produ\u00e7\u00e3o, e o desenvolvedor salva arquivos no diret\u00f3rio raiz, de onde o nginx pega os arquivos para responder \u00e0s solicita\u00e7\u00f5es. Quando esse c\u00f3digo vai para produ\u00e7\u00e3o, percebe-se que o arquivo est\u00e1 presente em um dos 3 servidores.<\/p>\n

<\/p>\n

Atualmente, est\u00e1 em ascens\u00e3o a abordagem de microsservi\u00e7os. Quando dividimos nossas grandes aplica\u00e7\u00f5es em pequenos componentes que interagem entre si. Isso permite escolher tecnologias espec\u00edficas para o conjunto de tarefas requerido. Tamb\u00e9m permite dividir o trabalho e a \u00e1rea de responsabilidade entre os desenvolvedores.<\/p>\n

<\/p>\n

O desenvolvedor frontend, ao trabalhar com JS, praticamente n\u00e3o influencia o backend. O desenvolvedor backend, por sua vez, desenvolve, neste caso, em Ruby on Rails e n\u00e3o interfere no frontend. A intera\u00e7\u00e3o ocorre atrav\u00e9s de APIs.<\/p>\n

<\/p>\n

Como b\u00f4nus, com o Docker conseguimos otimizar os recursos no staging. Cada projeto, devido \u00e0 sua especificidade, requer configura\u00e7\u00f5es espec\u00edficas. Precisava-se fisicamente alocar um servidor virtual para cada um e configur\u00e1-los separadamente, ou ent\u00e3o dividir algum ambiente vari\u00e1vel, onde os projetos poderiam, dependendo da vers\u00e3o das bibliotecas, influenciar uns aos outros.<\/p>\n

<\/p>\n

\"Processo<\/p>\n

<\/p>\n

Ferramentas. O que estamos usando? <\/p>\n

<\/p>\n