Práticas do DevOps para o LUIS

  • Artigo

Importante

O LUIS será descontinuado a 1 de outubro de 2025 e a partir de 1 de abril de 2023 não poderá criar novos recursos do LUIS. Recomendamos que migre as suas aplicações LUIS para a compreensão de linguagem de conversação para beneficiar do suporte contínuo do produto e das capacidades multilingues.

Os engenheiros de software que estão a desenvolver uma aplicação Language Understanding (LUIS) podem aplicar práticas de DevOps em torno do controlo de código fonte, compilações automatizadas, testes e gestão de versões ao seguir estas diretrizes.

Estratégias de controlo de fontes e de sucursais para o LUIS

Um dos principais fatores de que o sucesso do DevOps depende é o controlo de origem. Um sistema de controlo de código fonte permite que os programadores colaborem em código e controlem as alterações. A utilização de ramos permite aos programadores alternar entre diferentes versões da base de código e trabalhar independentemente de outros membros da equipa. Quando os programadores criam um pedido Pull (PR) para propor atualizações de um ramo para outro ou quando as alterações são intercaladas, estes podem ser o acionador para compilações automatizadas criarem e testarem continuamente código.

Ao utilizar os conceitos e as orientações descritos neste documento, pode desenvolver uma aplicação LUIS enquanto controla as alterações num sistema de controlo de código fonte e seguir estas melhores práticas de engenharia de software:

  • Controlo de Origem

    • O código fonte da sua aplicação LUIS está num formato legível por humanos.
    • O modelo pode ser criado a partir da origem de uma forma repetível.
    • O código fonte pode ser gerido por um repositório de código fonte.
    • As credenciais e segredos, como chaves, nunca são armazenados no código fonte.

  • Ramificação e Intercalação

    • Os programadores podem trabalhar a partir de ramos independentes.
    • Os programadores podem trabalhar em vários ramos em simultâneo.
    • É possível integrar alterações numa aplicação LUIS de um ramo para outro através da rebase ou intercalação.
    • Os programadores podem intercalar um PR com o ramo principal.

  • Controlo de versões

    • Cada componente numa aplicação grande deve ter uma versão independente, permitindo que os programadores detetem alterações interruptivas ou atualizações apenas ao observarem o número da versão.

  • Revisões de Código

    • As alterações no PR são apresentadas como código fonte legível por humanos que pode ser revisto antes de aceitar o PR.

Controlo de código fonte

Para manter a definição de esquema de aplicação de uma aplicação LUIS num sistema de gestão de código fonte, utilize a representação do formato LUDown (.lu) da aplicação. .lu é preferível formatar .json porque é legível por humanos, o que facilita a realização e revisão de alterações em PRs.

Guardar uma aplicação LUIS com o formato LUDown

Para guardar uma aplicação LUIS no .lu formato e colocá-la sob controlo de origem:

  • QUALQUER UM: exporte a versão da aplicação a .lu partir do portal do LUIS e adicione-a ao repositório de controlo de origem

  • OU: Utilize um editor de texto para criar um .lu ficheiro para uma aplicação LUIS e adicioná-lo ao seu repositório de controlo de origem

Dica

Se estiver a trabalhar com a exportação JSON de uma aplicação LUIS, pode convertê-la em LUDown. Utilize a opção --sort para garantir que as intenções e expressões são ordenadas alfabeticamente.
Tenha em atenção que . A capacidade de exportação lu incorporada no portal do LUIS já ordena o resultado.

Criar a aplicação LUIS a partir da origem

Para uma aplicação LUIS, crie a partir de meios de origem para criar uma nova versão da aplicação LUIS ao importar a origem .lu , para preparar a versão e publicá-la. Pode fazê-lo no portal do LUIS ou na linha de comandos:

Ficheiros a manter sob controlo de origem

Os seguintes tipos de ficheiros para a aplicação LUIS devem ser mantidos sob controlo de origem:

As credenciais e as chaves não estão selecionadas

