MLOps (Machine Learning and Operations) no Azure

O MLOps (Machine Learning e Operations), de forma similar ao DevOps, é a combinação de práticas e ferramentas que permitem aos times de Data Science e Operações melhorar a implementação de modelos, através da governança de modelos de ML (Machine Learning) e IA, monitoramento, validação, colaboração e comunicação.

MLOps-MSFT
Figura: Microsoft Azure – MLOps

Isso porque segundo Gartner, muitas empresas estão desenvolvendo modelos de Machine Learning, mas apenas 47% deles são publicados em produção. E ainda 88% das iniciativas de IA possuem dificuldades para passar do estágio de teste.

Azure ML é composto de interfaces web e SDK que faz o treinamento e deploy do modelo. O processo (figura abaixo) envolve a gestão dos dados, limpeza dos dados, escrevendo e executando experimentos, publicando os modelos para coletar os dados reais (em produção) e aplicar melhorias nos modelos.

MLOps

  • Experiment: os cientistas de dados realizam diversos experimentos, evoluindo e coletando dados, a procura de respostas para as necessidades do negócio. Fundamento nos conceitos de DevOps e da Engenharia de Software, o MLOps sugere práticas para evitar a promoção de modelos mal escritos a outros ambientes.
  • Develop: o treinamento dos algoritmos (Azure ML Training Services), ETL (Data pipelines) e as práticas de CI/CD para criação dos Pipelines (Azure DevOps Pipelines) de deploy dos experimentos construídos de ML.
  • Operate: inference, monitoramento (com uso de analyse/profile, app telemetry, etc.), testes automatizados e data feedback loop para aprendizado com os dados que levam a melhorias nos modelos.

 

Vantagens

Com os times trabalhando juntos (cientistas de dados e operações), encorajam as operações de negócio data-driven, reduzindo o gap entre a descoberta de insights e ações de implementação. Algumas das vantagens são:

  • Reprodutibilidade e auditabilidade: a criação dos modelos em pipelines específicos e reproduzíveis, possibilitando rollbacks (em caso de erros) e auditorias, caso seja necessário algum rastreamento.

  • Validação: herda conceitos de DevOps como validações automáticas, testes, profiling e gestão de ambientes.

  • Habilita automação e observabilidade ao realizar novas implementações. Permite a comparação entre predicted x expected performance. Coleta as informações que servem de treinamentos aos modelos para melhorias futuras.

 

Fases do MLOps

O framework DevOps para soluções AI no Azure pode ser macro representado dessa forma:

Azure-AI-solutions

E compreende quatro principais fases entre a criação até a implantação dos modelos:

  1. Criação e treinamento dos modelos: use o treinamento com pipelines de aprendizado para criar pipelines reproduzíveis, reunindo todas as etapas (da preparação de dados à avaliação do modelo).
  2. Implantação de modelos: empacotamos o modelo para implantação e a criação de perfil para ajudar a configurar memória, CPU e validar os modelos.

  3. Automatizar o aprendizado E2E: atualizar frequentemente os modelos com Azure Machine Learning e GitHub, testar e implementar continuamente com outros aplicativos e serviços.

  4. Trilha de auditoria: coletar os dados de ponta a ponta para estabelecer uma trilha de auditoria. Por exemplo: dados do publicador dos modelos, data de implementação, uso em produção, etc.

fases-MLOpsFigura: Microsoft Azure – MLOps (adaptada)

 

 

Azure DevOps x Zendesk – Integração com service hooks

O Service Hooks é um recurso interessante do Azure DevOps para habilitar ações, baseadas em eventos que acontecem nos projetos do Azure DevOps. Por exemplo, criar uma notificação no Slack (em algum grupo específico) sobre um deploy bem sucedido. Ele funciona da seguinte maneira:

  • Publisher: define um conjunto de eventos.
  • Subscriptions: recebe os eventos e define as ações (Actions) a serem tomadas. Os consumidores (Consumer) são serviços externos que podem executar suas próprias ações, ao ocorrer algum evento.

service-hooks

