Uso de Conditional Task no VSTS

Já falamos anteriormente sobre CI e CD e a importância deste processo de Integração Contínua no seu time de desenvolvimento. Quando este processo evolui, aumenta a complexidade em gerenciar Builds, por isso da necessidade do uso de conditional  execution. O VSTS trabalha com Conditional Task que é a configuração de condições na execução de uma task, por exemplo no processo de Build e Release.

Podemos adicionar na fase de release pipeline (control options de cada tarefa), uma condição na qual a tarefa executará:

  • Only when all previous tasks have succeeded
  • Even if a previous task has failed, unless the build or release was canceled
  • Even if a previous task has failed, even if the build was canceled
  • Only when a previous task has failed
  • Custom conditions

A configuração inicial é na pipeline do Build adicionar em Run this task a conditional task desejada. Veja que no exemplo abaixo utilizamos a condição referente a “Run for the master branch, if succeeding”, em caso de sucesso de execução na branch Master, o script configurado, apenas para mostrar a mensagem “Hello World” será exibida:

A condição no custom conditions utilizada foi:
and(succeeded(), eq(variables[‘Build.SourceBranch’], ‘refs/heads/master’))

vsts-condition-task-configuration

Após a execução do Build, veja que o resultado apresentado no Log é a mensagem  “Hello World” configurada no Script (passo anterior), indicando que execução na branch Master foi bem sucedida.

vsts-condition-task

É isso! Vale ler mais informações sobre as expressões condicionais que podem ser utilizada no site da Microsoft.

Uso de Queries no VSTS – visualização de tarefas, bugs e follow-up da sprint

Neste post vamos demonstrar o uso de Queries no VSTS para extrair informações do trabalho realizado pelo time, utilizando filtros e condições pré-definidas na ferramenta. O benefício está em obter análises do work in progress, bugs, estimativas, distribuição dos recursos, progresso do projeto, etc.

Comece então acessando a área de configuração das Queries (dentro de Work no VSTS). Veja que algumas Queries já vem criadas por padrão, tais como Active BugsOpen Issues, User Stories Delivered, My Tasks, etc.

queries-vsts

Na primeira Query (New Query) utilizamos os filtros de:

  • 1ª linha = retornar somente as tarefas criadas como work item. Assim, evitamos relacionar os bugs, etc.
  • 2ª linha = retornar todas as atividades em qualquer estado (active, closed, etc.)
  • 3ª linha = o uso da tag @CurrentIteration é para considerar a Sprint atual.

Execute a query em Run Query.

query-vsts

E na opção column options você consegue escolher quais colunas deseja incluir na Query. Entre os principais que utilizamos:

  • Assigned To: recurso que está trabalhando na atividade
  • Area Path: projeto que o time está trabalhando
  • Iteration Path: sprint em que a atividade está alocada
  • State: estado da atividade (active, closed, etc.)
  • Title: nome do work item
  • Work Item Type: epic, feature, task, etc.

Se estiver utilizando o template CMMI:

  • Original estimate: estimativa para concluir a tarefa
  • Completed work: horas concluídas de trabalho da tarefa
  • Remaining work: trabalho ainda restante para a conclusão

query-columns-vsts

Por fim, outros dois recursos interessantes são: 1) Clique em … (três pontos) e abrirá opções adicionais para atribuir, clonar, modificar, etc. daquele work item; 2) Email query é uma opção que envia o resultado da query por e-mail, assim você consegue planilhar ou analisar em outras ferramentas, se necessário.

This slideshow requires JavaScript.

 

Ágil em larga escala (SAFe – Scaled Agile Framework) com o VSTS

Objetivo: gestão ágil de projetos em larga escala, utilizando conceitos do SAFe, trabalhando com Release Trains e Program Increment (PI). Também gerenciar as dependências entre os times, com uma boa gestão de configuração e organização do backlog em Epic > Features > Stories.


Utilizando o VSTS
Crie um novo projeto e escolha o work item process desejado. Os três modelos (Agile | Scrum | CMMI) permitem trabalhar com gestão ágil em larga escala.

Em Project Settings, acesse Work > Project Configuration e defina a cadência do projeto. Veja que criamos a agenda da 1ª PI do projeto, inserindo as datas de início e término das Sprints 01 à 04 e a IP (The Innovation and Plannning).

vsts-PI-configuration

