Estamos escrevendo um projeto. Adicione SpringBoot e configure um processo de CI - "Projeto Java de A a Z"

Um artigo de uma série sobre a criação de um projeto Java (links para outros materiais estão no final). Seu objetivo é analisar tecnologias-chave, o resultado é escrever um bot de telegrama. Saudações, queridos leitores. Conforme descrito na parte anterior , iremos conforme o planejado. Já criamos um projeto e é hora de preenchê-lo com código. Agora todos os problemas serão adicionados como commits separados. Descreverei tudo o que é necessário aqui. Se eu perder alguma coisa ou não descrever com clareza suficiente, pergunte nos comentários, tentarei responder.

Escrevemos JRTB-0M

Nesta tarefa, precisamos adicionar uma estrutura SpringBoot vazia para trabalhos futuros. Faremos isso da mesma forma que fizemos no artigo sobre SpringBoot + Flyway . Baixe o projeto , abra-o no IDEA e crie um novo branch chamado JRTB-0 . Descrevi como fazer isso através de uma ideia aqui . Isso tornará mais fácil para nós acompanhar o trabalho no futuro. Você já sabia que não existe mais branch master ? Agora é chamado de neutro- principal . Então a gente se acostuma. Embora, para ser honesto, sempre possamos renomeá-lo de volta para master. Vamos ao Spring Initializr e criamos uma estrutura SpringBoot para nosso bot. No momento, a versão mais nova do boot sprint oferecida é a 2.3.7, vamos lá. Descreverei as seguintes configurações separadamente:

• Projeto: Projeto Maven - já discutimos o Maven aqui e aqui . Portanto, descreverei adicionalmente apenas o que não revelei em artigos anteriores. Se houver tais “manchas brancas”, é claro)
• Linguagem: Java - tudo está claro aqui. Se desejarmos, podemos reescrever este assunto em Kotlin. Acabei de comprar um livro Kotlin em ação, aprenderemos Kotlin juntos))
• Spring Boot: 2.3.7 - utilizamos a menor versão oferecida para eliminar quaisquer problemas. Esta já é uma versão totalmente moderna da bota.

Metadados do projeto:

• Grupo: com.github.javarushcommunity - aqui selecionamos o domínio no qual nosso grupo de repositórios está hospedado.
• Artefato: javarush-telegrambot - descrição máxima do projeto.
• Nome: Javarush TelegramBot - escreveremos na íntegra aqui.
• Descrição: Bot Telegram para Javarush de comunidade em comunidade - aqui está uma descrição mais detalhada do projeto.
• Nome do pacote: com.github.javarushcommunity.jrtb - aqui você já pode usar uma abreviatura para o nome do projeto. Agora o projeto começará com este pacote. Por que tantos? Para que quando adicionarmos outros projetos ao classpath, eles estarão em pacotes diferentes. Cada um à sua maneira única. Isso é importante para manter os princípios OOP.
• Embalagem: Jar é nosso padrão)
• Java: 11 - estaremos um passo à frente. Não acho que usarei inovações após o oitavo Java, mas deixe estar. Ele não pede comida)... esta decisão nos dará um pequeno ovo de Páscoa no futuro)

Não adicionaremos nenhuma dependência por enquanto. Não precisamos disso para esta tarefa. Depois de preencher tudo isso, obtemos (aqui está um link para o projeto gerado): Depois de preencher, clique em GERAR e adicione todos os internos do arquivo ao nosso projeto. Adicione arquivos ao projeto. Como resultado, temos um aplicativo. Para verificar se está montado, vá até o terminal e escreva: $ mvn clean package Se você tem o mesmo daqui, está tudo ok: o projeto está montado e o jarnik já está pronto na pasta de destino. Neste ponto, a tarefa dentro da descrição está pronta. É simples, certo? Portanto, fazemos commit e push para nosso branch: Adicionamos o nome da nossa tarefa no início da descrição do commit, para que posteriormente fique claro dentro da estrutura de qual tarefa o trabalho foi realizado. Clique em Commit e Push ... Mais uma vez revisamos e verificamos o que exatamente queremos enviar do repositório local para o remoto e, certificando-nos de que está tudo bem, clique em Push . Qual é o nosso próximo passo? De acordo com todas as regras (que podem ser lidas neste artigo , na parte sobre fluxo do GitHub), você precisa criar um pull request para o branch principal e esperar que alguém da equipe revise o código. Como estou sozinho, criarei formalmente uma solicitação pull e revisarei tudo novamente. Vou para a página do repositório, e o Github já sabe que temos um complemento e se oferece para criar um pull request: Não há obstáculos para patriotas (c) - nós o criamos, conforme sugerido. Definimos o mesmo rótulo, projeto da tarefa em que estamos trabalhando e preenchemos a descrição: Clique em Criar solicitação pull .