Há vários serviços disponíveis no Marketplace que permitem a integração com o Azure DevOps Services. Veja a relação dos principais abaixo:

services-azure-devops

Neste post, vamos abordar a integração do Azure DevOps com o Zendesk.

1. Criando os conectores

O primeiro passo é instalar o IntegrateCloud Connector for VSTS no Zendesk. Vá no Marketplace e execute a instalação.

instalacao-integrate-cloud-azure

Você irá precisar de um Token (do lado do Zendesk) para permitir a integração com o Azure DevOps. Acesse no Zendesk a [Engrenagem de Admin] > Canais > API e ative o acesso por token, conforme imagem abaixo. Salve este token.

API-zendesk

Feito isso, acesse o Azure DevOps e configure o Service Hook do Zendesk para permitir a manipulação dos work items externamente. Para isso, acesse Project Settings > Service Hooks e adicione um novo Serviço do Zendesk.

  • A tela seguinte solicita Area Path e Work Item Type desejado.
  • Na última tela, insira a conta, usuário e token gerado no Zendesk.

new-service-hooks

Também adicione um token do lado Azure DevOps para prover a autorização da configuração do Service Hook, feito acima. Acesse “Personal access tokens” e insira um nome para ele. Salve este token também.

token-service-hooks

2. Integração de work items

Na sequência, crie um novo ticket (ou acesse algum já criado) no Zendesk e configure a área de Aplicativos (lado direito da tela). Insira a URL da conta do Azure DevOps e o Token que acabamos de gerar no passo anterior.

ticket-zendesk

Feita a autenticação, a tela abaixo (do IntegrateCloud Connector for VSTS) irá aparecer. Preencha o Projeto (Area Path) e a  Sprint (Iteration) que deseja publicar esse work item. Salve a modificação.

integratecloud-connector-vsts

Veja que o ticket criado no Zendesk agora foi criado como work item (pode ser do tipo task / bug / epic / feature / user story) no Azure DevOps. Pronto! A integração entre os dois está funcionando.

board-azure-devops

Lembrando que o Service Hooks é um recurso para para habilitar ações, baseadas em eventos e que pode ser utilizado na integração com diversos sistemas (conforme mostrado no início do artigo). Aqui fizemos uma demonstração com o Zendesk.

Migração Azure DevOps, TFS e Azure DevOps Server – Parte I

Com a adoção do Azure DevOps  (área Boards | Repos | Pipelines | Test Plans | Artifacts) em diversas empresas como a solução para o ciclo de desenvolvimento das aplicações, algumas dúvidas sobre o funcionamento do backup e migração dos dados surgiram, devido ao interesse em garantir a segurança para os artefatos criados pelos times.

E então, existe alguma ferramenta ou recurso nativo para executar a migração dos dados? Vamos começar pelo VSTS Sync Migrator, que não é tão friendly, mas apoia nas seguintes operações:

  • Migração dos dados do TFS para o TFS
  • Migração dos dados do TFS para o Azure DevOps Services
  • Migração dos dados dos Serviços de Devops do Azure para TFS
  • Atualização em massa nos serviços TFS ou Azure DevOps

Outra ferramenta muito utilizada é o Data Migration Tool for Azure DevOps. Esta ferramenta possui um guia com todos os passos para realizar a migração do Azure DevOps Server para o Azure DevOps Services. A recomendação geral deste processo é:

  • Identificar os artefatos mais importantes que deseja incluir na migração – código-fonte, work items, build pipelines, planos de testes, etc.
  • Escolher o melhor horário para fazer a migração
  • Preparar as organizações de destino, criando a organization e team projects necessários no Azure DevOps, provisionando os usuários e configurações básicas
  • Considerar tornar os deployments do Azure DevOps Server (origem) como read-only

Também pode ser feita a migração entre Organizações (Organizations) no Azure DevOps de forma manual. Neste post, vamos abordar a migração de work items da área Boards entre organizações diferentes do Azure DevOps.

1. Criando a Query

