Política de Ciclo de Desenvolvimento de Software

Última atualização: 25 de março de 2026

Mantenedor: Projeto Rockxy (código aberto)

Visão geral

Este documento descreve como o projeto Rockxy desenvolve software. Por ser uma ferramenta de código aberto para desenvolvedores no macOS, mantemos padrões elevados de qualidade, segurança e transparência. Todo o código é auditável publicamente, e o processo de desenvolvimento reflete essa abertura.

Escopo

Esta política se aplica a todo o trabalho de desenvolvimento no Rockxy: o aplicativo principal, as ferramentas auxiliares, a infraestrutura de build e este site. Cobre desde a concepção inicial até a manutenção contínua.

Princípios fundamentais

  • Qualidade — entregamos software confiável, com bom desempenho e bem testado. Cada release passa por QA automatizado e manual antes de chegar a quem usa.
  • Segurança — segurança faz parte de todas as etapas. Como o Rockxy lida com tráfego de rede sensível, levamos isso a sério. Sem telemetria, sem coleta de dados, com auditoria regular de dependências.
  • Transparência — o código-fonte é público. O rastreador de issues é público. Decisões sobre arquitetura, prioridades e trade-offs são documentadas abertamente.
  • Comunidade — contribuições da comunidade fazem o Rockxy avançar. Mantemos diretrizes claras, revisão de código ágil e um ambiente de desenvolvimento inclusivo.

Etapas do SDLC

1. Concepção e escopo

Novas features e melhorias são propostas via GitHub Issues ou discussões da comunidade. Avaliamos propostas considerando impacto para quem usa, viabilidade técnica e alinhamento com o roadmap antes de alocar recursos.

2. Planejamento e arquitetura

Propostas aprovadas entram em fase de design, onde definimos arquitetura do sistema, identificamos dependências, avaliamos riscos e definimos critérios de aceitação. Mudanças significativas geram registros de decisão de arquitetura (ADRs) no repositório.

3. Desenvolvimento

Todo código é desenvolvido em feature branches e submetido via pull request. Todo PR passa por revisão antes do merge. Seguimos as convenções Swift e SwiftUI, usamos mensagens de commit com propósito e mantemos mudanças focadas e revisáveis.

4. Garantia de qualidade e testes

Mantemos testes unitários, testes de integração e um checklist de QA manual. Código sensível a segurança (interceptação TLS, gestão de certificados, configuração de proxy) recebe escrutínio extra. Testamos em todas as versões suportadas do macOS antes de cada release.

5. Deploy e release

Releases seguem versionamento semântico. Cada versão vem com uma entrada no changelog, build assinado e distribuição pelos canais oficiais do projeto. Usamos pipeline de build automatizado para garantir builds reproduzíveis.

6. Manutenção e evolução

Após o release, monitoramos feedback da comunidade, tratamos relatos de bug e lançamos patches quando necessário. Atualizamos dependências regularmente e acompanhamos alertas de segurança upstream de todo pacote de terceiros.

Equipe e dinâmica da comunidade

  • Mantenedores core — responsáveis por decisões de arquitetura, gestão de releases e direção de longo prazo.
  • Contribuidores — pessoas da comunidade que enviam código, documentação, traduções e relatos de bug. Todas as contribuições passam pelo processo padrão de revisão de PR.
  • Usuárias e usuários — enviam feedback, reportam issues e validam features. As opiniões de quem usa moldam o roadmap diretamente.

Documentação e compartilhamento de conhecimento

Mantemos documentação em vários níveis:

  • Comentários inline no código para detalhes de implementação não óbvios
  • Registros de decisão de arquitetura (ADRs) para escolhas de design importantes
  • Documentação para quem usa e guias de configuração
  • Diretrizes de contribuição e convenções de código no repositório
  • Posts técnicos aprofundados no blog de engenharia

Compliance e gestão de risco

Seguimos boas práticas da indústria para desenvolvimento de software seguro. Reduzimos risco de supply chain com auditoria regular de dependências, assinatura de código e builds em sandbox. Como o Rockxy não coleta dados de pessoas usuárias, a conformidade regulatória fica simplificada. Vulnerabilidades de segurança podem ser reportadas via nossa política de segurança.

Melhoria contínua

  • Retrospectivas pós-release para identificar melhorias no processo
  • Revisão periódica de ferramentas, dependências e infraestrutura de build
  • Feedback da comunidade integrado ao processo de desenvolvimento
  • Compartilhamento de conhecimento via blog e discussões abertas

Alterações nesta política

Atualizações desta política são versionadas no repositório do Rockxy no GitHub. A data de "última atualização" no topo reflete a revisão mais recente. Mudanças significativas são anotadas no changelog do projeto.

Contato

Se você tiver dúvidas sobre esta política ou sobre o nosso processo de desenvolvimento, abra uma issue no GitHub.