Configurando o processo de CI

Vamos para o pull request criado: abaixo vemos que não temos a Integração Contínua configurada (doravante - CI). Bem, não está configurado, e daí? Por que precisamos de CI? Afinal, o que é CI? Esta é aproximadamente a lista de questões que devem nos preocupar neste momento. Em geral, CI é um processo contínuo de fusão de código em uma base de código comum e execução de uma construção do projeto antes disso. O chamado build (do inglês build). Cada vez que construímos um projeto, garantimos que o projeto foi compilado, todos os seus testes foram aprovados com êxito e, após a construção do projeto, você pode adicionar autotestes de testadores ao CI que são executados nesta compilação específica. Dessa forma, ficamos mais confiantes de que as novas mudanças funcionarão conforme esperamos e não quebrarão a funcionalidade anterior. CI também é bom porque inicia automaticamente após atualizar a base de código. Ou seja, empurramos nossas alterações para a filial e o processo começou – montagem, testes, autotestes e outras etapas. Se alguma dessas etapas falhar, a compilação será considerada quebrada e não poderá ser mesclada na ramificação principal. É exatamente isso que faremos agora: adicionaremos GitHub Actions, que executará nosso código após o push. GitHub Actions se encaixa perfeitamente em nosso GitHub Flow, então vamos usá-lo para automatizar nosso trabalho. Esta ferramenta é muito poderosa e grande, mas por enquanto só a usaremos para executar a compilação e verificar se ela está montada conforme necessário. Para habilitá-lo, encontre o botão Ações na página do repositório e siga-o: Encontre o fluxo de trabalho de Integração Contínua que precisamos: Clique em Configurar este fluxo de trabalho. A seguir, nos é oferecido o uso do template deles: concordamos plenamente, vamos apenas esclarecer tudo um pouco:

# This workflow will build a Java project with Maven
# For more information see: https://help.github.com/actions/language-and-framework-guides/building-and-testing-java-with-maven

name: Java CI with Maven

on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

jobs:
  build:

    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v2
    - name: Set up JDK 1.8
      uses: actions/setup-java@v1
      with:
        java-version: 1.8
    - name: Build with Maven
      run: mvn -B package --file pom.xml

Isso indica que GitHub Action é chamado em dois casos:

1. Quando um push é feito no branch principal.
2. Quando uma solicitação pull é criada na ramificação principal.

A seção de trabalhos descreve as etapas que serão executadas. Temos apenas uma etapa: construir. Mostra que nosso projeto será lançado no Ubuntu com o comando mvn -B package --file pom.xml . Isto é exatamente o que fizemos localmente. Se você quiser mudar alguma coisa aqui, por favor. Vou usar este modelo, será o suficiente para mim. Clico em Start commit , selecione create a new branch para configurar o processo e então Propose new file . Mas o processo de construção caiu... Como você pode ver, Falha após 14s - construção. Parece que algo aconteceu: vamos passar à montagem e ver os detalhes: Diz que não consegui encontrar tal memória. Por que? Ahhh, exatamente, exatamente! Porque criamos alterações no branch master, mas nossa tarefa ainda não chegou. E é por isso que ele não encontrou a memória... Portanto, agora fazemos o seguinte: fundimos esses dados no master, depois fundimos o branch principal no JRTB-0, e então tudo deve correr bem. Em uma solicitação pull com alterações de ações do github, clique em Mesclar solicitação pull : e repita Confirmar mesclagem . A seguir, o Github nos solicita que excluamos o branch em que trabalhamos. Não recusamos e excluímos: A seguir, não encontrei no pull request do SpringBoot como extrair alterações do branch principal do site, então faremos isso manualmente através do IDEA.

