Ir para o conteúdo principal

Processo de Desenvolvimento

Giveth TRACE foi oficialmente descontinuado. Depois de 5 anos de serviços, Giveth e suas plataformas, serviços e produtos migraram totalmente para Giveth.io. Com a descontinuação da rede Rinkeby e a baixa frequência de usuários, o Giveth DAO decidiu encerrar seu dApp original no terceiro trimestre de 2022. O código é e sempre será aberto. Você pode encontrá-lo nestes repositórios do Github.

Toda a documentação do Giveth TRACE vai permanecer disponível para referência histórica.


*Essa seção detalha o processo de desenvolvimento da Giveth TRACE, implantações e como a mesclagem e o teste são tratados.

Planejamento de desenvolvimento, Sprints e onde se envolver.

Executamos um ciclo de sprint de 2 semanas com reuniões semanais de desenvolvedores para planejar sprints e avaliar o progresso. Você pode verificar quando é a próxima no nosso Google Agenda e também entrar em contato pelo Giveth Discord com o @moenick, o gerente do projeto Giveth TRACE. Também é possível encontrar o repositório Giveth TRACE no Github.

Implantações e Organização de Branch

Giveth TRACE fez a transição de desenvolvimento passivo para ativo para lançamento pós-beta em breve. Existem duas implantações usadas para o processo de desenvolvimento atualmente.

NomeBlockchainBranch DeployedAuto DeployUtilização
betaMainnet/RinkebymasternãoImplantação em bridge; Rinkeby para interações contratuais internas, Mainnet para enviar e receber fundos reais.
developRopsten Test NetworkdevelopsimAmbiente de desenvolvimento para integração e teste de novos recursos. Branches de recurso e pull requests são implantados nesse ambiente.

As duas Branchs abaixo estão sendo usadas no gitflow.

NomeDescrição
masterA Branch master rastreia apenas o código liberado. Os commits são feitos para master no meio de cada mês para não interferir nos processos de pagamento que acontecem perto do final e do início desses meses.
developAs implantações feitas para desenvolver são de compilações locais e incluem novos recursos e correções de bugs.

Uso da Boards Zenhub

Atualmente, usamos a extensão Zenhub Boards para Github para acompanhar o progresso dos recursos e correções. Você pode obter a extensão Zenhub aqui.

O fluxo de problemas do Github atual é o seguinte:

NomeUtilização
Novos ProblemasCrie um novo problema para uma nova solicitação de recurso ou para relatar um bug. Marque um desenvolvedor ou @moenick para garantir que seja notado. Use rótulos para adicionar contexto ao seu problema.
IceboxRecursos e ideias a serem considerados para desenvolvimento futuro, a serem avaliados pela equipe Giveth somente quando a largura de banda do desenvolvedor permitir.
Lista de pendências do produtoQuestões que precisam ser tratadas ou novos recursos aprovados para desenvolvimento. Estes serão enfileirados no próximo sprint progressivamente.
ÉpicasGrandes tarefas que foram divididas em questões menores.
Precisa de EsclarecimentoProblemas que exigem mais esclarecimentos do criador do problema para avançar.
Sprint BacklogProblemas que estão sendo trabalhados no sprint atual.
Bugs & Opstarefas urgentes que precisam ser priorizadas. A largura de banda é reservada no cronograma do sprint para os desenvolvedores resolverem quaisquer problemas aqui.
Em ProgressoProblemas que foram selecionados por um desenvolvedor para o sprint atual.
Revisão de códigoOs desenvolvedores devem revisar o código referenciado nesses problemas para garantir a qualidade e corrigir possíveis problemas antes de passar para o teste do usuário.
UAT (User Acceptance Testing)Recursos ou correções prontas para serem testadas pelo usuário.
DoneQuestões prontas para serem mescladas ao master de acordo com o ciclo de confirmação.

Fazendo uma Pull Request