Crie os times que irão trabalhar no projeto. Os times serão responsáveis pelo desenvolvimento de novas releases (que serão integradas com outros times) e atualização das atividades no Board. Por isso, configure apropriadamente as permissões de cada grupo de usuários.

vsts-PI-teams

Em seguida, defina o capacity dos recursos alocados no projeto. Isso será importante quando houver a distribuição dos work itens no backlog da Sprint, pois saberemos se já há atividades suficiente para aquela Sprint.

vsts-capacity

Após criar os times e definir a capacidade dos recursos, acesse Work > Boards, e crie as EPICS do seu projeto. Elas devem ser criadas a nível do projeto (e não a nível de Team Project) para que as features de qualquer time de projeto possam vincular.

vsts-epics

Crie então as FEATURES e associe a EPIC que desejar como Parent, conforme a estrutura do teu projeto. Também crie as User Stories e associe como Parent das FEATURES apropriadas.

This slideshow requires JavaScript.

É isso! Nos próximos posts vamos falar sobre os Dashboards de acompanhamento das Sprints e das PIs. Também sobre a gestão de releases e configurações para manter o trem on track.

 

Serviços de gerenciamento de API – Portal Azure

O serviço da API Management, disponível no Portal Azure, é uma excelente escolha para a publicação de APIs a clientes externos ou outros departamentos da própria empresa.  Entre os principais benefícios estão: escala, segurança (chave, token e filtragem de IP), insights (logs, monitoramento e desempenho).

O diagrama mostra que desenvolvedores de aplicativos, aplicativos e distribuidores da API são inserido ao Gerenciamento de API do Azure por meio do portal do desenvolvedor, gateway e portal do distribuidor, que sai diretamente ou por VPN para serviços de back-end
Fonte: https://azure.microsoft.com/pt-br/services/api-management/

O Portal do Publicador disponibiliza a opção de Importar API ou criar manualmente, com exemplos práticos como a definição Swagger da API de Calculadora. Também há o Analytics que provém informações de uso e integridade. Já o Portal do Desenvolvedor interage através de documentações e credenciais para realizar chamadas. Também há

This slideshow requires JavaScript.

Na tela abaixo podemos visualizar no Portal do Publicador os principais gráficos de uso, integridade e atividades em diferentes visões (região, período, produto, operações etc.)

api-analytics.png

E o Portal do Desenvolvedor possui as seguintes áreas:

  • APIs: demonstra as APIs, URL, Request e documentações
  • Products
    • Starter: permite a execução de 5 chamadas por minuto até um máximo de 100 chamadas por semana.
    • Unlimited: acesso ilimitado a API.
  • Applications: lista de aplicações publicadas na seção de app do Portal

This slideshow requires JavaScript.

Por fim, navegue nos serviços disponíveis do API Management (Serviços de Gerenciamento de API):

  • Gerenciamento de API: adicione uma nova API – OpenAPI specification (interface to REST APIs), WADL, WSDL, Logic App, API App e Function App. Acesso aos portais (publicador e desenvolvedor), assinatura, produtos, usuários, grupos e análise.
  • Segurança: identidades, OAuth, etc.
  • Configurações: propriedades, escala e preços, rede virtual, domínios, SSL e script de automação.
  • Monitoramento: com Application Insights e visualização de métricas.

 

Wiki no VSTS – distribuindo informações nos seus times

Wiki é uma ótima escolha de tecnologia social para compartilhar informações, documentos, objetivos do projeto, entre outros no VSTS. Entre os principais recursos:

  • Distribuição da informação com referência ao backlog do VSTS
  • O formato markdown permite inserir imagens, formatações de texto, etc.
  • Utiliza o Git workflow para colaboração com a equipe e fluxo de trabalho de criação de páginas

Escolha então a criação de um novo Wiki ou Publish code as Wiki. A opção Create Wiki  (botão da esquerda), suporte apenas um Wiki no repositório Git para armazenar as páginas e artefatos relacionados.

create-wiki

Veja que podemos referenciar Work Items do backlog, assim como Epics, Features e Stories nas páginas do Wiki. É interessante que o log de revisões nas páginas é armazenado para identificar o autor de qualquer modificação.

wiki-vsts

Já na opção Publish code as Wiki, você pode manter diversos Wikis versionados no repositório Git configurado.

wiki-git

Há outras diferenças entre o Provisoned WikiPublish code as Wiki que podem ser vistas no link Differences between provisioned wiki and publish code as wiki.

