Primeiro deploy SIMA

[gabrielbdornas]

• [x] Utilizar tabela user do próprio framework.
• [x] Referenciar tabela user do próprio framework em demais tabelas.
• [x] Criar seed superuser para conseguir logar no novo servidor.
• [x] Preparar para deploy com Docker.
• [x] Testa deploy fork gabriel.
• [x] Criar conta dcd onrender.
• [x] Deploy definitivo ambiente teste conta dcd onrender.

[gabrielbdornas]

Durante test deploy fork @gabrielbdornas, migração para criação de superusuário não funcionou com variáveis de ambiente cadastradas. Ao que tudo indica, as variáveis cadastradas no serviço não estão sendo carregadas para dentro do conteiner.

See https://community.render.com/t/missing-env-file/11200 See https://docs.render.com/docker-secrets#environment-variables-in-docker-builds

[gabrielbdornas]

@raianecardoso, criei uma conta para dcd no render, basta acessar estando logado no GitHub da dcd.

[gabrielbdornas]

Erro Timed out: Port scan timeout reached, no open ports detected on 0.0.0.0. Detected open ports on localhost -- did you mean to bind one of these to 0.0.0.0? solucionado a partir deste post. Somente incluí 0.0.0.0:8000 para ligar o servidor (python manage.py runserver 0.0.0.0:8000)

[gabrielbdornas]

Error Origin checking failed - does not match any trusted origins.

Help
Reason given for failure:

    Origin checking failed - https://sima-2lmy.onrender.com does not match any trusted origins.

In general, this can occur when there is a genuine Cross Site Request Forgery, or when [Django’s CSRF mechanism](https://docs.djangoproject.com/en/5.0/ref/csrf/) has not been used correctly. For POST forms, you need to ensure:

Your browser is accepting cookies.
The view function passes a request to the template’s [render](https://docs.djangoproject.com/en/dev/topics/templates/#django.template.backends.base.Template.render) method.
In the template, there is a {% csrf_token %} template tag inside each POST form that targets an internal URL.
If you are not using CsrfViewMiddleware, then you must use csrf_protect on any views that use the csrf_token template tag, as well as those that accept the POST data.
The form has a valid CSRF token. After logging in in another browser tab or hitting the back button after a login, you may need to reload the page with the form, because the token is rotated after a login.
You’re seeing the help section of this page because you have DEBUG = True in your Django settings file. Change that to False, and only the initial error message will be displayed.

You can customize this page using the CSRF_FAILURE_VIEW setting.

[gabrielbdornas]

Dados incluídos no banco de dados do projeto após publicação são perdidos. Este post me ajudou a entender porque:

Hi,

Render instances have an ephemeral filesystem, meaning any file written to the instance after it has booted will be >lost when it next restarts (e.g. spun down if on free instance type, next deploy, manual restart, etc.).

If you’re using SQLite on your service, you’ll need to have a persistent store, a Render Disk (which is chargeable and also requires a paid instance type).

Para resolver o problema tentei criar um banco de dados Postgres no render, mas descobri que os dados são perdidos após 30 dias:

O ideal é achar outro serviço para realizar esta conexão.

O video Easiest Way To Connect Django To A Postgres Database mostra como fazer a conexão. O primeiro post mostrado também dá um exemplo de como referenciar esta conexão no código:

if DEBUG :
  DATABASES = {
    “default”: {
      “ENGINE”: “django.db.backends.sqlite3”,
      “NAME”: BASE_DIR / “db.sqlite3”,
    }
  }
else :
  DATABASES = {
    ‘default’: dj_database_url.parse(os.getenv(“DATABASE_URL”))
  }

[gabrielbdornas]

Como dito no comentário anterior, o video Easiest Way To Connect Django To A Postgres Database (e seu post) me ajudaram a entender como a conexão com Postgres deveria ser feita.

Descobri o serviço de banco de dados supabase que possui planos gratuitos, e com isso criei uma conta vinculada ao usuário dcd no GitHub. Feito isso, bastou incluir as credenciais de conexão, que consegui também graças a este artigo, e consegui realizar a migração. :sweat:

[gabrielbdornas]

Depois que consegui integrar o novo banco de dados Postgres comecei a ter problemas com a visualização do site:

Descobri com auxílio desta resposta stackoverflow que:

With debug turned off Django won't handle static files for you any more - your production web server (Apache or something) should take care of that.

O que fez sentido porque no ambiente sima-test a variável DEBUG está configurada como False.

A maioria das respostas desta mesmo resposta sugerem instalar a biblioteca WhiteNoise para resolver o problema, que fiz.

Ler esta resposta - https://stackoverflow.com/questions/74732370/django-website-does-not-load-static-files

[gabrielbdornas]

Deploy definitivo ambiente teste conta dcd onrender concluído após utilização messiânica do tutorial Deploy a Django App on Render.

Historico e pensamentos futuros

@raianecardoso, criei a branch test-env para testar o deploy em um repositório sima forkado no meu usuário. Ela deu certo após muita marretada. Basicamente tive que colocar hard code (o que é péssimo) as informações de login e senha do superuser.

Após entender que o problema para criar o superuser estava na dificuldade da máquina render ler variáveis de ambiente em uma imagem docker, fiz algumas modificações e criei a branch test. Esta foi criada com muito sucesso. Sendo assim, nosso ambiente de teste já está disponível vem https://sima-test.onrender.com/

Já adianto então que teremos funcionando em paralelo 3 ambientes:

• dev: Rodará em nossas máquinas a partir da branch dev (a ser criada).
• test: Rodará no servidor sima-test a partir da branch test (criada conforme explicado acima). Toda modificação aprovada na branch dev será mergiada na branch test e, portanto, testada no servidor sima-test
• prod: Rodará no servidor sima-prod (a ser criado) a partir da branch main. Toda modificação aprovada na branch test será mergiada na branch main e, portanto, aplicada no servidor sima-prod .

graph TD
    A[Início do Projeto] --> B[Coleta de Requisitos]
    B --> C[Análise de Requisitos]
    C --> D[Design do Sistema]
    D --> E[Desenvolvimento]
    E --> F[Testes Unitários]
    F --> G[Branch dev]
    G --> H[Testes de Integração]
    H --> I[Branch test]
    I --> J[Testes de Aceitação]
    J --> K[Branch main]
    K --> L[Implantação em Ambiente de Produção]
    L --> M[Monitoramento e Manutenção]

    subgraph Ambiente de Desenvolvimento
        G
    end

    subgraph Ambiente de Testes
        I
    end

    subgraph Ambiente de Produção
        K
    end

    subgraph Branches
        G -->|Merge aprovado| I
        I -->|Merge aprovado| K
    end

    E --> F
    J --> L

[gabrielbdornas]

Acredito que podemos simplificar o pipeline de produção proposto no fluxo desenhado neste comentário com a opção Pull Request Previews habilitada.

Teríamos assim um ambiente a menos para cuidar (sima-test), sendo crido uma nova instância toda vez que abrirmos um PR para a branch main. Acredito que vale o teste.