WDD 330: Desenvolvimento Web Front-end II

S01 Atividade: Configuração do projeto em equipe

Visão geral

Esta atividade é a configuração e o início do projeto em equipe. Você não será obrigado(a) a se reunir de forma síncrona nesta semana com sua equipe, mas é altamente recomendado que você tente fazer isso.

Instruções da atividade

Configuração do projeto – Quadro do Trello

1. Faça login na sua conta do Trello.
2. Crie um workspace chamado "WDD 330" ou algo semelhante.
   Ajuda: Capturas de tela

   

   

3. Copie este quadro do Trello Sleep Outside para a sua conta.
   
   Ajuda: Capturas de tela

   

   

4. Convide as outras pessoas da equipe para o quadro usando os e-mails das contas do Trello.

   Lembre-se de continuar adicionando pessoas à medida que elas entrarem na equipe.

   Ajuda: Capturas de tela

   

   

5. Defina o quadro como Público, se necessário.
   Ajuda: Captura de tela

   

6. No trello.com, adicione cada pessoa da equipe à tarefa Team Activity W01: Setup project for all team members.

   Adicione pessoas a esta tarefa à medida que elas entrarem na equipe.

7. Mova a tarefa para a coluna Doing. Esta é a tarefa associada a esta atividade em equipe.

Configuração do projeto – Clonar repositório

1. Faça login no GitHub e clone este template de repositório Sleep Outside inicial clicando no botão "Use this template" para criar uma cópia do projeto em um novo repositório e dar um nome ao novo repo.
2. Vá para Settings > Manage Access do repositório clonado e adicione o restante da equipe como colaboradores.

Clonar e fazer build do projeto

1. Todas as outras pessoas da equipe precisam clonar este repositório da equipe para o próprio computador.
2. No VS Code, abra o diretório que contém o repositório clonado.
3. Abra uma janela de terminal e mude para o diretório do projeto.

   Abra o terminal no VS Code pressionando ctrl+~ para alternar o painel do terminal entre aberto e fechado.

   No VS Code, você pode usar o painel do terminal (ctrl+~ alterna o painel do terminal entre aberto e fechado). Quando você abre o terminal no VS Code, ele será automaticamente definido para a raiz do seu projeto.

4. Execute o comando de interface de linha de comando para listar (ls) ou o comando de diretório (dir) para listar todo o conteúdo do diretório/pasta atual. Certifique-se de ver package.json na lista de arquivos. Mude para o diretório correto do clone do projeto se você não vir esse arquivo.
5. Execute a rotina de instalação do gerenciador de pacotes do Node usando o terminal.

   >npm install

6. Observe que um novo diretório foi criado: node_modules
7. Este projeto vem com várias ferramentas integradas para ajudar a equipe a escrever código consistente e sem erros.
   Abra o arquivo package.json. Há duas seções para revisar inicialmente, devDependencies e scripts.
   • devDependencies contém todas as ferramentas necessárias para o desenvolvimento deste projeto. Executar npm install consultou esta lista para saber o que instalar.
   • scripts são atalhos para comandos de gerenciamento do projeto. Ele contém o seguinte

        "scripts": {
       "start": "vite",
       "build": "vite build --emptyOutDir",
       "lint": "eslint *.js src/**/*.js",
       "format": "prettier --ignore-path ./.gitignore --write \"./**/*.{html,json,js,ts,css}\"",
       "test": "jest"
       },

     • start: Isso executará o servidor de desenvolvimento. Você usará isso com mais frequência.
     • build: Isso preparará o código para ser implantado em produção. Uma pessoa da sua equipe deve ser designada para executar isso quando necessário.
     • lint: Isso executará o Eslint no código para procurar erros de estilo e sintaxe. Você deve fazer isso sempre que estiver pronto(a) para fazer commit. Certifique-se de corrigir quaisquer erros encontrados antes de fazer commit!
     • format: Isso executará o Prettier no seu código e formatará tudo de forma consistente. Você também deve fazer isso como uma etapa do seu processo de commit.
     • test: Isso executará o framework de testes Jest no seu código.

     Os comandos são executados no terminal. Se você quisesse iniciar o servidor de desenvolvimento, por exemplo, você digitaria npm run start no terminal. Se você quisesse executar o linter, você digitaria npm run lint.