wiki-differences

 

 

 

Utilizando Fork de repositórios no VSTS

Como funciona o Fork de repositórios no VSTS?
Por trabalhar com repositórios privados, a Fork do VSTS é uma cópia completa do repositório para a sua conta, incluindo os arquivos, commitsbranches. Funciona bem para manter o projeto original sem gravações, sugerindo a criação de um Fork para realizar as alterações e compartilhando-as com Pull Requests.

Por exemplo, uma equipe terceira que trabalhará em um projeto da sua empresa e você deseja que não tenha interferência no projeto principal. Pode-se criar uma Fork para isolar o repositório e fazer o pull request para o original. O Fork do GitHub é um pouco diferente, pois permite trabalhar também com repositórios públicos.

Utilize o conceito de Fork para times grandes e em situações como a de projetos open source,  em que o commit é realizado por uma alta quantidade de desenvolvedores casuais / não frequentes.  Desta forma, você mantém que somente core contributors possam realizar o commit diretamente no repositório. Em times pequenos (até 5 devs), a recomendação é trabalhar com um único repositório e políticas de branches.

O primeiro passo é criar o Fork (o botão está na tela inicial de Code > Files):

fork-vsts-01

Em seguida, escolha o nome para o novo repositório (clonado), o Team Project de destino e se a cópia será de todas as branches ou somente a principal.

fork-vsts-02.png

Após trabalhar na Fork e realizar o commit das alterações, podemos então fazer o Pull Request da aplicação.

fork-vsts-commitfork-vsts-pull-request

E por fim, clique em Complete para finalizar o Pull Request. Veja que a modificação da Fork foi aplicada no repositório original.

fork-vsts-pull-request-approve

 

Infrastructure as code – Benefícios e ferramentas como Azure Resource Manager

Infrastructure as code (IaC) vai muito além de utilizar linguagem de alto nível (descritiva) nas configurações e automações para provisionar a infraestrutura em seu ambiente corporativo. Trata-se de habilitar a escala, load balance, disponibilidade e performance exigidas por aplicações modernas.

É um ótimo approach no processo DevOps, envolvendo melhorias nas práticas de  CI (Continuous Integration): versionamento de código-fonte, provisionamento rápido e seguro de ambientes, uso de Docker, Cloud Computing, processo de deployment e infraestrutura de rede.

Iac
Fonte: Sam Guckenheimer

Entre as principais ferramentas que podem contribuir no IaC:

  • Azure Resource Manager: controle sobre múltiplos deploys de aplicações, gerenciando os recursos utilizados e acessos.
  • AWS CloudFormation: ferramenta com linguagem comum para provisionar recursos de infra em cloud e automatizar deploys.
  • Chef: permite criar “receitas” em Ruby (DSL), definindo os passos a serem executados para atingir a configuração desejada no servidor. Pode trabalhar com Azure, AWS ou Google Cloud Platform.
  • Puppet: outra ferramenta de gerenciamento de configuração que permite trabalhar com DSL. É mais direcionada a Sysadmins.
  • Ansible: ferramenta criada pela Red Hat, que modela sua infra gerenciando a relação entre os componentes. Não utiliza agentes.

Veja então como funciona o Azure Resource Manager, trabalhando a implantação, atualização ou exclusão dos recursos da sua solução (por exemplo, servidor de aplicação, BD e UI) como um grupo. Há uma camada de gerenciamento que permite realizar as tarefas utilizando o Azure PowerShell, CLI, Portal Azure, API REST e SDKs.

As ferramentas interagem com o Azure Resource Manager via API, que controla o acesso e autoriza as solicitações para o Resource Provider Contract.

azure-resource-manager

Por fim, vale relembrar algumas práticas recomendadas por Martin Fowler:

  • Utilizar arquivos de definição (shell scripts ou Chef receipts, por exemplo) para evitar mudanças manuais em servidores.
  • Auto-documentar sistemas e processos ao invés de instruções.
  • Versionamento de tudo (que for possível) para manter rastreamento e controle.
  • Continuously test systems and processes ajudam a encontrar erros rapidamente.
  • Frequência reduz a complexidade – quanto maior o tamanho do update na infraestrutura, mais difícil será detectar o erro, se houver.
  • Manter serviços continuamente disponíveis, com melhorias para evitar  downtimes. Técnicas como BlueGreenDeployment podem auxiliar nas atualizações com disponibilidade.