Não inclua chaves ou valores confidenciais semelhantes nos ficheiros que dá entrada no seu repositório onde poderão estar visíveis para pessoal não autorizado. As chaves e outros valores que deve impedir de dar entrada incluem:

  • Chaves de Criação e Predição do LUIS
  • Pontos finais de Criação e Predição do LUIS
  • Chaves de recursos do Azure
  • Tokens de acesso, como o token de um principal de serviço do Azure utilizado para autenticação de automatização

Estratégias para gerir segredos de forma segura

As estratégias para gerir segredos de forma segura incluem:

  • Se estiver a utilizar o controlo de versões do Git, pode armazenar segredos de runtime num ficheiro local e impedir a entrada do ficheiro ao adicionar um padrão para corresponder o nome de ficheiro a um ficheiro .gitignore
  • Num fluxo de trabalho de automatização, pode armazenar segredos de forma segura na configuração de parâmetros oferecida por essa tecnologia de automatização. Por exemplo, se estiver a utilizar GitHub Actions, pode armazenar segredos de forma segura nos segredos do GitHub.

Ramificação e intercalação

Os sistemas de controlo de versões distribuídos, como o Git, proporcionam flexibilidade na forma como os membros da equipa publicam, partilham, analisam e iteram alterações de código através de ramos de desenvolvimento partilhados com outras pessoas. Adote uma estratégia de ramificação do Git adequada para a sua equipa.

Independentemente da estratégia de ramificação que adotar, um princípio fundamental de todos eles é que os membros da equipa podem trabalhar na solução num ramo de funcionalidades independentemente do trabalho que está a decorrer noutros ramos.

Para suportar trabalhos independentes em ramos com um projeto LUIS:

  • O ramo principal tem a sua própria aplicação LUIS. Esta aplicação representa o estado atual da sua solução para o seu projeto e a versão ativa atual deve ser sempre mapeado para a origem .lu que está no ramo principal. Todas as atualizações à origem .lu desta aplicação devem ser revistas e testadas para que esta aplicação possa ser implementada para criar ambientes como a Produção em qualquer altura. Quando as .lu atualizações ao são intercaladas em principal a partir de um ramo de funcionalidade, deve criar uma nova versão na aplicação LUIS e aumentar o número da versão.

  • Cada ramo de funcionalidade tem de utilizar a sua própria instância de uma aplicação LUIS. Os programadores trabalham com esta aplicação num ramo de funcionalidades sem risco de afetar os programadores que trabalham noutros ramos. Esta aplicação "dev branch" é uma cópia funcional que deve ser eliminada quando o ramo de funcionalidade é eliminado.

Ramo de funcionalidades do Git

Os programadores podem trabalhar a partir de ramos independentes

Os programadores podem trabalhar em atualizações numa aplicação LUIS independentemente de outros ramos ao:

  1. Criar um ramo de funcionalidade a partir do ramo principal (consoante a sua estratégia de ramo, normalmente principal ou desenvolver).

  2. Crie uma nova aplicação LUIS no portal do LUIS (a "aplicação de ramo de desenvolvimento") apenas para suportar o trabalho no ramo de funcionalidades.

    • Se a origem da .lu solução já existir no ramo, uma vez que foi guardada após o trabalho realizado noutro ramo anteriormente no projeto, crie a sua aplicação LUIS do ramo de desenvolvimento ao importar o .lu ficheiro.

    • Se estiver a começar a trabalhar num novo projeto, ainda não terá a origem para a .lu sua aplicação LUIS principal no repositório. Irá criar o .lu ficheiro ao exportar a sua aplicação de ramo de desenvolvimento a partir do portal quando tiver concluído o trabalho do ramo de funcionalidades e submetê-lo como parte do seu PEDIDO Pull.

  3. Trabalhe na versão ativa da sua aplicação do ramo de desenvolvimento para implementar as alterações necessárias. Recomendamos que trabalhe apenas numa única versão da sua aplicação dev branch para todo o trabalho do ramo de funcionalidades. Se criar mais do que uma versão na sua aplicação de ramo de desenvolvimento, tenha cuidado para controlar que versão contém as alterações que pretende dar entrada quando criar o seu PEDIDO Pull.

  4. Teste as atualizações – veja Testing for LUIS DevOps (Testar para o LUIS DevOps ) para obter detalhes sobre como testar a sua aplicação de ramo de desenvolvimento.

  5. Exporte a versão ativa da sua aplicação do ramo de desenvolvimento como .lu a partir da lista de versões.

  6. Verifique as atualizações e convide a revisão em modo de peering das suas atualizações. Se estiver a utilizar o GitHub, irá emitir um pedido Pull.

  7. Quando as alterações forem aprovadas, intercale as atualizações no ramo principal. Neste momento, irá criar uma nova versão da aplicação LUIS principal , com a atualização .lu principal. Veja Controlo de versões para obter considerações sobre como definir o nome da versão.

  8. Quando o ramo de funcionalidade é eliminado, recomendamos que elimine a aplicação LUIS do ramo de desenvolvimento que criou para o trabalho do ramo de funcionalidades.