O primeiro passo é ter o AZURE DEVOPS ADD-IN PARA EXCEL instalado e configurado. Em seguida, crie uma Query (em Boards > Queries) para relacionar todos os work items que deseja fazer a migração.

2. Estruturando os times e cadência

Crie no Azure DevOps de destino as Iterations (sprints) e Areas que os times de projeto irão utilizar. Elas são as colunas Iteration Path e Area Path e podem ser utilizadas na migração para ajudar na organização dos work items. Por exemplo:

  • Work item: Criar API de retorno dos dados
  • Iteration Path: Sprint 01
  • Area Path: Time Backend e API

3. Acesse os dados do Azure DevOps (origem) no Excel

Com o Excel aberto, acesse via query, os work items do Azure DevOps (origem) que serão migrados para a outra Organização.

4. Realize a migração via Publish

Com outro Excel aberto, conecte no Azure DevOps (destino) na opção Input List e configure as colunas (choose columns) na mesma ordem do Excel com os work items de origem.

Feito isso, copie e cole os work items e utilize a opção Publish para publicar no Azure DevOps (destino). Recomendo iniciar pelo nível mais alto da estrutura (Epic – Feature – Requirements – Tasks), pois embora não há migração do relacionamento entre eles, você pode configurar em Links and Attachments estes relacionamentos.

Portfolio Plans – Feature Timeline e Epic Roadmap no Azure DevOps

O Portfolio Plans é um novo recurso do Azure DevOps (ainda em fase Beta), muito interessante para gestão ágil, pois permite a visualização do timeline dos projetos e respectivas Epics > Features a serem entregues nas Sprints.

1. Estruturação das Sprints: para começar a utilizar este recurso, o primeiro passo é a estruturação das Sprints dos times de projeto no Azure DevOps. Acesse Project Settings > Project Configuration > Iterations. Crie as Iterations (Sprints) com data de início e fim conforme seu projeto.

2. Criação do Backlog: em seguida, crie o backlog do projeto (o ideal é fazer o refinamento e distribuir as tarefas entre as Sprints, de acordo com a capacidade dos times). Acesse Boards > Backlogs e crie os Work Items, estruturando em Epic – Feature – User Story – Task.


Em Boards > Sprints, o backlog da Sprint pode ser inserido devidamente, de acordo com o planejamento. Inclua as tasks daquela Sprint, fazendo isso para cada Sprint.

3. Portfolio Plans: em Portfolio Plans, crie um novo plano e a adicione as Epics e Features que serão exibidas no Project Plan.

Visualize então as Epics e Features devidamente distribuídas nas Sprints do projeto. Em cima da caixa da Epic (ou da Feature), clique em “…” e tenha acesso as configurações de:

  • Set dates: ajustar as datas de início e fim da Epic/Feature.
  • Drill down: visão a um nível mais baixo de detalhe.
  • View dependencies: visualizar a dependência (se existir) entre Epics ou entre Features.

No símbolo da engrenagem (parte superior), também pode ser configurada a visualização do progresso por completed count (quantidade de work items completos) ou Effort (story points ou horas completas dos work items).

E a visão na Feature Timeline das Features distribuídas entre as Sprints.

Sensacional! Com este novo recurso, ficou muito mais fácil estruturar o backlog do projeto em times ágeis e visualizar o planejamento de entrega para cada produto.

Gestão de backlog – Epic Roadmap, WI relationships e personas no Azure DevOps

Já discutimos sobre o uso do Azure DevOps como plataforma de ciclo de vida do desenvolvimento e a estruturação do backlog na ferramenta (Epic – Feature – User Story – Tasks) de acordo com o seu process template.

Na área de Boards do Azure DevOps, temos alguns novos recursos no Marketplace para apoiar a visualização e gestão das atividades dos times. Selecionei três deles que são bem interessantes:

Crie então a estrutura do seu Time de Projeto no Azure DevOps (Boards > Backlogs). Veja na imagem abaixo que a relação entre Epic – Feature (Requirement) – User Story é de Parent. 

azure-devops-backlog

Feature timeline and Epic Roadmap

