Repositório central da "fábrica" de software — templates, projetos didáticos, infra e material de apoio para desenvolvimento, infraestrutura e automação.

1. Sobre
2. Objetivos
3. O que você encontra aqui
4. Como os projetos estão organizados
5. Contribuindo
6. Onboarding / Mantainers
7. Licença e Código de Conduta
8. Templates & Automatizações
9. CI/CD e Runners self-hosted
10. Como solicitar um novo projeto
11. Contato / Comunidade

O Jardim de Software é a organização que centraliza os repositórios criados pela fábrica: desde boilerplates e templates (front, back, infra), projetos educativos e comerciais, experimentos de infra (Proxmox, Kubernetes, Rancher) e integrações de CI/CD. Nosso foco é educação prática, automação e reutilização.

• Facilitar o aprendizado prático em desenvolvimento e infraestrutura.
• Fornecer templates reutilizáveis e padrões para acelerar o início de novos projetos.
• Promover boas práticas de Git, CI/CD, infraestrutura como código e DevSecOps.

• Templates: front-end (Next.js), back-end (.NET/Spring/Node), infra (Terraform/Ansible), Dockerfiles etc.
• Projetos didáticos: exercícios, exemplos de disciplinas e material para estudantes.
• Infra: exemplos de configuração Proxmox, runners self-hosted, scripts de automação.
• Modelos: GitHub Actions, templates de issue/PR, geradores de repositório.

Padrões sugeridos para repositórios nesta organização:

• template-<tipo>-<nome> — ex: template-front-nextjs, template-back-spring.
• proj-<nome>-<ano> — projetos disciplinares ou entregas de turma.
• infra-<componente> — scripts, playbooks e IaC (ex: infra-proxmox, infra-runners).
• Estrutura mínima de pastas e arquivos:

/
├── .github
│
├── backend/
│   ├── Dockerfile
│   └── (projetos e arquivos relacionados ao backend)
│
├── frontend/
│   ├── Dockerfile
│   └── (projetos e arquivos relacionados ao frontend)
│
├── config/
│   └── Arquivos de configuração do projeto/aplicação  
│
├── .env.example
├── .gitignore
├── LICENSE
├── README.md
└── docker-compose.yml

Branch principal:

• main — versão pronta para uso/produção.

Use GitHub Flow e nomes de branchs semanticos. Ex:

feature/: Nova funcionalidade (ex: feature/login-oauth).
fix/ ou bugfix/: Correção de bugs (ex: fix/corrige-botao-envio).
hotfix/: Correção urgente em produção (ex: hotfix/crash-pagamento).
refactor/: Refatoração de código sem alterar funcionalidade (ex: refactor/otimiza-query-user).
docs/: Mudanças apenas na documentação/README.
style/: Formatação, ponto e vírgula, espaços (sem alterar lógica).
test/: Adição ou correção de testes.
chore/: Atualização de dependências, builds, configs

Tags: semântica sugerida vMAJOR.MINOR.PATCH para releases.

Quer contribuir? Obrigado — você é bem-vindo! Siga este fluxo:

1. Abra uma issue descrevendo a sugestão ou bug.
2. Discuta a proposta (se necessário) e aguarde aprovação do maintainer.
3. Abra um pull request a partir de um branch feature/ fix/ etc, com descrições claras e checklist.
4. Certifique-se de que o PR roda nos checks (linters, testes, build).

Arquivos úteis (colocar em .github/ de cada repo):

• CONTRIBUTING.md (guia específico do repo)
• ISSUE_TEMPLATE.md
• PULL_REQUEST_TEMPLATE.md
• CODE_OF_CONDUCT.md

• README atualizado com exemplos de uso
• Dockerfile e/ou compose testados
• CI mínima (build e lint) configurada
• Licença/atribuições corretas

Se você quer ser maintainer de um repositório da organização, abra uma issue com:

• Nome GitHub
• Repositório(s) que quer manter
• Experiência / motivação curta

Perfis de cargo sugeridos dentro da organização:

• Owner — administradores da organização (poucos).
• Maintainer — responsáveis por um ou mais repositórios.
• Contributor — contribuições avulsas.

Adotamos Apache-2.0 para os projetos da organização. Cada repositório deve conter um LICENSE e um CODE_OF_CONDUCT.md.

Se você preferir outra licença (MIT, GPLv3), adicione a justificação no repo antes de publicar.

Temos templates para:

• Frontend (Next.js) — template-front-nextjs
• Backend (Java Spring / Node) — template-back-<stack>
• Infra (Terraform + Ansible) — template-infra-<cloud/onprem>
• GitHub Actions: lint, build, publish container, scanner de segurança

Também temos o repo infra-factory com os scripts/Actions que geram repositórios novos automaticamente.

Se o repositório criado usar runners self-hosted, documente no repo infra-runners:

• Como registrar um runner
• Labels usados (ex: linux,gpu,proxmox)
• Regras de segurança e acesso

Para Actions, inclua checks mínimos: lint, build, container-scan.

Crie uma issue no repositório infra-factory (desta de organização) preenchendo o template com:

• Título: <nome do projeto>
• Nome do sistema: <nome do sistema>
• Template escolhido.
• Local de deployment.
• Credenciais necessárias para deployment.

Um maintainer revisará e o repositório será criado quando aprovado.

• E-mail: jardimdesoftware@belojardim.ifpe.edu.br
• Issues: abra issues nos repositórios correspondentes