Ir para o conteúdo

🧪 Lançamento de Versão

Lançamento

À medida que fluxos de mudanças chegam ao branch de produção e são versionados em lotes, uma parte essencial da entrega/implantação contínua é produzir artefatos a partir de versões que podem então ser implantados em vários destinos.

Lançamentos são iterações de software implantáveis que você pode empacotar e disponibilizar para um público mais amplo baixar e usar.

Como determinamos quando criar um lançamento? Vamos ver...

Mostrar marco de entrega de artefatos de pacote


Exercício: Criar um Lançamento de Versões

Como você já pode imaginar, o GitHub fornece um evento que encapsula a atividade de criar uma tag e enviá-la para um repositório. Vamos automatizar o tratamento de tais eventos, para que possamos criar um lançamento quando necessário.


Implementar Criação de Lançamento

No explorador de arquivos, crie um novo fluxo de trabalho .github/workflows/continuous.delivery.yml da seguinte forma:

.github/workflows/continuous.delivery.yml
name: Package Delivery Artifacts & Create Release

on:
  push:
    tags:
      - "*-release"

permissions:
  contents: write

env:
  CI: true
  SITE_DIR: site

jobs:
  package-delivery:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - uses: actions/setup-python@v4
        with:
          python-version: 3.12
      - name: Install Python dependencies
        run: |
          python -m pip install --upgrade pip
          pip install -r requirements.txt
      - name: Build Site
        run: |
          python -m mkdocs build --clean --strict --verbose --site-dir '${{ env.SITE_DIR }}'
      - name: Archive Site
        run: |
          zip -r ${{ env.SITE_DIR }}.zip ${{ env.SITE_DIR }}
      - run: |
          echo "Site directory ${{ env.SITE_DIR }} content:"
          ls -al ${{ env.SITE_DIR }}

      - uses: actions/create-github-app-token@v1
        id: generate-app-token
        with:
          app-id: ${{ vars.APP_ID_ACTIONS_ASSISTANT }}
          private-key: ${{ secrets.APP_PRIVATE_KEY_ACTIONS_ASSISTANT }}

      - name: Draft release
        uses: actions/github-script@v6
        id: draft-release
        with:
          github-token: ${{ steps.generate-app-token.outputs.token }}
          script: |

            const response = await github.request(
              'POST /repos/{owner}/{repo}/releases',
              {
                owner: context.repo.owner,
                repo: context.repo.repo,
                draft: true,
                tag_name: '${{ github.ref }}',
                discussion_category_name: 'announcements',
                generate_release_notes: true,
                make_latest: 'legacy',
                headers: {
                  'X-GitHub-Api-Version': '2022-11-28'
                }
              }
            );

            console.dir(response);

            return response.data.id;

      - name: Upload release asset
        run: |
          curl -L \
            -X POST \
            -H "Accept: application/vnd.github+json" \
            -H "Authorization: Bearer ${{ steps.generate-app-token.outputs.token }}" \
            -H "X-GitHub-Api-Version: 2022-11-28" \
            -H "Content-Type: application/octet-stream" \
            "https://uploads.github.com/repos/${{ github.repository }}/releases/${{ steps.draft-release.outputs.result }}/assets?name=${{ env.SITE_DIR }}.zip" \
            --data-binary "@${{ env.SITE_DIR }}.zip"

      - name: Publish release
        uses: actions/github-script@v6
        id: publish-release
        with:
          github-token: ${{ steps.generate-app-token.outputs.token }}
          script: |

            const response = await github.request(
              'PATCH /repos/{owner}/{repo}/releases/{release_id}',
              {
                owner: context.repo.owner,
                repo: context.repo.repo,
                release_id: ${{ steps.draft-release.outputs.result }},
                draft: false,
                discussion_category_name: 'announcements',
                make_latest: 'true',
                headers: {
                  'X-GitHub-Api-Version': '2022-11-28'
                }
              }
            );

            console.dir(response);

Análise

  • Linhas 3 - 6

    O fluxo de trabalho de criação de lançamento será acionado por envios de tags e quando a versão da tag enviada tiver o sufixo de metadados -release.

  • Linhas 29 - 34

    Nos dois passos incluídos aqui, o site é compilado e arquivado como um artefato de lançamento.

  • Linhas 39 - 43

    Um GitHub App será usado como o ator para as operações que executaremos. Portanto, a ação actions/create-github-app-token@v1 é usada aqui para gerar um token de autorização para o aplicativo.

    O que é um GitHub App?

    GitHub Apps, muito semelhantes a contas de serviço e bots, são ferramentas que estendem a funcionalidade do GitHub. Você pode criar um GitHub App para fornecer flexibilidade e reduzir atrito em seus processos, sem precisar fazer login como usuário ou criar uma conta de serviço . GitHub Apps podem fazer coisas no GitHub como abrir issues, comentar em pull requests e gerenciar projetos. Eles também podem fazer coisas fora do GitHub com base em eventos que acontecem no GitHub. Por exemplo, um GitHub App pode postar no Slack quando uma issue é aberta no GitHub.

    Quando você usa o GITHUB_TOKEN do repositório para executar tarefas, eventos acionados pelo GITHUB_TOKEN, com exceção de workflow_dispatch e repository_dispatch, não criarão uma nova execução de fluxo de trabalho. Isso evita que você crie acidentalmente execuções de fluxo de trabalho recursivas. Por exemplo, se uma execução de fluxo de trabalho envia código usando o GITHUB_TOKEN do repositório, um novo fluxo de trabalho não será executado mesmo quando o repositório contém um fluxo de trabalho configurado para ser executado quando ocorrerem eventos de push.

    ~ Usando o GITHUB_TOKEN em um fluxo de trabalho

    Portanto, estamos autorizando operações como um GitHub App para permitir que a execução da operação acione ainda mais execuções de fluxo de trabalho, possivelmente.

  • Linhas 45 - 70

    Um lançamento rascunho é criado pela respectiva etapa, permitindo a modificação do lançamento antes de publicá-lo. O lançamento faz referência à tag que acionou o fluxo de trabalho.

  • Linhas 72 - 81

    Esta etapa aproveita a API ReST do GitHub para ajustar o rascunho de lançamento criado anteriormente, especificamente adicionando o arquivo arquivado criado na etapa Archive Site ao lançamento como um ativo.

  • Linhas 83 - 105

    Tendo rascunhado o lançamento e anexado ativos implantáveis a ele, a etapa Publish release finalmente publica o lançamento alterando o estado do atributo draft para false.


Fazer commit e publicar suas alterações

Você pode vincular suas alterações a uma issue

Lembre-se da issue que você criou anteriormente e seu respectivo número, você o usará para vincular suas alterações atuais à issue.

1
2
3
git add .
git commit -m "$(printf 'Criar um jogo de tetris para impulsionar o engajamento do site\n\n-Implementar automação de lançamento\n\n- Resolve #<NÚMERO-DA-ISSUE>')"
git push origin feature/tetris-game

📚 Recursos