📝 Relatório de Contribuição – Sprint 0

Disciplina: Gestão de Configuração e Evolução de Software

Equipe: OWASP (Times Blue e Red)

Comunidade/Projeto de Software Livre: OWASP (ej-application)

1. Objetivos da Sprint

Instalar a aplicação local.
Estudar infraestrutura da aplicação.
Documentar primeiros aprendizados sobre ambiente.

2. Entregas Coletivas

Entrega	Status (Concluído/Parcial/Pendente)	Link/Referência	Observações
Ambiente local configurado	Concluído	Original: Repositório ej-application	Execução com `inv docker-up`
Relatório de atividades da Sprint 0	Concluído	–	Documento atual
Identificação das práticas de GCES do projeto	Concluído	– 📚 Práticas de GCES no EJ	Documento atual
Configuração inicial do ambiente do EJ	Concluído	- ⚙️ Configuração de Ambiente	Documento atual
Estudo sobre a infraestrutura da aplicação	Concluído	- 🏗️ Infraestrutura	Documento atual

3. Contribuições Individuais

Integrante	Contribuições	Links (PRs, Issues, Docs)
Mateus Vieira	Documentação das práticas de GCES do EJ	📚 Práticas de GCES no EJ
Miguel Arthur	Documentação da Infraestrutura do EJ	🏗️ Infraestrutura
Marcus Vinicius	Documentação da Configuração inicial do ambiente do EJ	⚙️ Configuração de Ambiente
Júlio Costa	Documentação das Maiores Dificuldades	Maiores Dificuldades
Henrique Quenino	Documentação de Aprendizados	Lições Aprendidas

4. Maiores Avanços

✨ Destaques da Sprint

Aplicação instalada e containers rodando corretamente.
Equipe conseguiu compreender dependências principais (Docker, Python, Invoke).
Alinhamento com o mentor da disciplina sobre o cronograma e entregas.

📚 Práticas de GCES no EJ

Comunicação e Fluxo:

Sempre usar grupos públicos — Telegram — (evitar contato privado).
Ambiente configurado via Docker conforme README.md.
Organização por sprints + OKRs, com Kanban para acompanhamento.

Desenvolvimento e Boas Práticas:

Branchs a partir da develop, nome ligando ao ID da issue.
Testes: unitários, integração (Pytest), aceitação (Cypress).
Código: Black (formatação), Ruff (análise estática).
Frontend: BEM CSS, SASS, HTMX, responsividade com flex/grid.
Priorizar soluções simples, coesas e “pythonicas”.

Revisão e Deploy:

Auto-revisão obrigatória antes de pedir análise do MR.
MR sem testes ou com erros não é revisado.
Atualizar documentação (Sphinx) e traduções (Django i18n) quando necessário.
MR aprovado ativa CI/CD, atualizando homologação e produção automaticamente.

⚙️ Configuração de Ambiente

1. Instalação do Docker

A aplicação é executada em contêineres, então o Docker é um requisito fundamental. Então para atualizar os pacotes e instalar as dependências do Docker:

Comando:

sudo apt update
sudo apt install -y ca-certificates curl

Instalar o Docker Engine e plugins

Comando:

sudo apt update
sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

2. Instalação e Configuração do Pyenv e Python

instalar o pyenv e suas dependências:

Comando:

curl https://pyenv.run | bash
sudo apt install -y build-essential libssl-dev zlib1g-dev libbz2-dev libreadline-dev libsqlite3-dev wget curl llvm libncurses5-dev libncursesw5-dev xz-utils tk-dev libffi-dev liblzma-dev git

Para instalar o Python para o projeto pós configuração do do Pyenv, é necessário utilizar a versão ressaltada no proprio README.rd do projeto, sendo ela a versão 3.11 do Python.

Comando:

pyenv install 3.11.9.

3. Clonar Repositório

Para começar a configurar o ambiente, primeiramente é necessario clonar o repositório do projeto para a maquina local. Logo após isso, adentrar a pasta do projeto.

Comando:

git clone https://gitlab.com/pencillabs/ej/ej-application
cd ej-application

4. Instalar o Invoke

O projeto utiliza a ferramenta de invoke para gerenciar os comandos do Docker. O README.md é instruido a instalá-lo utilizando o pip3.

Comando:

pip3 install invoke==2.0.0 django-environ --user

5. Iniciar a Aplicação

