Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adicionando testcontainers ao projeto #162

Merged
merged 20 commits into from
Jun 4, 2024
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
20 commits
Select commit Hold shift + click to select a range
9ad10b9
[WIP] Alterações de código para testcontainers
dunossauro Jun 3, 2024
eee5461
[WIP] Removendo tópico sobre serviços no CI da aula 11
dunossauro Jun 3, 2024
afe9caf
[WIP] Removendo inicialização do postgres do diagrama do CI na aula 11
dunossauro Jun 3, 2024
f632bec
update pydantic-email
dunossauro Jun 3, 2024
1fb699b
Verificações mais precisas de migrações no CI
dunossauro Jun 3, 2024
023555f
Envs por padrão com postgres
dunossauro Jun 3, 2024
33c6605
[WIP] Preparando o terreno para os testcontainers na aula 10
dunossauro Jun 3, 2024
90d96f7
[WIP] Introduzindo os testcontainers no texto da aula 10
dunossauro Jun 3, 2024
9b45100
Ajustando o codestyle da fixture de engine
dunossauro Jun 3, 2024
733d5bb
[WIP] Adicionando informações sobre escopos de fixtures na aula 10
dunossauro Jun 3, 2024
f3fd2e5
[WIP] Introduzindo o tópico de testes e docker
dunossauro Jun 4, 2024
8bc3cde
Linting no arquivo de tasks do CI
dunossauro Jun 4, 2024
50f604c
[WIP] Fechando tópico "Executando testes com o banco de dados em um c…
dunossauro Jun 4, 2024
0602da3
[WIP] Revisão do tópico "Containers de testes"
dunossauro Jun 4, 2024
214ed80
[WIP] Revisão do tópico "fixtures de sessão"
dunossauro Jun 4, 2024
277385d
[WIP] Atualização do tópico "fixture para engine"
dunossauro Jun 4, 2024
a6638a3
[WIP] Removendo o tópico executando os testes no Postgresql
dunossauro Jun 4, 2024
0c08828
FIX: tasks.py
dunossauro Jun 4, 2024
5ac6930
[WIP] Removendo a execução dos testes rodando no docker
dunossauro Jun 4, 2024
67ad5cf
[WIP] Correções de grafia na aula 10
dunossauro Jun 4, 2024
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 3 additions & 0 deletions .github/workflows/ci.yaml
Original file line number Diff line number Diff line change
Expand Up @@ -43,3 +43,6 @@ jobs:

- name: Roda os typos dos códigos de aulas
run: poetry run invoke typos-sub

- name: Testa as migrações
run: poetry run invoke test-migrations
342 changes: 256 additions & 86 deletions aulas/10.md

Large diffs are not rendered by default.

91 changes: 0 additions & 91 deletions aulas/11.md
Original file line number Diff line number Diff line change
Expand Up @@ -55,7 +55,6 @@ flowchart LR
C --> D[Instale as dependência do projeto com Poetry]
D --> E[Poetry execute os testes do projeto]
end
Ubuntu -- Inicie o banco de dados --> Postgres
```

Com o fluxograma em mente, nosso objetivo de aula é traduzir esses passos para a configuração prática no GitHub Actions. Agora que temos uma visão clara do que nosso workflow envolve, nos aprofundaremos em como transformar essa teoria em prática.
Expand Down Expand Up @@ -314,98 +313,8 @@ connection to server at "localhost" (127.0.0.1), port 5432 failed: Connection re
```

A mensagem `Is the server running on that host and accepting TCP/IP connections?` traduzida de forma literal quer dizer "O servidor rodando está aceitando conexões TCP/IP?". Isso quer dizer que houve uma tentativa de comunicação com `localhost:5432`, porém, não conseguiu obter uma resposta. Para corrigir esse comportamento teremos que partir para a configuração do postgres no workflow.

## Adicionando serviços ao Github Actions

Um 'serviço' no contexto do GitHub Actions é tipicamente um contêiner Docker que é iniciado com o nosso workflow. Esses serviços podem incluir bancos de dados, caches, ou qualquer outra dependência externa que nosso aplicativo possa precisar durante a execução do CI.