8. Tente executar o linter agora.

   >npm run lint

   O que você viu? Abra o arquivo .eslintrc.json. Você pode ter notado que um dos erros sobre os quais ele está reclamando é que suas aspas devem ser todas simples.

   As aspas precisam ser aspas simples? Isso importa? Na verdade, não importa se você usa aspas simples ou duplas no seu código JavaScript. No entanto, é importante ser consistente. Sua equipe precisará concordar com um padrão e segui-lo. É por isso que o linter é usado para impor um padrão. Ele ajudará você a evitar erros e a tornar seu código mais legível.

9. Decida em equipe se vocês gostariam de usar aspas simples ou duplas. Em seguida, encontre a linha que se parece com isto: "quotes":["error", "single"] no arquivo .eslintrc.json. Se você quiser aspas simples, não faça alterações. Se você quiser aspas duplas, então altere a palavra "single" para "double".

   O arquivo eslintrc.json pertence à equipe. Se sua equipe discordar de alguma das regras que estão sendo aplicadas, altere-as. Apenas certifique-se de que todas as pessoas da equipe concordem com as alterações. Se você decidir se aprofundar na configuração de regras personalizadas do Eslint, talvez você queira obter a extensão LintLens para o VSCode.

10. Execute o seguinte comando:

    >npm run format

    Em seguida, execute o linter novamente. O que aconteceu? Peça para alguém corrigir quaisquer erros restantes e, então, faça commit e push das alterações.

    Cada pessoa da equipe deve executar os comandos format e lint antes de fazer commit após realizar quaisquer alterações ao longo do curso.

11. Execute o seguinte comando:

    >npm run start

    Este comando executa vários processos no código e inicia um servidor web em localhost:xxxx, em que xxxx é algum número de porta. Ele também deve abrir esse endereço no seu navegador padrão; se não abrir, você pode digitar esse endereço diretamente no navegador ou clicar no link no terminal.

    Você deve usar este servidor ao desenvolver seu projeto, em vez de algo como Live/Five Server.

12. Quando você terminar de trabalhar, você pode parar o servidor de desenvolvimento digitando ctrl c na mesma janela do terminal em que o processo está em execução. Isso o encerrará.

Publicação

1. Faça o build da distribuição usando o seguinte comando:

   npm run build

   Isso criará um diretório chamado dist.
2. Apenas 1 pessoa precisará fazer commit dessas alterações e fazer push delas para o GitHub.
3. Veja o repositório em github.com e observe que o diretório dist não foi transferido com o commit. Se você verificar o arquivo .gitignore que faz parte do projeto, você verá o motivo.
4. Você usará uma plataforma chamada Render para hospedar o site do aplicativo web ao vivo.
   ✔ Crie uma conta gratuita no render usando as credenciais do GitHub e faça login para a próxima etapa.
5. Após fazer login, você precisa adicionar um novo Static Site. Clique no botão "+ New" no topo e selecione GitHub.
6. Selecione o repo que contém o projeto sleepoutside.
7. Selecione a branch "main" e confirme estas configurações antes de fazer o deploy:
   • Build Command: npm install && npm run build
   • Publish Directory: dist
   Em seguida, Deploy Static Site. O Render produzirá uma URL aleatória para o site, que deve ser compartilhada com todas as pessoas da equipe.
   Este é o link para o seu site de "produção".

   ✔ A versão build do site será considerada a versão de produção. Este site do aplicativo deve sempre estar funcionando. O Render atualizará seu site sempre que detectar uma alteração na branch "main" do GitHub. Portanto, depois que pull requests forem revisados e mesclados, você provavelmente deve acessar a URL do Render para garantir que nada quebrou.

Conflitos de merge

1. Pull das alterações do GitHub.
2. Se ainda não existir, crie um arquivo na raiz do projeto chamado team.txt.
3. Certifique-se de que há um link para o quadro do Trello da equipe no arquivo de texto.
4. Adicione seu nome ao arquivo de texto.
5. Em seguida, faça commit dessa alteração e push para o GitHub.
6. O que aconteceu? Isso deve ter resultado em um erro no Git se mais de uma pessoa tiver editado, feito commit e feito push do arquivo.

   Houve várias alterações feitas no mesmo arquivo e o Git não sabe qual manter. Isso resulta em um conflito de merge (mesclagem). Como os conflitos podem ser evitados? Algumas formas:

   • Primeiro, certifique-se de que, sempre que você se sentar para trabalhar no projeto, você deve fazer pull antes de qualquer outra coisa, para garantir que você obtenha alterações que qualquer pessoa da sua equipe tenha feito recentemente.
   • Faça commit com frequência! Commits pequenos têm menos probabilidade de resultar em conflitos do que commits grandes ...e são muito mais fáceis de corrigir se um conflito ocorrer.
   • Aproveite técnicas de design de software como módulos para dividir seu código em partes menores.
   • Por fim, aproveite a capacidade do Git de criar branches. Branching é apresentado na atividade extra abaixo.