Após a estruturação do backlog, ainda em Boards > Backlogs, veja que as guias de “Feature Timeline” e “Epic Roadmap” foram criadas (após a instalação da extensão do Marketplace). A visão é das User Stories em relação a Sprints que serão desenvolvidas. Este roadmap ajuda o time a visualizar a entrega das funcionalidades do projeto.

epic-roadmap

Visualize work item relationships

Após a instalação da extensão no Marketpace, acesse as opções do Work Item (conforme imagem abaixo) e utilize Visualize. Em seguida, veja que será exibido a estruturação do seu backlog, bem semelhante ao FBS (Feature Breakdown Structure), muito utilizado para ajudar o time a melhorar a compreensão do produto e requisitos.

wi-visualization

work-item-visualization

Personas

Por fim, a criação de Personas ajuda a representar o usuário no sistema, descrevendo seu papel e necessidades. Instale a extensão do Marketplace (conforme link no início do artigo) e acesse o novo recurso “Personas” que será exibido, conforme abaixo.

Clique em + Add para adicionar uma nova Persona. Preencha o Nome, Tag, Descrição e Foto conforme necessidade do projeto.

create-persona-azure-devops

Após ter criado a Persona, você consegue utilizar e vincular em qualquer Work Item. No exemplo abaixo, estamos associando quais Personas são afetadas pela aquela atividade.

wi-personas

TDC SP 2019 – DevOps em grandes organizações regidas por compliance

Olá,

Segue um resumo da minha palestra na Trilha DevOps (18/07) no TDC (The Developer’s Conference) em São Paulo. O tema abordado foi Habilitando o Continuous Deployment em empresas regidas por compliance. O material apresentado está disponível neste TDC2019PDF.

tdc-2019-leo.png

  • Introdução
  • Livro Jornada DevOps
  • O problema a ser resolvido
    • Estratégicos e operacionais
    • As recomendações são mesmo aplicáveis ao seu ambiente?
    • Existe silo entre Dev e Ops?
    • Verifique seus dados – Machine Learning, Service Desk, opinião de especialistas, etc.
    • Throughput e Stability
    • Alavancagem estratégica (MVPs, Build-Measure-Learn-Loop, Time to market, testes A/B)
    • Assessment (process | technology | culture | measurement | outcomes)
    • Case real com problema no processo de Change Management
  • SOX e desafios em organizações regidas por compliance
  • Os pilares da mudança: processos, pessoas e ferramentas
  • Gestão Ágil e DevOps
  • ALM (Ciclo de vida da aplicação) com Microsoft Azure DevOps
    • Boards: estruturação de times e template do processo; cadência do projeto e definição de backlog
    • Repos: estratégia de fontes e gestão da configuração
    • Pipeline: definições de build e release
    • Gerenciamento de configuração e orquestração
    • Testes: plano de testes, Agile Testing Quadrants, modelo tradicional x ágil
    • Change Management: Azure DevOps x Service Now; processo de change management com práticas DevOps
    • Ferramentas: as ferramentas utilizadas no ciclo de desenvolvimento
    • Monitoramento: da sprint, aplicação, serviços, componentes e processo CI/CD
  • Leituras recomendadas

inscricao-jornada-devops

Azure DevOps add-in para Excel

O Azure DevOps nativamente oferece recursos para gerenciar work items – tais como criar um novo (bug, feature, epic, etc.), atribuir, status, entre outros. O board permite a visualização destes itens em Sprints e por time de projeto. A área de Queries permite a extração da informação e a área Dashboards para criar gráficos de acompanhamento.

Mesmo com todos estes recursos, sabemos que o Excel é a ferramenta utilizada por muitas pessoas para ajudar na análise e consolidação das informações. E o Azure DevOps possui integração com o Excel. Se você não tiver Visual Studio instalado na sua máquina, o primeiro passo é ir ao Visual Studio downloads page e baixar a Integração do Office para Team Foundation Server 2017 em “Outras Ferramentas e Estruturas”.

integracao-office-tfs