Com o invoke instaladom, agora é utilizar o seguinte comando para construir as imagens Docker e iniciar todos os contêiners da aplicação: Esse comando do Docker-up serve para baixar todas as dependências, criar os contêineres e executar a aplicação. O terminal ficará exibindo os logs em tempo real.

Comando:

inv docker-up

6. Acessar a Aplicação

Assim que os contêineres estiverem rodando, a aplicação estará disponível no seu navegador nesse endereço:

http://localhost:8000 ---

7. Outros comandos do Projeto

No README.md do projeto também é listado outros comandos úteis para gerenciar o ambiente Docker através do invoke:

inv docker-stop: Para os contêineres da aplicação.
inv docker-logs: Mostrar os logs do serviço do Django.
inv docker-rm: Remove os contrêineres da aplicação.
inv docker-exec "comando": Executa um comando shell dentro do contêiner do Django.

🏗️ Infraestrutura

Análise da Infraestrutura do Projeto EJ-Platform

Ao analisar o projeto, Notamos que ele utiliza uma infraestrutura moderna e bem organizada, baseada em contêineres com Docker. Uma prática interessante é que a arquitetura é dividida em dois cenários distintos: um para desenvolvimento e outro para produção.

1. Ambiente de Desenvolvimento

Para o desenvolvimento do dia a dia, o projeto usa uma configuração mais simples, definida no arquivo docker-compose.yml. Ela é composta por apenas dois serviços principais:

server: Um contêiner que roda a aplicação Django com o servidor de desenvolvimento embutido. Isso é ótimo para o desenvolvimento, pois o código é sincronizado em tempo real, e qualquer alteração é refletida na hora.
db: Um contêiner com o banco de dados PostgreSQL.

Essa abordagem simplifica muito a configuração inicial e permite que o desenvolvedor foque apenas no código.

2. Ambiente de Produção

Para o ambiente de produção, a arquitetura é mais robusta e focada em performance e segurança, como é esperado de uma aplicação real. Embora não haja um único arquivo de configuração que defina toda a estrutura, as dependências declaradas no arquivo pyproject.toml apontam para a seguinte estrutura:

Gunicorn: É o servidor que executa a aplicação Django de forma otimizada para produção, aguentando mais tráfego que o servidor de desenvolvimento.
PostgreSQL: O mesmo banco de dados, responsável por guardar os dados.

Conclusão

Em resumo, o projeto demonstra maturidade ao fornecer uma configuração de desenvolvimento limpa e auto contida, enquanto desacopla a aplicação da infraestrutura de produção. Em vez de definir uma configuração de produção rígida dentro do repositório, ele indica os componentes essenciais para produção (servidor Gunicorn) através de suas dependências e espera que o ambiente de implantação final gerencie o resto da infraestrutura (como o banco de dados e o reverse proxy).

5. Maiores Dificuldades

A utilização do Docker facilitou em subir o ambiente isolado com todas as dependências instaladas, a configuração do ambiente foi concluída com sucesso, sem ocorrências de problemas técnicos, mas alguns integrantes tiveram dificuldade parar subir o ambiente usando WSL no Windows, o projeto aparenta ser bem documentado e é possível subir uma página de documentação local Sphinx rodando inv docker-exec "inv docs" após a configuração inicial do ambiente.

6. Lições Aprendidas

Nesta sprint, o principal aprendizado foi sobre a importância de ter um ambiente de desenvolvimento bem configurado e documentado. O uso do Docker possibilita isolar todas as dependências do projeto em containers, garantindo que todos trabalhem em ambientes idênticos, o que elimina o famoso problema do “funciona na minha máquina”. Por fim concluimos que praticar essas técnicas acelera o desenvolvimento, reduz retrabalho, proporciona escalabilidade e melhora a colaboração entre times, entregando mais qualidade durante todo o ciclo de vida do software.

7. Planejamento para a Próxima Sprint

Blue Team

Mapear arquitetura e superfícies de ataque:
Estudar os frameworks de modelagem (STRIDE, DREAD, PATH)
Recolher o máximo de documentação do projeto
Realizar a modelagem de riscos utilizando o STRIDE

Red Team

Estudar vetores de ataque:
- SQL Injection
- CSRF
- XSS e Clickjacking
- IDOR
- Sessões/Cookies inseguros
- Brute force / Rate limiting