7. Antes de você poder fazer commit, o conflito de merge (mesclagem) precisará ser resolvido. Certifique-se de que o arquivo team.txt esteja aberto. Você deve ver algumas adições ao arquivo feitas pelo Git. Ele deve se parecer com algo como abaixo.

   

   Você deve decidir qual código deve ser mantido.

   • O conteúdo do código sob <<<<<<<•HEAD é o código que você estava tentando enviar.
   • O conteúdo do código sob ======= é o código que já estava no GitHub.
   • Se você quiser manter o código que acabou de escrever e descartar o outro, você pode escolher "Accept Current Change".
   • Se você quiser manter o que estava no GitHub e remover suas alterações recentes, escolha "Accept Incoming Changes".
   • Ou, se você escolher "Accept Both Changes", ele mesclará os dois conjuntos de alterações. Isso geralmente é a forma mais rápida de eliminar o conflito, mas normalmente exige mais trabalho para realmente corrigir o problema.
   • Neste caso, aceite ambos e, então, exclua o nome sem a inicial. Isso nos deixaria com as versões mais atuais de tudo.
8. Depois de corrigir o código, você precisará fazer commit do merge.
9. Faça push das suas alterações para o GitHub.

Atividade extra

Um dos recursos mais poderosos do Git é a capacidade de criar branches do código. Branching cria uma cópia do código do projeto no ponto atual no tempo, de modo que as alterações sejam feitas sem afetar qualquer outra branch. Isso permite que uma organização sempre mantenha uma versão de produção totalmente funcional do código do aplicativo, que pode ser implantada a qualquer momento, enquanto também trabalha em atualizações que normalmente podem causar uma interrupção no serviço do aplicativo.

Você também pode usar branches para reduzir conflitos de merge se várias pessoas da equipe precisarem fazer alterações no mesmo arquivo em uma base de código.

Instruções de prática de branching

1. Crie uma nova branch. Dê à sua branch um nome como yourinitials--branch-test.
2. Adicione um arquivo na raiz do projeto chamado yourname.txt.
3. Digite seu nome no arquivo de texto e salve.
4. Faça commit e publique (push) sua branch no GitHub.
5. Conclua um pull request depois que as outras pessoas da equipe tiverem feito push de suas próprias branches.
6. Mude para uma das novas branches no repositório. Observe o que acontece com a listagem de arquivos no seu editor quando você faz isso.
7. Mude de volta para sua própria branch.
8. Mude de volta para a branch main.
9. Converse com sua equipe sobre o que você viu.

Pull requests

Quando você terminar o recurso para o qual criou uma branch, o novo código deve ser mesclado de volta na branch main. Isso pode ser feito de duas formas:

• mesclando diretamente a branch de trabalho de volta na branch main, ou
• executar um pull request.

Em projetos em que há apenas 1 pessoa desenvolvedora, mesclar diretamente funciona. No entanto, ao trabalhar com uma equipe, é mais comum trabalhar por meio de pull requests. Um pull request essencialmente significa: "Meu trabalho está concluído e testado, estou pronto(a) para que o código seja mesclado na branch main. Alguém pode verificar e garantir que você não vê nenhum problema. (Para eu não quebrar nada 😁)"

Neste caso, agora, as branches não contêm nada importante que precise ser mesclado de volta na branch main. Então, a maioria delas pode simplesmente ser excluída.

1. Peça para 1 pessoa da equipe, que não seja o(a) driver, enviar um pull request da própria branch para observar como é o processo.
2. Depois que o pull request for feito, o(a) driver deve ir ao repositório no GitHub, revisar a solicitação e, então, concluir o merge.
3. Certifique-se de que quaisquer branches extras sejam excluídas quando a mesclagem for concluída.
4. Mova o cartão Team Activity W01 no Trello para "Done".

Solução de exemplo

Entrega

Volte ao Canvas para relatar seu trabalho na atividade e suas contribuições.