Nas opções do Excel > Suplementos, marque o “Team Foundation Add-in” em Suplementos de COM. Isso irá criar a aba “Equipe” no Excel que é onde iremos trabalhar na integração com o Azure DevOps.

excel-com

Na aba “Equipe’, crie uma nova lista, adicionando a URL da sua instância no TFS ou Azure DevOps.

excel-tfs

Escolha o projeto de equipe e conectar. Em seguida, na lista de consultas, utilize a query desejada para extrair os dados.

tfs-excel-query

Pronto! Os work items serão relacionados. Utilize as seguintes opções:

  • Escolher colunas: para adicionar ou remover colunas no relatório.
  • Links e anexos: permite vincular um work item a outro, ou incluir anexo.
  • Editar áreas e iterações: direciona para o Azure Devops.
  • Configurar (lista | servidor): definição do servidor que está publicado a sua organização.
  • Publicar: em caso de alteração, você consegue carregar de volta no Azure DevOps, utilizando esta opção.

work-item-excel

Estratégia de backup e recovery no Azure DevOps

Em posts anteriores, apresentamos o Azure DevOps e seus principais serviços: Azure Pipelines, Boards, Artifacts, Repos e Test Plans. Vimos também os principais benefícios da solução e como gerenciar o ciclo de vida do desenvolvimento. Ao começar o uso intensivo em sua organização, criando times e projetos, seguramente uma pergunta que virá: como funciona o backup e restore das informações?

Bom, oficialmente a Microsoft não possui um serviço (como Backup do Azure ou Armazenamento de Blobs) no Portal Azure para fazer o backup da estrutura e dados do Azure DevOps em nível de organização ou projeto.

portal-azure

* para saber como funciona no Azure DevOps Server 2019 e TFS (2018 à 2013), acesse este link de Backup and Restore.

O que pode ser feito então se alguma estrutura de projeto, arquivo de repositório ou tarefas do board forem apagadas indevidamente? Claro, que a primeira recomendação é segregar muito bem os acessos no time para evitar modificações inapropriadas. Com os acessos bem controlados, algumas recomendações que ajudam a gerenciar estes problemas são:

Board
A primeira dica é com um processo bem manual. Para salvar os work items da área board, utilize o recurso de Query e ajuste a consulta (colunas e filtros) para retornar os itens que você precisa. Em seguida, utilize “open in excel” e mantenha uma rotina de atualização. Assim, quando precisar, bastar utilizar o serviço de conexão (Excel – Azure DevOps) e carregar os work items novamente.

azure-devops-query

* as configurações relacionadas aos projetos e times de projetos são carregadas nesta query, mas caso a estrutura (teams, iterations, templates, etc.) seja perdida no Azure DevOps, ela precisará ser recriada manualmente.

 

Repos
Ao deletar um projeto, você não pode recuperá-lo. Por isso, mantenha sempre um backup do projeto. Há um procedimento para salvar o código fonte e os dados do build (View build results). Acesse a área de repositório e clique com o botão direito no nível desejado (pode ser um arquivo específico ou pasta inteira) para o download dos arquivos.

download-files-azure

* se você utiliza Git, clone seus repositórios para manter o histórico do projeto e todas as branches.

 

Pipelines
A estrutura de Build pode ser guardada com o comando Export. Acesse a área de Pipelines > Builds e com o botão direito Export. Este comando gera um JSON que pode ser utilizado para importar a estrutura de volta.

export-build

Veja que ao importar o arquivo JSON (em Pipelines > Import a pipeline), temos a estrutura criada a partir do Build que exportamos as configurações.

pipeline-build-import.png

As Releases podem ser feitas da mesma forma, exportando a estrutura em arquivo JSON e importando novamente quando necessário. Também recomendo a leitura deste artigo para implementar uma estratégia de rollback com release management.

Azure DevOps Server 2019

A Microsoft lançou inicialmente o Azure DevOps (antigo VSTS – Visual Studio Team Services) como solução completa de serviços de desenvolvimento na nuvem. Agora em 2019, está disponível o Azure DevOps Server 2019 (antigo TFS – Team Foundation Server), um conjunto de ferramentas colaborativas de desenvolvimento de software, hospedadas localmente.

