> ## Documentation Index
> Fetch the complete documentation index at: https://docs.devinenterprise.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Containerização

> Neste tutorial, vamos mostrar como o Devin pode configurar um contêiner Docker para padronizar o ambiente de desenvolvimento da sua equipe.

<div id="creating-a-docker-container">
  ## Criando um Container Docker
</div>

Como o Devin tem acesso a um terminal e pode configurar e executar software em seu próprio servidor, criar um container Docker está totalmente dentro das suas capacidades.

Nossa aplicação de exemplo é um projeto em Go com MongoDB como armazenamento de dados. Esta sessão é a versão do Devin de um pull request que um desenvolvedor real fez para um projeto open source. Acompanhe a execução ao vivo [aqui](https://app.devin.ai/sessions/379eb9a40ff2433db49e51c95c7d9bc1?ts=1729908167981).

<div id="start-with-a-github-issue">
  #### Comece com uma issue do GitHub
</div>

Começamos com a issue original do GitHub:

<Frame>
  ![Devin](https://cdn.sanity.io/images/2mc9cv2v/production/e8a410ab96ee363911b146bcbd923da43c25b03a-1856x746.png)
</Frame>

Em seguida, podemos escrever um prompt simples para o Devin com base no que essa issue está pedindo. Pedimos que ele leia a issue do GitHub acima para obter mais contexto, mas também damos nosso próprio resumo da solução proposta e do que queremos que o Devin produza.

<Frame>
  ![Devin](https://cdn.sanity.io/images/2mc9cv2v/production/4caecf4fd393f5573536a5b6d57d7246b684d699-1312x612.png)
</Frame>

<div id="investigating-the-codebase">
  #### Investigando a base de código
</div>

Devin começa com uma etapa de investigação em que lê nossa issue vinculada no GitHub e [analisa](/pt-BR/release-notes#repo-knowledge) o código e os arquivos de configuração do projeto em busca das dependências necessárias.

<Frame>
  ![Devin](https://cdn.sanity.io/images/2mc9cv2v/production/4f146e093bd0374b5d816c5fd9f49d6a411d6c8f-1334x844.png)
</Frame>

Após concluir a análise, Devin procede à instalação do Docker em sua máquina local e, em seguida, cria nosso Dockerfile inicial, docker-compose.yml e .dockerignore para começar a testar a configuração do contêiner. Ele também configura nosso arquivo .env para que a aplicação possa ser executada com o back-end em contêiner recém-configurado.

<Frame>
  ![Devin](https://cdn.sanity.io/images/2mc9cv2v/production/710b051e9b5f75d3b5492f554fee786e212dc129-1314x1370.png)
</Frame>

<div id="testing-the-container">
  #### Testando o container
</div>

Devin então passa a testar cada container, começando pelo nosso servidor MongoDB e depois seguindo para o nosso ambiente Go. Assim que os containers estão em execução, Devin passa a testar o próprio aplicativo. Ao ler o [Histórico de Comandos](/pt-BR/work-with-devin/devin-session-tools#shell-command-history) do Devin, vejo que ele encontrou nossa definição de API Swagger e a carregou no [Browser](/pt-BR/work-with-devin/devin-session-tools#interactive-browser) integrado para entender como a API de backend funciona.

<Frame>
  ![Devin](https://cdn.sanity.io/images/2mc9cv2v/production/3cee193ba84dcea344e4a7fd829ae39c0d602270-2720x1422.png)
</Frame>

Em seguida, Devin montou uma requisição curl para testar se a API de backend está em execução e retornando resultados conforme sua especificação de design.

<Frame>
  ![Devin](https://cdn.sanity.io/images/2mc9cv2v/production/de15b455421e2320b5dd6023bd0d4d47aaff2e7c-1208x710.png)
</Frame>

<div id="debugging">
  #### Depuração
</div>

Como recebemos um erro de **Connection refused**, Devin imediatamente inicia a depuração e correção da configuração do Docker. Esse é um padrão comum em que Devin consegue se autocorrigir à medida que avança em uma sessão. Devin corrige rapidamente o problema de configuração, reinicia o contêiner Docker e resume o trabalho concluído para nós.

<Frame>
  ![Devin](https://cdn.sanity.io/images/2mc9cv2v/production/ad2d884abb70c7dd74614addbe1d8e111ebf7d53-1356x2208.png)
</Frame>

Quando comparamos o trabalho do Devin com o [PR do projeto real](https://github.com/Ratnesh-Team/Rehabify/pull/137), há algumas diferenças e melhorias importantes:

* Devin configura um arquivo docker-compose.yml além do nosso Dockerfile. Isso nos dá configurações de orquestração mais específicas, como definir como nossa rede funciona, como nossos volumes são configurados e de quais serviços outros serviços dependem.
* Devin altera o processo de build de `go mod tidy` para um método que nos permite armazenar em cache algumas das dependências no nosso build Docker.
* Devin gera um binário Go estaticamente ligado em vez de dinamicamente ligado, o que deve deixar nosso build Docker mais leve.
* Devin configura nossos certificados de CA para HTTPS e nos permite usar um arquivo .env para configuração em vez de passar variáveis de ambiente diretamente.
* E, principalmente, Devin adiciona um serviço MongoDB na nossa configuração Docker, algo que o PR do projeto não faz. Ele assume que o desenvolvedor já tem uma instância separada de MongoDB em execução.

<Frame>
  ![Devin](https://cdn.sanity.io/images/2mc9cv2v/production/7607ba8b57199a26812cb8f4c7129ee5a97ffcdb-1818x1206.png)
</Frame>

Em 13 minutos, Devin configurou com sucesso nosso contêiner Docker para o backend deste projeto usando boas práticas, testou-o e escreveu um resumo abrangente do seu trabalho. Experimente hoje o seu próprio prompt de containerização na sua base de código [se inscrevendo](https://cognition.com/get-started#company) para uma conta Devin para sua equipe.