Antes de fazer uma nova Pull Request, certifique-se de que seu código não tenha problemas de linter e possa ser implantado. Somente PRs implantados com êxito e que não tenham conflitos de mesclagem serão mesclados. Você também pode verificar facilmente a visualização de implantação na integração de implantação automática do Github Netlify.

Integração de implantação automática Visualização de implantação. Cada solicitação de pull para o repositório DApp tem uma visualização de implantação do Netlify. Você pode acessá-lo na parte inferior pelo botão ''Conversa'' depois de clicar no botão Mostrar todas as verificações e em Detalhes.

Integração e Teste

A integração de novos recursos é feita pela equipe de desenvolvimento após uma reunião de desenvolvimento do DApp onde os PRs são revisados. Depois que os PRs são revisados ​​e corrigidos, eles são mesclados à ramificação de desenvolvimento. O teste dos novos recursos é feito no ambiente develop para garantir que os recursos façam o que dizem e funcionem bem com o restante do DApp.

## Teste de garantia de qualidade

Depois que os novos recursos forem integrados e testados pelos desenvolvedores no ambiente develop, os desenvolvedores enviarão pings aos testadores com solicitações ou atualizações no [Giveth TRACE Dev Channel](https://discord .gg/79uUbyVCtE) no Discord. O teste não deve ser feito por desenvolvedores e está aberto a qualquer pessoa que deseje contribuir.

Implantação de Produção

Apenas uma vez que todos os bugs recém-introduzidos são removidos na branch develop, ele pode ser mesclado para master e enviado para produção. Isso é feito manualmente pelo DApp devteam (construído por @aminlatifi e @MohammadPCh).

Para implantar a versão mais recente do feathers-giveth

$ ssh user@feathers.alpha.giveth.io

$ cd /home/deploy/feathers-giveth/
$ sudo -u deploy bash

$ git pull

$ yarn install --pure-lockfile
$ yarn serve

Em seguida, verifique o status de implantação dos feathers

$ pm2 logs

Se os logs estiverem limpos, a última etapa é implantar o commit da branch master mais recente no Netlify e bloquear o deploy.

Documentação de serviços da Web de back-end

Se você é um novo colaborador e gostaria de uma documentação técnica mais detalhada sobre todos os Webservices aproveitados desde o back-end (feathers-giveth) até o front-end (giveth-dapp), confira nossas páginas em Swagger para implantações de produção e preparação:

feathers-giveth Production
feathers-giveth Staging

FAQ

Qual é a definição de um recurso?

Um recurso é qualquer melhoria não trivial (menos de 10 linhas de código). A maioria dos recursos tem problemas no repositório Github correspondente.

E as correções?

Grandes correções não críticas são tratadas como qualquer outro recurso. Se uma correção for crítica no tempo, ela será criada como uma nova branch com o prefixo hotfix/ como uma bifurcação da branch master. Esse hotfix é testado no mínimo por 2 pessoas da equipe de desenvolvimento antes de ser mesclado aos ramos master e develop.

Onde comunicamos o que precisa ser testado?

O teste de controle de qualidade é anunciado no canal Giveth-1 Dev no Discord.

Como priorizamos quando os testes falham/correções de bugs?

As correções de bugs são feitas ad-hoc assim que são descobertas durante o processo de teste. Os bugs podem ser resolvidos pela equipe de desenvolvimento do DApp ou pode-se pedir ajuda a contribuidores externos. A correção de bugs tem prioridade sobre o novo desenvolvimento.

Quem faz as implantações e como elas são implantadas?

A branch develop é implantada automaticamente em seu ambiente. A branch master é implantada pela equipe de desenvolvimento (@aminlatifi, @RamRamez e @MohammadPCh) uma vez que não há novos bugs conhecidos na branch develop. O processo é manual e existe um procedimento de implantação.

Qual é a frequência do ciclo de lançamento?

Há uma nova versão a cada 2 semanas, conforme descrito no gráfico de gant do ciclo de desenvolvimento do produto.