Você pode instalar o Azure DevOps Server em seu próprio ambiente, integrando com seu IDE ou editor existente. As atualizações podem ser configuradas para acontecer conforme desejado. Os serviços do Azure Pipelines, Azure Boards, Azure Artifacts, Azure Repos e Azure Test Plans podem ser utilizados da mesma forma e independentes.

Clique para fazer o Download do Azure DevOps Server 2019. Os requisitos para instalação podem ser encontrados neste artigo da Microsoft.

azure-devops-server

A release notes descreve as principais mudanças em relação ao TFS 2018. Entre as principais estão:

azure-devops-server.png

Integração ServiceNow Change Management com Azure Pipelines – Parte II

Na parte I deste tópico, vimos como realizar a instalação das seguintes extensões:

  • ServiceNow Change Management (no Azure DevOps)
  • Criar uma nova instância no ServiceNow (no ServiceNow Developers)
  • Azure Pipelines (no ServiceNow)

A parte II será direcionada a configuração da integração entre o Azure DevOps e ServiceNow, desde a abertura de uma mudança no ServiceNow (a partir do pipeline no Azure DevOps) e também da atualização do status da mudança, por exemplo, colocar como concluída no ServiceNow, caso a release tenha sido publicada no Azure DevOps.

Azure DevOps
Após a instalação do ServiceNow Change Management (demonstrado na parte I), crie um novo Service Connection no Azure DevOps (Project Settings > Pipelines > Service connections). Defina as seguintes configurações:

  • Connection name: insira o nome desejado para a conexão com o ServiceNow
  • ServiceNow Url: é a URL da instância que será utilizada (também criada na parte I)
  • Username: usuário criado (ou configurado) na parte I com a permissão já definida
  • Password: a senha definida na configuração do usuário (no ServiceNow)

service-connection-vsts

Na Release Pipeline, adicione um pre-deployment gate, incluindo a conexão que acabamos de criar. É o campo ServiceNow connection. A documentação da Microsoft possui uma descrição para o preenchimento de todos os campos. Estas configurações permitem a abertura de uma mudança no ServiceNow. Entre os principais inputs:

  • Category:  a categoria da mudança (HardwareNetworkSoftware)
  • Priority: a prioridade da mudança
  • Risk: o risco da mudança
  • Impact: o impacto da mudança no negócio
  • Configuration Item: o item de configuração da mudança

gates-azure-devops

O Gates produz variáveis de output, como por exemplo:

  • CHANGE_REQUEST_NUMBER: número da mudança criada no ServiceNow
  • CHANGE_SYSTEM_ID: ID da mudança criada no ServiceNow

Esta variável de output pode ser acessada utilizando o prefixo PREDEPLOYGATE. Por exemplo, a variável gate-servicenow (definida no campo reference name) pode ser utilizada com a sintaxe $(PREDEPLOYGATE.gate-servicenow.CHANGE_REQUEST_NUMBER).

new-release-pipeline

Ao executar o deploy da release, uma nova mudança será criada no ServiceNow. Como o Success Criteria (tela anterior) está definido em “Implement”, a mudança será liberada quando for alterada para este status no ServiceNow.

ServiceNow
Então, por exemplo, quando o gestor da mudança acessar a ferramenta do ServiceNow, haverá uma nova mudança em sua fila. Ao colocar a mudança em “Implement”, a condição pre-deployment configurada no Gates será disparada, liberando a release.

service-management

Azure DevOps
Em seguida, adicione um novo Agentless job com a extensão Update ServiceNow Change Request ao final do seu release pipeline. Novamente, utilize a conexão criada anteriormente em ServiceNow connection e o status que deseja colocar a mudança após a implementação da release. No meu exemplo, coloquei o status como “Closed”.

agentless-job-azure-devops

Após a execução , o status do Deployment Gates fica disponível e se bem sucedida, a mudança será fechada automaticamente no ServiceNow.

pre-deployment-gates