{"id":32637287,"url":"https://github.com/a3data/framework-eml","last_synced_at":"2025-10-31T01:55:49.014Z","repository":{"id":269988310,"uuid":"850055907","full_name":"A3Data/framework-eml","owner":"A3Data","description":null,"archived":false,"fork":false,"pushed_at":"2025-04-24T17:46:58.000Z","size":404,"stargazers_count":0,"open_issues_count":2,"forks_count":0,"subscribers_count":1,"default_branch":"main","last_synced_at":"2025-04-25T13:36:52.761Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":null,"language":"Python","has_issues":true,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":null,"status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/A3Data.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":null,"code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null}},"created_at":"2024-08-30T19:35:52.000Z","updated_at":"2024-12-27T16:25:12.000Z","dependencies_parsed_at":"2024-12-27T17:38:55.422Z","dependency_job_id":null,"html_url":"https://github.com/A3Data/framework-eml","commit_stats":null,"previous_names":["a3data/framework-eml"],"tags_count":1,"template":true,"template_full_name":null,"purl":"pkg:github/A3Data/framework-eml","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/A3Data%2Fframework-eml","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/A3Data%2Fframework-eml/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/A3Data%2Fframework-eml/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/A3Data%2Fframework-eml/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/A3Data","download_url":"https://codeload.github.com/A3Data/framework-eml/tar.gz/refs/heads/main","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/A3Data%2Fframework-eml/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":281914558,"owners_count":26583083,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2022-07-04T15:15:14.044Z","status":"online","status_checked_at":"2025-10-30T02:00:06.501Z","response_time":61,"last_error":null,"robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":true,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2025-10-31T01:55:47.684Z","updated_at":"2025-10-31T01:55:49.008Z","avatar_url":"https://github.com/A3Data.png","language":"Python","funding_links":[],"categories":[],"sub_categories":[],"readme":"# Framework EML\r\n\r\n## Descrição\r\nEste repositório apresenta um pipeline de Machine Learning completo utilizando o dataset Iris. Ele cobre as etapas de download de dados, pré-processamento, treinamento de modelos e predição. Nesse repositório também estão implementadas as melhores práticas e diversas outras features.\r\n\r\n## Índice\r\n1. [Instalação](#instalação)\r\n2. [Estrutura do Repositório](#estrutura-do-repositório)\r\n3. [Configuração](#configuração)\r\n4. [Uso](#uso)\r\n   - [Recuperando os Dados](#recuperando-os-dados)\r\n   - [Preparação de Dados](#preparação-de-dados)\r\n   - [Treinamento do Modelo](#treinamento-do-modelo)\r\n   - [Inferência](#inferência)\r\n5. [Versionamento de Dados](#versionamento-de-dados)\r\n6. [Integração e Entrega Contínua (CI/CD)](#integração-e-entrega-contínua-cicd)\r\n7. [Deploy](#deploy)\r\n8. [Testes](#testes)\r\n\r\n## Instalação\r\nPasso a passo para utilizar o repositório e instalar as dependências.\r\n\r\n### Requisitos\r\n\r\nAntes de começar, certifique-se de ter as seguintes dependências instaladas:\r\n\r\n- WSL (caso voce esteja usando Windows):\r\n    - Abra um powershell e execute os comandos abaixo na ordem.\r\n    - `wsl --set-default-version 2`\r\n    - `wsl --install -d Ubuntu`\r\n    - `wsl --set-default Ubuntu`\r\n    - Daqui em diante, execute todos os comandos dentro do terminal do wsl.\r\n- Python 3.10+ - https://www.python.org/downloads/\r\n- VSCode - https://code.visualstudio.com/download\r\n    - O VSCode permite instalar extensões, é recomendado instalar ao menos a extensão que integra o VSCode ao WSL.\r\n    - Cole o seguinte ID na aba de extensões: `ms-vscode-remote.remote-wsl`\r\n\r\n### Inicializar o ambiente virtual e instalar dependências\r\n\r\nPara configurar o ambiente de desenvolvimento e instalar todas as dependências, utilize o Makefile:\r\n```bash\r\n    make init\r\n```\r\n\r\nEste comando executará as seguintes etapas:\r\n- Criará o ambiente virtual\r\n- Instalará o Poetry\r\n- Instalará as dependências do projeto\r\n- Configurará o pre-commit e o DVC\r\n\r\n### Entrar no ambiente virtual\r\n\r\nPara ativar o ambiente execute o comando:\r\n\r\n```bash\r\n    source .venv/bin/activate\r\n```\r\n\r\nA partir daqui você já tem tudo que é necessário para começar a utilizar o repositório. Modifique os arquivos para adequar ao seu cenário, contudo não altere os nomes das funções. Você pode criar novas funções, mas lembre-se de chamar elas no fluxo principal que são as funções com o decorador `@app.command()` nos arquivos dentro da pasta `src/pipelines`.\r\n\r\n## Estrutura do repositório\r\n```bash\r\n├── .dvc                                # Pasta para controle de versionamento de dados com DVC\r\n│\r\n├── .github                             # Configurações para o GitHub Actions\r\n│   └── workflows                       # Workflows de CI/CD\r\n│       ├── pipeline_lint.yml           # Pipeline para lint e formatação\r\n│       ├── pipeline_deploy_batch.yml   # Pipeline para deploy em batch\r\n│       └── pipeline_test.yml           # Pipeline para execução de testes\r\n│\r\n├── api                                 # Código da API para interagir com o modelo\r\n│   └── __init__.py                     # Torna o diretório um módulo Python\r\n│\r\n├── artifacts                           # Armazena dados e modelos\r\n│   ├── data                            # Dados organizados em diferentes estágios\r\n│   │   ├── external                    # Dados de fontes de terceiros\r\n│   │   ├── interim                     # Dados intermediários que foram transformados\r\n│   │   ├── processed                   # Conjuntos de dados finais e canônicos para modelagem\r\n│   │   └── raw                         # Dados originais e imutáveis\r\n│   └── models                          # Pasta para armazenar modelos treinados\r\n│\r\n├── config                              # Configurações de nível de projeto\r\n│   ├── __init__.py                     # Torna o diretório um módulo Python\r\n│   └── environments                    # Configurações de ambiente (ex. dotenv, YAML)\r\n│\r\n├── deployment                          # Arquivos relacionados à implantação e DevOps\r\n│   ├── docker                          # Arquivos para construção e gerenciamento de imagens Docker\r\n│   ├── infrastructure                  # Código para gerenciar a infraestrutura do projeto\r\n│   │   └── terraform                   # Arquivos Terraform para provisionamento de infraestrutura\r\n│   ├── pipelines                       # Pipelines de CI/CD\r\n│   └── scripts                         # Scripts de suporte para construção e implantação\r\n│\r\n├── docs                                # Um projeto mkdocs padrão\r\n│\r\n├── notebooks                           # Notebooks Jupyter\r\n│\r\n├── src                                 # Código fonte para desenvolvimento do modelo\r\n│   ├── __init__.py                     # Torna o diretório um módulo Python\r\n│   ├── pipelines                       # Códigos para pipelines de treino, criação de features e predição\r\n│   │   ├── features.py                 # Código para criação de features\r\n│   │   ├── get_data.py                 # Código para recuperar os dados\r\n│   │   ├── predict.py                  # Código para executar inferência com modelos treinados\r\n│   │   └── train.py                    # Código para treinar modelos\r\n│   └── utils                           # Scripts utilitários\r\n│\r\n├── tests                               # Scripts para execução de testes\r\n│\r\n├── ui                                  # Interface de usuário para interagir com a API do modelo\r\n│    ├── __init__.py                    # Torna o diretório um módulo Python\r\n│    ├── static                         # Templates para a interface de usuário\r\n│    └── templates                      # Arquivos estáticos (CSS, JS, imagens)\r\n│\r\n├── .gitignore                          # Lista de arquivos e/ou diretórios que não são armazenados no repositório\r\n├── .pre-commit-config.yaml             # Arquivo de configuração dos hooks de pre-commit\r\n├── dvc.lock                            # Arquivo de controle do DVC\r\n├── dvc.yaml                            # Arquivo de configuração do DVC\r\n├── Makefile                            # Arquivo para automatizar tarefas comuns de desenvolvimento\r\n├── poetry.lock                         # Arquivo de controle de dependências do Poetry\r\n├── pyproject.toml                      # Configuração do projeto e dependências\r\n└── README.md                           # Documentação do repositório\r\n```\r\n\r\n## Configuração\r\n\r\nO repositório tem o propósito de ser bem generalista, por isso, tem algumas configurações que você pode fazer para adequar o repositório ao seu projeto.\r\n\r\n### Arquivos de configurações globais\r\n\r\n#### Settings.py\r\nDentro da pasta `config` há o arquivo `settings.py`, ele pode ser utilizado para criar qualquer variável para ser utilizada em diferentes estágios do pipeline. Por padrão nós já colocamos os caminhos globais das pastas para referenciá-las sempre que necessário. Por estar centralizado nesse arquivo, se for necessário para seu projeto acrescentar outros arquivos ou trocar de lugar os existentes, você pode alterar somente nesse arquivo e todo o código já estará buscando o caminho correto.\r\n\r\n#### Configurações por ambiente\r\nAinda dentro da pasta `config`, note que há 4 outras pastas, cada uma representando um ambiente do projeto (loc, dev, hml e prd). Algumas configurações podem ser distintas para cada um dos cenários, principalmente arquivos .env, .yaml e outros. Por isso, criamos essas pastas.\r\n\r\nNo repositório há uma ferramenta que utiliza esses arquivos de configuração. A ferramenta `DVC`, utilizada tanto para versionamento de dados, quanto orquestração do pipeline de treino. Essa ferramenta pode receber parâmetros por meio de um arquivo .yaml, há um exemplo na pasta loc.\r\n\r\n### Data Version Control (DVC)\r\nComo citado anteriormente, utilizamos o DVC para o versionamento dos dados e também para a orquestração do pipeline. Existem algumas configurações que você pode querer fazer:\r\n1. Dentro da pasta .dvc há um arquivo config. Dentro desse arquivo config há um bucket S3 configurado, ele está na conta da sandbox da A3. O ideal é voce ter uma conta na AWS voltada para seu projeto, e então criar um bucket e colocar a URL dele no lugar. Você também pode colocar o S3 como sendo o repositório padrão, basta trocar a linha `remote = myremote` para `remote = s3bucket`, assim, ao executar o comando `dvc push` ele irá mandar para o S3. Para usar o S3 voce deve configurar suas credenciais da aws (https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-envvars.html).\r\n2. O dvc.yaml define o pipeline de treino padrão. Ele está configurado para:\r\n    - Executar o script `get_data.py`\r\n    - Usar a saída do `get_data.py` e executar o `features.py`\r\n    - Usar a saída do `features.py` e executar o `train.py`\r\nEntão se você deseja alterar esse fluxo, você deve alterar o arquivo dvc.yaml.\r\n\r\n### Dependências e pacotes\r\nAs bibliotecas necessárias podem ser instaladas e gerenciadas pelo arquivo `pyproject.toml`.\r\n\r\n### Makefile\r\nEsse arquivo contém todas as regras para facilitar o uso do repositório, entraremos em mais detalhes no próximo tópico de uso. Por agora, você pode encontrar algumas variáveis no topo do arquivo `Makefile` que podem ser alteradas, mas que devem funcionar perfeitamente da forma que estão.\r\n\r\n## Uso\r\n\r\n\r\n### Recuperando os Dados\r\nPassos para recuperar e carregar os dados.\r\nO script responsável por essa tarefa é o `src/pipelines/get_data.py`. Nele você deve configurar a forma como seus dados vão ser recuperados. Se eles forem um csv fixo, você pode só apagar essa etapa do pipeline do DVC no arquivo dvc.yaml. O importante é manter o nome da função, todo o conteúdo dela, assim como os parâmetros da função podem e devem ser alterados para o seu cenário.\r\n\r\nAo alterar os parâmetros, será necessário trocar no arquivo `dvc.yaml` os parâmetros esperados durante o pipeline de treino.\r\n\r\nCaso você queira testar esse script de maneira isolada execute:\r\n```bash\r\n    # Caso você ainda não tenha ativado o ambiente virtual\r\n    source .venv/bin/activate\r\n    # Lembre-se de passar os argumentos, caso haja\r\n    python -m src.pipelines.get_data\r\n```\r\n\r\n### Preparação de Dados\r\nPassos para carregar e preparar os dados para uso.\r\nO script responsável por essa tarefa é o `src/pipelines/features.py`. Esse é o script onde irá se concentrar toda a parte do processamento dos dados. Aqui deve estar toda a parte de limpeza e preparação dos dados, assim como a engenharia de features.\r\n\r\nAssim como foi feito na recuperação dos dados, se os parâmetros forem alterados o arquivo `dvc.yaml` deve ser modificado para refletir o que foi alterado no arquivo de preparação de dados.\r\n\r\nCaso você queira testar esse script de maneira isolada execute:\r\n```bash\r\n    # Caso você ainda não tenha ativado o ambiente virtual\r\n    source .venv/bin/activate\r\n    # Lembre-se de passar os argumentos, caso haja\r\n    python -m src.pipelines.features\r\n```\r\n\r\n### Treinamento do Modelo\r\nInstruções para treinar o modelo utilizando o código fonte.\r\nO script responsável por essa tarefa é o `src/pipelines/train.py`. Aqui é onde fica a lógica de treinar o modelo, então é onde você deve ler o dataset que resultou do features e retornar um arquivo do modelo treinado. O dataset da iris lê dados de treino e teste e treina um modelo SVC. Assim como você alterou os outros arquivos para adaptar ao seu projeto, altere aqui também para treinar seu modelo. Reforçando, todo o arquivo pode ser alterado, exceto pelo nome da função principal. E ao terminar as alterações, vá ao arquivo `dvc.yaml` e faça o mesmo.\r\n\r\nCaso você queira testar esse script de maneira isolada execute:\r\n```bash\r\n    # Caso você ainda não tenha ativado o ambiente virtual\r\n    source .venv/bin/activate\r\n    # Lembre-se de passar os argumentos, caso haja\r\n    python -m src.pipelines.train\r\n```\r\n\r\n### Inferência\r\nGuia para rodar inferências e salvar resultados.\r\nO script da inferência é o `src/pipelines/predict.py`. Diferente dos outros, aqui há duas funções importantes, a `predict` e a `predict_batch`.\r\n\r\nA `predict` serve para inferências pontuais, ela será utilizada no deploy online, enquanto que a `predict_batch` serve para a inferências em lote periódicas e será utilizada no deploy batch.\r\n\r\nNa `predict` você deve esperar receber os dados e deve retornar o resultado, por outro lado, no `predict_batch` você deve configurar o fluxo que você espera que aconteça no deploy batch. Por exemplo, caso você deseje ler dados de um banco de dados, fazer a inferência e salvar o resultado em um S3, você deve configurar esses 3 passos dentro da função.\r\n\r\n\r\nCaso você queira testar esse script de maneira isolada execute:\r\n```bash\r\n    # Caso você ainda não tenha ativado o ambiente virtual\r\n    source .venv/bin/activate\r\n    # Lembre-se de passar os argumentos, caso haja\r\n    python -m src.pipelines.predict predict         # Predict individual\r\n    python -m src.pipelines.predict predict-batch   # Predict em lote\r\n```\r\n\r\nComo a `predict_batch` pode ser feita de diferentes formas, o arquivo Dockerfile que faz o deploy batch (`deployment/docker/Dockerfile.batch`) também deve ser alterado ligeiramente. Ao final do arquivo, há o seguinte trecho de código:\r\n```dockerfile\r\nENV BATCH_INPUT_FILE=\"artifacts/data/raw/batch_data.csv\"\r\nENV BATCH_OUTPUT_FILE=\"artifacts/data/processed/predicted_data.csv\"\r\n\r\n# Comando para rodar o script de predição em lotes\r\nCMD [\"sh\", \"-c\", \"poetry run python -m src.pipelines.predict predict-batch $BATCH_INPUT_FILE --output-file $BATCH_OUTPUT_FILE\"]\r\n```\r\n\r\nNote que ele está passando dados de entrada e dizendo onde deve ser a saída, mas a lógica que se adequa ao seu projeto será diferente. Por exemplo, caso você não precise passar nenhum argumento, todo esse trecho anterior se transformaria em:\r\n```dockerfile\r\n# Comando para rodar o script de predição em lotes\r\nCMD [\"sh\", \"-c\", \"poetry run python -m src.pipelines.predict predict-batch\"]\r\n```\r\n\r\n### Makefile\r\nO projeto inclui um Makefile para facilitar o gerenciamento do ambiente e das dependências. Alguns comandos disponíveis:\r\n```\r\nmake install-poetry           Atualiza as dependências no poetry, útil quando alterar bibliotecas em pyproject.toml\r\nmake init                     Prepara todo o repositório com o poetry e pre-commit\r\nmake clean                    Remove todo o ambiente virtual e desconfigura o pre-commit\r\nmake lint                     Lint usando ruff (use `make format` para formatação)\r\nmake format                   Formata o código fonte com ruff\r\nmake lambda                      Inicia o lambda localmente [Docker]\r\nmake batch                    Inicia o batch localmente [Docker]\r\n```\r\n\r\n## Versionamento de Dados\r\nExplicação de como usar o DVC para versionar datasets e modelos.\r\n\r\n### O que é DVC?\r\n\r\nO DVC (Data Version Control) é uma ferramenta open-source que facilita o controle de versões de grandes datasets, modelos e pipelines de machine learning. Ele estende o Git para suportar dados e arquivos pesados, permitindo rastrear e gerenciar versões de dados sem armazená-los diretamente no repositório Git.\r\n\r\n### O que o DVC pode fazer?\r\n\r\n- **Controle de versão de dados e modelos**: Assim como o Git versiona código, o DVC versiona datasets e modelos de machine learning, facilitando a rastreabilidade de experimentos.\r\n- **Gestão de pipelines**: Automatiza o controle e execução de pipelines de ML, garantindo reprodutibilidade dos processos, desde a preparação dos dados até o treinamento de modelos.\r\n- **Integração com Git**: O DVC rastreia os arquivos de grandes volumes (datasets, checkpoints e modelos) e cria \"ponteiros\" no Git, para que os arquivos em si possam ser armazenados remotamente (S3, Google Drive, etc.), sem sobrecarregar o repositório Git.\r\n- **Colaboração**: Facilita o trabalho em equipe ao gerenciar versões de datasets compartilhados e modelos, garantindo consistência entre membros.\r\n- **Rastreabilidade e reprodutibilidade**: Cada versão dos dados e dos resultados de experimentos pode ser facilmente recuperada e reproduzida.\r\n\r\n### DVC no repositório\r\n\r\n**1.** O primeiro passo é verificar se o dvc está corretamente instalado.\r\n```bash\r\n# O primeiro passo é verificar se o dvc está corretamente instalado.\r\ndvc --version\r\n```\r\n**2.** Como executar o pipeline de treino\r\n```bash\r\n# Para executar todo o pipeline de treino\r\ndvc repro\r\n\r\n# Para executar um único passo você pode passar o nome dele\r\ndvc repro download\r\n\r\n# Se voce quiser evitar que ele verifique as dependências voce pode passar a flag -s\r\ndvc repro -s preprocess\r\n\r\n# Para mais informações você sempre pode consultar o help\r\ndvc repro --help\r\n```\r\n**2.** Como salvar e recuperar os dados e artefatos na nuvem\r\n```bash\r\n# Após acabar o treino, é importante fazer o push dos artefatos para o S3\r\ndvc push -r s3bucket\r\n\r\n# Caso o armazenamento padrão seja o s3 (veja no tópico \"Configurações\") você pode executar somente\r\ndvc push\r\n\r\n# Para baixar os dados\r\ndvc pull -r s3bucket\r\n\r\n# Se quiser do armazenamento padrão, basta usar\r\ndvc pull\r\n```\r\n**3.** Como versionar seus modelos e artefatos\r\n```bash\r\n# Antes de começar, lembre de adicionar qualquer artefato que não esteja mapeado no dvc.yaml e não faça parte do pipeline principal\r\ndvc add artifacts/data/raw/dados_nao_mapeados_pelo_pipe.csv\r\n\r\n# Ao terminar uma versão e garantir que todos artefatos estão mapeados pelo dvc, faça o commit para o git\r\ngit commit -m \"mensagem de commit\"\r\n\r\n# Agora coloque uma tag para se lembrar depois, de preferencia versionamento semantico\r\ngit tag -a \"v0.1.0\" -m \"modelo treinado dia 11/10/24 com dataset x\"\r\n\r\n# Lembre-se de mandar essa tag para o repositório remoto\r\ngit push origin tag v0.1.0\r\n\r\n# Pronto! Agora você pode sempre voltar a esse ponto usando o comando\r\ngit checkout v0.1.0 # Ao usar esse comando, o dvc já trará os artefatos específicos dessa versão, assim como o código do git\r\n\r\n# Se você já tiver muitas versões você pode verificá-las com\r\ngit tag --list\r\n```\r\n\r\nSe quiser fazer alguns outros testes para ver o dvc funcionando organicamente, experimente os passos a seguir com o dataset da iris já configurado:\r\n\r\n**1.** Após reproduzir o pipeline com `dvc repro`, experimente modificar os arquivos gerados dentro da pasta `artifacts/data` e execute o `dvc repro` novamente. Você irá notar que ele busca a versão correta do cache, sem a necessidade de rodar de novo.\r\n\r\n**2.** Agora tente apagar esses arquivos, até mesmo o modelo em `artifacts/models/model.joblib`. Tudo isso pode ser recuperado usando `dvc pull`. Esse comando busca do storage (normalmente na nuvem) os arquivos e coloca na pasta local, assim como o git faz com o código. Esse repositório tem configurado como padrão o storage local na pasta /tmp/dvcstore, contudo ele tem também configurado um bucket S3 do ambiente de sandbox da A3. Então se você tiver acesso a conta `a3datasandbox` da aws, experimente o comando: `dvc pull -r s3bucket`. Lembrando, voce deve configurar suas credenciais da aws (https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-envvars.html).\r\n\r\n**3.** Tente fazer alterações no modelo, ou nos dados, ou no processamento, contanto que você mantenha a estrutura dos arquivos, o pipeline irá manter as features mencionadas anteriormente. Faça as alterações e rode `dvc repro`\r\n\r\nVocê pode conseguir mais informações sobre o dvc no link https://dvc.org/doc.\r\n\r\n## Deploy\r\nPassos para deploy em batch ou deploy online.\r\n\r\nOs deploys só podem ser feitos através dos pipelines do CI/CD do github. Com isso, garantimos segurança e praticidade já que não há necessidade de configurar terraform, docker, aws cli e credenciais. Há somente alguns cuidados e passos necessários para que o deploy seja feito:\r\n\r\n- Primeiro, não alterar os nomes das funções, especialmente das de predict, que são as que serão utilizadas enquanto os modelos estiverem sendo servidos na nuvem.\r\n\r\n- Se assegurar de que as mudanças feitas nos códigos de inferência em `src/pipelines/predict.py` estejam sendo refletidas nos Dockerfiles, como instruído em `Inferência`.\r\n\r\n- Se ficar em dúvida se o deploy vai funcionar, use os comandos do makefile que permitem voce testar localmente. São eles: `make batch` e `make lambda`. Eles irão rodar um container Docker da mesma forma que será executado na nuvem.\r\n\r\n- Após rodar o comando `make lambda`, você pode testar as predições localmente através de uma requisição HTTP para o container Docker que está rodando a função Lambda localmente. Utilize o seguinte comando `curl` para fazer isso:\r\n\r\n    ```bash\r\n    curl -X POST http://localhost:9000/2015-03-31/functions/function/invocations -d '[ [5.1, 3.5, 1.4, 0.2], [6.2, 2.9, 4.3, 1.3] ]'\r\n    ```\r\n\r\n    A resposta esperada será algo similar a:\r\n\r\n    ```json\r\n    {\r\n    \"statusCode\": 200,\r\n    \"body\": \"[{\\\"prediction\\\": 2}, {\\\"prediction\\\": 0}]\"\r\n    }\r\n    ```\r\n\r\n    Isso significa que o modelo foi executado corretamente e as predições foram realizadas para os exemplos fornecidos.\r\n\r\n- Para o deploy em si, há a necessidade de se criar uma role na AWS com OIDC. Aqui está o tutorial oficial da AWS de como criar e configurar: https://aws.amazon.com/pt/blogs/security/use-iam-roles-to-connect-github-actions-to-actions-in-aws/ . Após configurar, coloque o arn da role no arquivo yml dos pipelines de deploy batch e deploy online (lambda).\r\n\r\n## Integração e Entrega Contínua (CI/CD)\r\nDetalhes dos pipelines no GitHub Actions.\r\n\r\n- **Pipeline Lint**: É o pipeline que irá executar todos os passos para garantir a qualidade do código. São os mesmos passos do pré-commit. Ele fica definido no arquivo `.github/workflows/pipeline_lint.yml`.\r\n- **Pipeline Deploy Batch**: É o pipeline que irá fazer o deploy batch. Ele levanta toda a infraestrutura na AWS, constrói a imagem Docker e envia ela para o repositório privado dentro da AWS para ser utlizada pelo ECS. Esse fluxo fica definido em `.github/workflows/pipeline_deploy_batch.yml`. A infraestrutura é constituída pelos seguintes serviços:\r\n    - ECR\r\n    - ECS com Fargate\r\n    - Eventbridge\r\n    - VPC\r\n    - Ela funciona ao enviar as imagens para o ECR, então o Eventbridge agenda uma tarefa no ECS\r\n- **Pipeline Deploy Online**: Pipeline que faz o deploy online. Ele levanta a infraestrutura na AWS, constrói a imagem Docker e envia ela para o repositório, da mesma forma que o deploy batch. Contudo, ele utiliza como infraestrutura uma AWS Lambda e também um API Gateway para que o endpoint possa ser acessado de qualquer lugar da internet. Se esse NÃO for seu caso, podemos te ajudar a remover essa parte e deixar o endpoint privado.\r\n- **Pipeline Test**: Esse pipeline executa todos os testes definidos dentro da pasta `tests` na raiz do projeto. É utilizado a biblioteca pytest. Há 4 testes nesse caso de uso de exemplo, eles são mais específicados a seguir.\r\n\r\n## Testes\r\nInstruções para rodar testes de unidade e integrados.\r\n\r\nNo exemplo do repositório há 4 testes sendo feitos:\r\n- Testa se o modelo salva corretamente\r\n- Testa se os dados são carregados corretamente\r\n- Testa o pré-processamento e verifica se o dado de treino tem a coluna alvo\r\n- Testa o pré-processamento e verifica se ele levanta um erro ao tentar carregar um arquivo inexistente.\r\n\r\nÉ importante adaptar os testes para o seu cenário. Esse comando executa todos os testes dentro da pasta `tests`, então sinta-se livre para criar quantos testes você achar necessário e lembre-se de alterar os existentes.\r\n\r\nA documentação da biblioteca de testes que utilizamos é a seguinte: https://docs.pytest.org/en/stable/\r\n\r\nPara executar os testes fora do pipeline de CI/CD, use:\r\n\r\n```bash\r\n# Comando para rodar testes\r\npytest --cov=.\r\n```\r\n\r\n## Boas Práticas para Commits com Pré-commit\r\n\r\n- Durante o commit, o Pré-commit verifica e corrige a formatação do código, mas não inclui essas alterações automaticamente no commit. É necessário executar `git add` novamente para registrar essas modificações. O Git não faz isso automaticamente para que você tenha controle total sobre o que será comitado. Então, se ao tentar dar commit aparecer um erro, verifique se não há arquivos modificados pelo pré-commit que precisam ser adicionados ao commit.\r\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fa3data%2Fframework-eml","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fa3data%2Fframework-eml","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fa3data%2Fframework-eml/lists"}