Os programadores podem trabalhar em vários ramos em simultâneo

Se seguir o padrão descrito acima em Os programadores podem trabalhar a partir de ramos independentes, utilizará uma aplicação LUIS exclusiva em cada ramo de funcionalidade. Um único programador pode trabalhar em vários ramos em simultâneo, desde que mude para a aplicação LUIS do ramo de desenvolvimento correta para o ramo em que está atualmente a trabalhar.

Recomendamos que utilize o mesmo nome para o ramo de funcionalidades e para a aplicação LUIS do ramo de desenvolvimento que criar para o trabalho do ramo de funcionalidade, para tornar menos provável que trabalhe acidentalmente na aplicação errada.

Conforme indicado acima, recomendamos que, para simplificar, trabalhe numa única versão em cada aplicação de ramo de desenvolvimento. Se estiver a utilizar várias versões, tenha o cuidado de ativar a versão correta à medida que alterna entre aplicações de ramo de desenvolvimento.

Vários programadores podem trabalhar no mesmo ramo em simultâneo

Pode suportar vários programadores a trabalhar no mesmo ramo de funcionalidade ao mesmo tempo:

  • Os programadores verificam o mesmo ramo de funcionalidade e enviam e solicitam as alterações submetidas por si próprios e por outros programadores enquanto o trabalho prossegue, normalmente.

  • Se seguir o padrão descrito acima em Os programadores podem trabalhar a partir de ramos independentes, este ramo utilizará uma aplicação LUIS exclusiva para suportar o desenvolvimento. Essa aplicação LUIS "dev branch" será criada pelo primeiro membro da equipa de desenvolvimento que começa a trabalhar no ramo de funcionalidades.

  • Adicione membros da equipa como contribuidores à aplicação LUIS do ramo de desenvolvimento.

  • Quando o trabalho do ramo de funcionalidades estiver concluído, exporte a versão ativa da aplicação .lu LUIS do ramo de desenvolvimento a partir da lista de versões, guarde o ficheiro atualizado .lu no repositório e faça o check-in e faça as alterações ao PR.

Incorporar alterações de um ramo para outro com a nova base ou intercalação

Alguns outros programadores da sua equipa que trabalham noutro ramo podem ter feito atualizações à origem .lu e intercalados com o ramo principal depois de criar o ramo de funcionalidades. Poderá querer incorporar as respetivas alterações na sua versão de trabalho antes de continuar a fazer as suas próprias alterações no ramo de funcionalidades. Pode fazê-lo ao voltar a basear ou intercalar para principal da mesma forma que qualquer outro recurso de código. Uma vez que a aplicação LUIS no formato LUDown é legível por humanos, suporta a intercalação com ferramentas de intercalação padrão.

Siga estas sugestões se estiver a colocar a sua aplicação LUIS num ramo de funcionalidades:

  • Antes de voltar a base ou intercalar, certifique-se de que a cópia local da origem .lu da sua aplicação tem todas as alterações mais recentes que aplicou com o portal do LUIS, ao exportar novamente a sua aplicação a partir do portal primeiro. Desta forma, pode certificar-se de que quaisquer alterações efetuadas no portal e ainda não exportadas não se perdem.

  • Durante a intercalação, utilize ferramentas padrão para resolver conflitos de intercalação.

  • Não se esqueça de que depois de a nova base ou intercalação estar concluída para voltar a importar a aplicação para o portal, para que esteja a trabalhar com a aplicação atualizada à medida que continua a aplicar as suas próprias alterações.