Na [aula passada (10)](10.md/#introduzindo-o-postgresql){:target="_blank"}, realizamos uma importante atualização nos nossos testes: a transição para o uso do PostgreSQL. Para que nossos testes no ambiente de CI reflitam esta mudança, precisamos incluir o PostgreSQL como um serviço no nosso workflow do GitHub Actions.

#### Adicionando suporte ao PostgreSQL

Para adicionar o serviço PostgreSQL ao CI, temos que criar uma seção chamada `services` em nosso arquivo `.github/workflows/pipeline.yaml`. Aqui, utilizamos a imagem Docker oficial do PostgreSQL e a configuramos como uma dependência essencial do nosso CI. A configuração define as variáveis de ambiente necessárias para o banco de dados e expõe a porta padrão do PostgreSQL:

```py title=".github/workflows/pipeline.yaml" linenums="8" hl_lines="7-15"
env:
DATABASE_URL: ${{ secrets.DATABASE_URL }}
SECRET_KEY: ${{ secrets.SECRET_KEY }}
ALGORITHM: ${{ secrets.ALGORITHM }}
ACCESS_TOKEN_EXPIRE_MINUTES: ${{ secrets.ACCESS_TOKEN_EXPIRE_MINUTES }}

services:
postgres:
image: postgres
env:
POSTGRES_DB: app_db
POSTGRES_PASSWORD: app_password
POSTGRES_USER: app_user
ports:
- 5432:5432
```

Dessa forma, no momento em que o CI for executado, ele iniciará um serviço postgres que pode ser usado durante o período de execução dos nossos testes. Como eles já estão configurados para isso e já temos as variáveis de ambiente apontando para o caminho do postgres, em nosso próximo commit já podemos ver os testes em ação:

```shell title="$ Execução no terminal!"
git add .
git commit -m "Adicionando o serviço do postgres no CI"
git push
```

![descrição](assets/11/print_ci_rodando_com_sucesso.png){: .center .shadow }

Este sucesso indica que nosso pipeline agora está corretamente configurado com o PostgreSQL, preparando o terreno para que cada push ou pull request no nosso repositório seja validado em um ambiente que espelha de perto nossa configuração de produção.

??? tip "Caso queira ver o arquivo completo"

Como o arquivo foi apresentado em pedaços até esse momento, é sempre importante ter uma visualização do arquivo completo para podermos validar se escrevemos tudo corretamente:

```yaml title=".github/workflows/pipeline.yaml" linenums="1"
name: Pipeline
on: [push, pull_request]

jobs:
test:
runs-on: ubuntu-latest

env:
DATABASE_URL: ${{ secrets.DATABASE_URL }}
SECRET_KEY: ${{ secrets.SECRET_KEY }}
ALGORITHM: ${{ secrets.ALGORITHM }}
ACCESS_TOKEN_EXPIRE_MINUTES: ${{ secrets.ACCESS_TOKEN_EXPIRE_MINUTES }}

services:
postgres:
image: postgres
env:
POSTGRES_DB: app_db
POSTGRES_PASSWORD: app_password
POSTGRES_USER: app_user
ports:
- 5432:5432

steps:
- name: Copia os arquivos do repositório
uses: actions/checkout@v3

- name: Instalar o python
uses: actions/setup-python@v5
with:
python-version: '3.11'

- name: Instalar o poetry
run: pipx install poetry

- name: Instalar dependências
run: poetry install

- name: Executar testes
run: poetry run task test
```

## Conclusão

Através deste módulo sobre Integração Contínua com GitHub Actions, ganhamos uma compreensão sólida de como a CI é vital no desenvolvimento moderno de software. Vimos como o GitHub Actions, uma ferramenta poderosa e versátil, pode ser utilizada para automatizar nossos testes e garantir a qualidade e estabilidade do código a cada commit. Esta prática não apenas otimiza nosso fluxo de trabalho, mas também nos ajuda a identificar e resolver problemas precocemente.

Com a habilidade de integrar serviços como o PostgreSQL, nosso workflow de CI agora reflete mais precisamente o ambiente de produção. Isso nos dá a confiança de que nosso código funcionará conforme esperado quando for lançado.

No próximo módulo, o foco será na preparação da nossa aplicação FastAPI para o deployment em produção. Exploraremos as etapas necessárias e as melhores práticas para tornar nossa aplicação pronta para o uso no mundo real, abordando desde configurações até estratégias de deployment eficazes.
Binary file removed aulas/assets/11/print_ci_rodando_com_sucesso.png
Binary file not shown.
Loading