Use pipelines do Azure DevOps para criar e testar aplicativos Node.js e, em seguida, implantar ou publicar no serviço de aplicativo azure. A seguir estão as etapas a serem realizadas para um fluxo de trabalho de CI / CD completo.
1 - Desenvolva e comprometa seu código no branch de desenvolvimento.
2 - Envie o código do branch de desenvolvimento para → branch de teste → branch master.
3 - Implante seu código em ambientes diferentes; Dev → Teste → Prod usando pipelines CI / CD no Azure DevOps.
Crie um pipeline de build
Acesse dev.azure.com/{organisation-name} → Selecione Projeto → Pipelines
- Create New Pipeline → Use Azure Git Repos (YAML) para criar um pipeline como código ou use the classic editor para criar um pipeline a partir do designer visual. Para este tutorial, usaremos o editor clássico.
- Select a source repo → Select Project Name → Select Repository → Select Branch Name → Click no Continue.
- Selecione o modelo como um Trabalho vazio.
- Altere o nome do pipeline de build de acordo com a convenção de nomenclatura de sua organização → Selecione Pool de agentes de acordo com o requisito {Hosted vs2017-win2016 for Windows Environment & Hosted Ubuntu 18.04 for Linux based environment}.
- Pense nesses agentes como máquinas virtuais com diferentes sabores de sistema operacional.
- Prefira usar Microsoft Hosted Agents em vez de Self Hosted Agents, a menos que você saiba o que está fazendo
- Selecione Fontes de tag → em caso de sucesso para criar tags git sempre que sua construção for bem-sucedida. Você pode manter o formato da tag como $ (build.buildNumber) ou v $ (build.buildNumber).
- Clique em Add Tasks(+) → procurar por tarefa → Add Task
- Você pode adicionar várias tarefas.
- Se uma tarefa não estiver disponível em sua organização, você pode instalá-la a partir do Marketplace.
Detalhes da Tarefa
- Instalador da ferramenta Node.js - localiza ou baixa e armazena em cache a especificação da versão especificada do Node.js e a adiciona ao PATH
- A versão mais recente do Node.js LTS já está instalada no agente e é gerenciada pela Microsoft. Se você estiver usando uma versão específica do Node em seu projeto, use esta tarefa para especificar a versão exata que deseja usar.
- NPM Task - instale e publique pacotes npm ou execute um comando npm. Suporta npmjs.com e registros autenticados como artefatos do Azure.
- Comandos disponíveis: CI, Instalar, Publicar, Personalizar.
- Para comandos personalizados, não há necessidade de prefixar npm.
- Diretório raiz que contém a pasta do pacote: $ {Build.SourcesDirectory} - É uma variável predefinida. O caminho local no agente onde seus arquivos de código-fonte são baixados. Por exemplo: c: \ agent \ _work \ 1 \ s. Essas variáveis são definidas automaticamente pelo sistema e somente leitura.
- Mais informações sobre variáveis predefinidas: Vá para Variáveis Predefinidas
- Pode haver várias versões de uma tarefa. Certifique-se de usar a versão estável e evite usar versões de visualização.
- O comando
npm installinstalará o devDependencies junto com outras dependências ao executar dentro de um diretório de pacote, em um ambiente de desenvolvimento (o padrão). - Cada vez que uma nova construção é acionada, haverá uma nova instância do Agente que não conterá nenhum cache npm.
- Evite instalar devDependencies em um ambiente de produção. Use o Custom command → install — only=prod
- Podemos adicionar tarefas npm para teste de unidade, linting, etc. Se os testes forem bem-sucedidos, o único pipeline será bem-sucedido.
- Use variáveis de ambiente para parametrizar os comandos. Use run build - $ (nome da variável) → Vá para a guia Variáveis → Add Variable → variable-name → value
- Arquivar arquivos: compactar arquivos em .7z, .tar.gz ou .zip.
- Faremos a implantação do zip para reduzir o tempo de implantação. Também podemos usar a tarefa de cópia para criar artefato, mas como haverá um grande número de arquivos, será mais lento em comparação com uma implantação zip. Encontre mais sobre a implantação do zip aqui.
- Especifique a pasta / diretório que deseja archive. eg. public/out.
- Especifique o nome do arquivo a ser criado.
- Anexe o nome da pasta raiz → esta caixa de seleção criará uma pasta com um nome de arquivo e colocará todos os arquivos dentro dessa pasta antes de arquivar.
- Substituir o arquivo existente - esta caixa de seleção excluirá o arquivo anterior antes de criar um novo arquivo em cada nova construção.
- Publique artefatos de compilação: publique artefatos de compilação no Azure Pipelines ou em um compartilhamento de arquivo do Windows.
- Manter as configurações padrão.
- Você pode fornecer um nome de artefato customizado.
- Habilite a integração contínua para acionar o pipeline de construção sempre que qualquer alteração for feita na filter-branch.
- O formato do número da compilação criará o número da compilação como Major.Minor.Patch.UniqueID → 1.0.0.1 (Versão semântica)
- O controle de versão semântico de buildId fará mais sentido do que apenas ter um número exclusivo como buildId.
- Build.BuildId é uma variável predefinida que é incrementada sempre que uma nova construção é atribuída ao nível da organização (1,2,3… .n).
- Adicione as variáveis Major, Minor e Patch na guia de variáveis.
- Major- 1, Minor- 0, Patch- $[counter(format(‘{0}.{1}’, variables[‘Major’], variables[‘Minor’]), 0)]
- A variável Patch começará a partir de 0 e incrementará toda vez que uma nova compilação for acionada. Ele será redefinido para 0 quando o valor Principal ou Secundário for alterado / incrementado.
- Mantenha essas duas variáveis configuráveis no tempo de execução para que a equipe do aplicativo possa alterar as versões principais / secundárias durante o tempo de execução.
- Também podemos agendar o tempo de construção
- Guia Histórico: para visualizar o histórico das alterações feitas no pipeline de construção e comparar as diferenças.
- Pipelines também podem ser revertidos para seu estado anterior usando a opção Reverter Pipeline.
E se você tiver que criar muitos pipelines em seu projeto que usarão o mesmo conjunto de tarefas?
Grupos de tarefas: Se houver tarefas semelhantes em pipelines diferentes, no mesmo projeto ou em projetos diferentes, você pode criar grupos de tarefas a partir das tarefas de pipeline existentes, conforme mostrado na figura. Selecione todas as tarefas e clique com o botão direito → selecione Criar grupo de tarefas.
- Se os argumentos forem diferentes nas tarefas, então você pode escrevê-lo como variável $ (nome-da-variável) e ele pedirá o valor ao adicioná-lo como um grupo de tarefa, conforme mostrado na imagem abaixo.
Podemos exportar e importar os grupos de tarefas para usá-los em vários projetos do Azure DevOps.
Criar um Release Pipeline
Vá para dev.azure.com/{organisation-name} → Selecione Projeto → Pipelines → Releases.
- Novo pipeline → Selecionar trabalho vazio
- Renomear estágio
- Clique em Adicionar um artefato → selecione o pipeline de compilação de origem → Versão padrão: Mais recente → Alias do artefato: Padrão → Adicionar
- Alias de origem: criará uma pasta no Agente com o mesmo nome de alias de origem (_Medium-Blogs-CI-Prod no nosso caso). Os artefatos serão armazenados nesta pasta no agente.
- Habilite a implantação contínua. Sempre que um novo build associado a este pipeline estiver disponível, uma nova versão será acionada.
- Habilite Branch Filter para acionar a liberação apenas de filiais selecionadas.
- Editar Nome do pipeline → Adicionar tarefa: Implantar Serviço de Aplicativo do Azure
- Vá para o trabalho do agente → Selecione o pool do agente de acordo com o requisito {Hosted vs2017-win2016 para ambiente Windows e Ubuntu 18.04 hospedado para ambiente baseado em Linux}.
- Prefira usar Microsoft Hosted Agents em vez de Self Hosted Agents, a menos que você saiba o que está fazendo
- Selecione o tipo de serviço de aplicativo como Web App no Windows (tarefa versão 4) / Web App (tarefa versão 3) para a máquina baseada em Windows.
- Implementar no Slot será verificado apenas para pipelines de produção
- Pacote ou pasta: $ (System.DefaultWorkingDirectory) / ** / *. Zip → Esta opção encontrará qualquer arquivo zip no diretório de trabalho padrão. Exemplo de localização: - Artefatos vinculados → Alias do artefato → Nome do artefato → $ {BuildId} .zip]
- Opções adicionais de implantação: se desmarcado, ele detectará automaticamente o melhor método de implantação com base no tipo de aplicativo, formato do pacote e outros parâmetros. Selecione a opção de visualizar os métodos de implantação com suporte e escolha um para implantar seu aplicativo.
- Colocar o Aplicativo Offline: selecione a opção para colocar o Serviço de Aplicativo do Azure offline, colocando um arquivo app_offline.htm no diretório raiz do Serviço de Aplicativo antes do início da operação de sincronização. O arquivo será removido depois que a operação de sincronização for concluída com sucesso.
- Remover arquivos adicionais no destino: selecione a opção de excluir arquivos no Serviço de Aplicativo do Azure que não possuem arquivos correspondentes no pacote ou pasta do Serviço de Aplicativo. Observação: isso também removerá todos os arquivos relacionados a qualquer extensão instalada neste Serviço de Aplicativo do Azure. Para evitar isso, selecione a caixa de seleção ‘Excluir arquivos da pasta App_Data’.
- Exclui arquivos da pasta App_Data: selecione a opção para impedir que arquivos na pasta App_Data sejam implantados / excluídos do Serviço de Aplicativo do Azure.
E se o aplicativo da web não for estático
Teremos que iniciar um servidor de nó no Serviço de Aplicativo do Azure que pode atender às solicitações.
- Para iniciar um servidor de nó no serviço de aplicativo do Windows, teremos que incluir um arquivo
web.configna raiz do diretório. - Para criar o arquivo
web.configdurante o lançamento, vá para Transformações de arquivo e opções de substituição de variável → Marque a caixa de seleção Gerar Web.Config e forneça os parâmetros do arquivoweb.configcomo nome do arquivo do servidor, tipo de aplicativo, etc. Ele irá gerar umweb.configarquivo que iniciará o servidor node.exe no aplicativo da web - O arquivo
web.configpode variar dependendo do aplicativo. Portanto, use um arquivoweb.configpersonalizado e mantenha-o no código-fonte em vez de gerá-lo no tempo de execução. Ao gerar o arquivoweb.config, ele tenta primeiro descompactar o arquivo zip do artefato em um local temporário (memória limitada) e, em seguida, coloca o arquivo de configuração dentro dele e, em seguida, compactá-lo novamente. Isso leva muito tempo e se o arquivo zip contiver muitos arquivos, ele pode falhar devido à limitação de memória. Ele usa um pacote de nó para compactar e descompactar o arquivo. Eu enfrentei esse problema com vários aplicativos que tinham um grande número de arquivos. Uma solução alternativa será usar a tarefa de cópia no pipeline de construção em vez da tarefa de arquivamento, mas isso tornará o pipeline lento. - Opções de pós-implantação: Esses scripts serão executados após a implantação bem-sucedida do pacote. Você pode fornecer um script embutido no próprio designer ou pode usar um arquivo de script do diretório de artefatos.
Para o Pipeline de Produção, teremos que adicionar mais um estágio para troca de slots.
- Adicione um novo estágio no pipeline de produção para troca de slot.
- Um novo slot denominado Inativo / canário (dependendo do tipo de implantação) precisa ser criado primeiro no serviço de aplicativo.
- No primeiro slot (slot inativo), marque a caixa de seleção - Implementar no slot ou ambiente de serviço de aplicativo → Fornecer o nome do slot (inativo / canário).
- Ele implantará o pacote no slot inativo / canário antes de trocá-lo por um slot Ativo. Isso garantirá tempo de inatividade ~ zero na implantação de produção.
- Como um slot também hospeda um aplicativo, ele também consumirá memória do ASP, o que pode reduzir o desempenho do aplicativo de produção.
- Portanto, pararemos o slot canário / inativo quando não estiver em uso, ou seja, após a troca de slot e iniciaremos o slot antes da implantação no slot canário / inativo.
- Adicione a tarefa de gerenciamento do serviço de aplicativo do Azure antes da tarefa de implantação do serviço de aplicativo do Azure e defina a ação para iniciar o serviço de aplicativo.
- Condições de pré-implantação: Selecione esta opção para adicionar aprovadores para o estágio de troca de slot. Você pode adicionar vários aprovadores ou um grupo de aprovadores.
- Adicionar tarefa - o serviço de Aplicativo do Azure gerencia que pode iniciar, parar, reiniciar, troca de slot, instalar extensões de site ou habilitar o monitoramento contínuo para um Serviço de Aplicativo do Azure
- Depois que a troca de slot for concluída, pararemos o slot inativo / canário para reduzir o consumo desnecessário de recursos.
Escopo para melhorias
- IaC (Infraestrutura como Código) - Este artigo é para iniciantes. Se você já está familiarizado com os pipelines de CI / CD, o pipeline YAML de vários estágios é o caminho a percorrer.
- Aumentando o desempenho do pipeline de construção usando npm-cache
- Uso de ferramentas de análise de código estático como SonarQube no pipeline de construção.
- Validação de build de solicitações pull.
Fontes onde pesquisei esse conteúdo:
Top comments (0)