Unir PRs

Após a aprovação do seu PEDIDO, pode intercalar as alterações ao seu ramo principal. Não se aplicam considerações especiais à origem LUDown para uma aplicação LUIS: é legível por humanos e, por isso, suporta a intercalação com ferramentas padrão de Intercalação. Quaisquer conflitos de intercalação podem ser resolvidos da mesma forma que com outros ficheiros de origem.

Após a intercalação do seu PEDIDO, recomenda-se a limpeza:

  • Eliminar o ramo no seu repositório

  • Elimine a aplicação LUIS "dev branch" que criou para o trabalho do ramo de funcionalidades.

Da mesma forma que com os recursos do código da aplicação, deve escrever testes de unidades para acompanhar as atualizações da aplicação LUIS. Deve utilizar fluxos de trabalho de integração contínua para testar:

  • Atualizações num PR antes de o PR ser intercalado
  • A aplicação LUIS do ramo principal após a aprovação de um PR e as alterações foram intercaladas em principal.

Para obter mais informações sobre os testes do LUIS DevOps, veja Testing for DevOps for LUIS (Teste para DevOps para LUIS). Para obter mais detalhes sobre a implementação de fluxos de trabalho, veja Fluxos de trabalho de automatização do LUIS DevOps.

Revisões de código

Uma aplicação LUIS no formato LUDown é legível por humanos, o que suporta a comunicação de alterações num PR adequado para revisão. Os ficheiros de teste de unidades também são escritos no formato LUDown e também podem ser facilmente revistos num PR.

Controlo de versões

Uma aplicação consiste em vários componentes que podem incluir elementos como um bot em execução no Azure AI Bot Service, Criador de FAQ, serviço de Voz de IA do Azure e muito mais. Para atingir o objetivo de aplicações pouco acopladas, utilize o controlo de versões para que cada componente de uma aplicação seja versado de forma independente, permitindo aos programadores detetar alterações ou atualizações interruptivas apenas ao observar o número da versão. É mais fácil criar uma versão da sua aplicação LUIS independentemente de outros componentes se a mantiver no seu próprio repositório.

A aplicação LUIS para o ramo principal deve ter um esquema de controlo de versões aplicado. Quando intercala atualizações para uma aplicação .lu LUIS principal, importará essa origem atualizada para uma nova versão na aplicação LUIS para o ramo principal.

Recomenda-se que utilize um esquema de controlo de versões numérico para a versão principal da aplicação LUIS, por exemplo:

major.minor[.build[.revision]]

Cada atualização do número da versão é incrementada no último dígito.

A versão principal/secundária pode ser utilizada para indicar o âmbito das alterações à funcionalidade da aplicação LUIS:

  • Versão Principal: uma alteração significativa, como o suporte para uma nova Intenção ou Entidade
  • Versão Secundária: uma pequena alteração retrocompatível, como após uma nova preparação significativa
  • Compilação: nenhuma alteração de funcionalidade, apenas uma compilação diferente.

Depois de determinar o número da versão para a revisão mais recente da sua aplicação LUIS principal, tem de criar e testar a nova versão da aplicação e publicá-la num ponto final onde pode ser utilizada em diferentes ambientes de compilação, como o Quality Assurance ou a Produção. É altamente recomendado automatizar todos estes passos num fluxo de trabalho de integração contínua (CI).

Veja:

Controlo de versões da aplicação LUIS "feature branch"

Quando estiver a trabalhar com uma aplicação LUIS "dev branch" que criou para suportar o trabalho num ramo de funcionalidades, irá exportar a sua aplicação quando o seu trabalho estiver concluído e irá incluir o atualizado 'lu no seu PR. O ramo no seu repositório e a aplicação LUIS "dev branch" devem ser eliminados depois de o PR ser intercalado em principal. Uma vez que esta aplicação existe apenas para suportar o trabalho no ramo de funcionalidades, não é necessário aplicar um esquema de controlo de versões específico nesta aplicação.

Quando as suas alterações no seu PR são intercaladas em principal, é quando o controlo de versões deve ser aplicado, para que todas as atualizações para o principal sejam versões de forma independente.

Passos seguintes