Etapa 1: atualize o branch master para o repositório local.

A ideia é ir até o branch master, pressionar ctrl + t e atualizar o branch master:

Etapa 2: Mesclar as alterações da ramificação master para a ramificação JRTB-0.

Vamos para o JRTB-0 e mesclar o principal nele.

Etapa 3: enviar alterações.

Pressione ctrl + shift + k e confirme o push. Agora estamos esperando a construção passar e ficará verde!)) Mas está vermelho novamente. O que é? Entramos nos logs de ações e vemos que estamos fora de sincronia nas versões Java. No GitHubActions é 8, mas usamos 11: Agora existem duas opções: ou corrigir as ações ou diminuir a versão para a oitava. A primeira opção, parece-me, é melhor e mais correta. Estamos fazendo alterações em um commit separado: não trabalharemos com Java 8, mas com Java 11. E depois disso, finalmente, tudo deu certo para nós e conseguimos montar nosso processo de CI para o projeto. Essas coisas precisam ser configuradas no estágio inicial, para que você não precise se preocupar com isso mais tarde. Agora você pode ver que a build passou e pode mesclar sem medo:

Configurando o trabalho com ramificações no repositório

Você também pode configurar coisas no repositório como regras ao trabalhar com ramificações. Quero fazer com que o branch principal não possa ser enviado diretamente, mas apenas por meio de solicitações pull, e quero fazer com que seja impossível mesclar uma solicitação pull se a compilação falhar (ou seja, se as ações do GitHub falharem em algum passo). Para fazer isso, encontre o botão Configurações e selecione Filiais : No momento não há regras para filiais, então vamos adicionar uma nova através do botão Adicionar regra : Há muitas configurações aqui e todos podem fazer algo de acordo com suas necessidades. precisa. Para que a compilação seja aprovada com êxito na solicitação pull antes da mesclagem, adicione uma caixa de seleção para Exigir que as verificações de status sejam aprovadas antes da mesclagem e selecione o status que precisamos - compilação. Por enquanto é o suficiente: depois você pode atualizar esse volante e ver o que mais deseja. Clique em Criar para criar este volante. A seguir, se formos ao nosso pull request novamente, podemos ver que nossa verificação agora está marcada como obrigatória: Vamos verificar a página do nosso projeto, que exibe todos os status das tarefas: Você pode ver imediatamente em qual tarefa está sendo trabalhada. Além disso, o trabalho já foi realizado e a tarefa está em status de revisão de código.

Fechando JRTB-0

Agora que preparamos um pull request e fizemos um CI para ele, precisamos concluir a última etapa: fechar a tarefa, movê-la para o status correto, ver as alterações em nosso projeto no quadro. Nossa solicitação pull está pronta para ser mesclada no mestre. Na solicitação pull, clique no botão Mesclar solicitação pull : após uma mesclagem bem-sucedida, você pode excluí-la, e geralmente faz isso. Não farei isso para facilitar a visualização de alterações entre ramificações/commits. Assim que um pull request é mesclado, ele passa automaticamente para feito em nosso quadro de projeto: A última etapa é fechar o problema (issue) com um link para o pull request em que ele estava: Este problema vai automaticamente para feito no quadro. O começo foi feito, a primeira tarefa está cumprida!

conclusões

Parece que já começamos a trabalhar e escrever código, mas ainda precisamos de configurações. Sim, leva tempo, mas terá um retorno cem vezes maior quando o projeto se tornar maior e mais complexo e você precisar de garantias de que não quebrará tudo com um único commit. A solicitação pull onde tudo isso acontece está disponível aqui . Talvez, quando você ler, já esteja fechado. Não é assustador: todas as informações necessárias serão armazenadas através do link. Obrigado a todos pela leitura, até breve. Além disso!

Uma lista de todos os materiais da série está no início deste artigo.