Month: March 2019

Leituras recomendadas: Livros de DevOps e SRE

Há algum tempo, venho recebendo perguntas de algumas pessoas sobre a minha sugestão de leitura para aprofundar os conhecimentos em DevOps. Então, decidi compartilhar um resumo dos principais livros que li nesta minha jornada e assim, facilitar a escolha de qual caminho você pode dedicar seu tempo de estudos.

Segue abaixo minhas leituras recomendadas em DevOps e SRE:

continuous-delivery

Continuous Delivery
Escrito por Jez Humble e David Farley, considero o melhor livro para compreensão de conceitos DevOps. A parte I descreve configuration management, continuous integration e estratégia de testes. Na parte II, o Deployment Pipeline com Build, deploy e testes automatizados. A parte III aborda a gestão de infra e ambientes, dados, componentes e versionamento. Para iniciar, veja o resumo do livro.
book-the-phoenix-project The Phoenix Project
O livro traz uma história fictícia para apresentar um cenário de TI, considerando a complexidade e o uso do DevOps neste contexto. Ela é centrada em Bill (gerente de TI) que recebe o desafio do CEO para organizar o fluxo de trabalho e simplificar a comunicação entre os departamentos em 90 dias. Também aborda métricas e empresas low / high performers.
book-the-visible-ops

The Visible OPS
Publica a implementação do ITIL em 4 passos práticos e auditáveis. 1) Core do ITIL com práticas de sucesso e um roadmap de como implementá-lo; 2) Apresenta processos de controle bem definidos e que pode ser leve e ágil; 3) Aplicabilidade do ITIL e como seria realizado com as práticas DevOps; 4) Buscar caminhos alternativos para atingir o objetivo esperado (Chaos Monkey).
book-devops-handbook The DevOps Handbook
Aborda as melhores práticas pelos líderes do movimento DevOps. É um guia completo com recomendações de como integrar a gestão de produto, práticas DevOps e sistemas.  Também incentiva a competitividade na equipe e rentabilidade da empresa, trazendo a experiência de empresas como Amazon, Etsy e Netflix. Por fim, vale pelo direcionamento de como se tornar relevante no marketplace.
book-effective-devops Effective DevOps
Práticas para alinhamento em DevOps na organização e foco nos quatro pilares fundamentais da cultura com vários estudos de caso. Estas abordagens contribuem na quebra de silos de informação para melhorar a colaboração entre equipes. São elas: colaboração individual | afinidade dos times | ferramentas | DevOps em escala.
book-release-it Release It!
O livro escrito por Michael T. Nygard (programador e arquiteto) visa compartilhar a experiência prática em deploys de aplicações para a produção. O foco é em relação a arquitetura, fator multiplicador (negligência com recursos – usuários, sessão, etc.) e fator limite (custo e prazo com recursos novos).
book-lean-enterprise Lean Enterprise
É um guia prático que apresenta os princípios e padrões Lean e Ágil para conseguir responder rapidamente a mudanças de mercado. A parte I aborda estratégia, cultura e o ciclo de vida das inovações. Na parte II, verificar as ideias (coletando dados) e ser orientado a valor. A parte III foca na exploração das ideias validadas, e a parte IV como as empresas criam ambientes de aprendizado e experimentação.
book-SRE Site Reliability Engineering
Teoria e prática do SRE, compartilhando como o Google trata sistemas em produção. Também aborda a gestão do Google em relação a treinamento, comunicação e reuniões. As ferramentas APM e feedbacks loops são destaques pela contribuição em análises, métricas e identificação de gargalos e lentidões.
book-leading-transformation Leading the transformation
Por conta da importância do desenvolvimento de software nas organizações e as melhorias requeridas neste processo. Cita a transformação digital na Amazon e Google, aplicando Ágil e DevOps e os benefícios obtidos com a entrega mais rápida das aplicações. Foca na eficácia das equipes e na criação de uma estrutura clara para melhorar o desenvolvimento e a entrega.

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

Definição de pronto – DoD (Definition of done)

Neste post vamos falar sobre a Definição de pronto, também conhecida como DoD (Definition of Done). Ao adotarmos métodos ágeis, este é um conceito-chave, pois ao final de cada iteração, um incremento de produto deve estar pronto pelo time. No Scrum, por exemplo, o pilar de transparência*, menciona que “aqueles que realizam o trabalho e aqueles que inspecionam o incremento resultado do trabalho devem compartilhar uma definição comum de Pronto”.

* os três pilares que apoiam a implementação de controle de processo empírico: transparência, inspeção e adaptação

incremento

Definição de pronto
O Scrum então resume os principais aspectos a serem considerados na DoD:

  • Quando um item do Backlog do Produto ou um incremento é descrito como “Pronto”, todos devem entender o que o “Pronto” significa, pois será usado pelo time para assegurar quando o trabalho está completado no incremento do produto.
  • Ela orienta o time de desenvolvimento no conhecimento de quantos itens do Backlog do Produto podem ser selecionados durante o Planejamento da Sprint.
  • Como o time de desenvolvimento entrega um incremento de funcionalidade do produto a cada Sprint. Este incremento é utilizável, então o Product Owner pode escolher por liberá-lo imediatamente.
  • Se há múltiplos Times Scrum trabalhando no sistema ou versão do produto, os Times de Desenvolvimento de todos os Times Scrum devem mutuamente definir uma definição de “Pronto”.
  • Cada incremento é adicionado a todos os incrementos anteriores e completamente testado, garantindo que todos os incrementos funcionam juntos.

Considerando todos os itens mencionados acima, o desenho abaixo representa um resumo para a definição de pronto :

pronto

E alguns exemplos utilizando a Definição de Pronto:

dod-exemplos

Por fim, a Definição de Pronto traz benefícios ao seu ambiente de trabalho por aumentar a transparência e previsibilidade dos incrementos. Entre os principais, podemos destacar:

  • Todos interessados sabem exatamente o que significa um produto pronto
  • As entregas passam a ser mais previsíveis
  • Serve como um acordo entre o PO e time desenvolvimento
  • Ajuda a assegurar que o incremento esteja em condições de ser liberado para produção ao final da iteração
  • Ajuda o time no planejamento da sprint

 

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.

O Mapa de histórias (story mapping) e Roadmap de produto

Neste post, vamos abordar a criação do Roadmap de produto e Mapa de histórias (story mapping). Antes, contextualizo alguns conceitos importantes a serem considerados na fase inicial de projetos ágeis, tais como: ciclo de projetos ágeis (fase de viabilidade e iniciação), gerenciamento orientado a valor e estimativas.

john-decoster-agile
John Decoster

 Já vimos anteriormente sobre a abordagem de ciclo de projetos ágeis, recomendada em cenários de incertezas com relação aos requisitos, recursos e tecnologia. 

A estratégia de entregas iterativas, curtas e incrementais, combinada com ciclos adaptativos, permitem mudanças ao planejamento e mitiga os riscos derivados do cenário complexo, apresentado na imagem ao lado.

Neste contexto, o gerenciamento orientado a valor permeia todo o ciclo e maximiza o valor de cada entrega dos times ágeis de forma antecipada. Na fase de viabilidade e iniciação (PMI ACP por Mike Griffiths) do projeto, recomenda-se deixar claro o objetivo geral do projeto e propósito do produto:

  • Business case: mesmo em projetos ágeis, cálculos de ROI, VPL e TIR ajudam a dirigir por valor de negócio.
  • Termo de abertura ágil: descreve em alto nível o objetivo do projeto, a proposta, o escopo e a abordagem.
  • Backlog inicial do produto: representa a visão do produto e evolui conforme o produto vai sendo utilizado pelos usuários. Geralmente, são escritos em user stories. A técnica de Lean Inception pode contribuir nesta elaboração.


Estimativas iniciais
O cone da incerteza reflete que na fase inicial do produto, período de maiores incertezas, as estimativas são menos precisas. Por isso, em gestão ágil, tratamos as estimativas de forma cíclica, conforme há maior detalhamento.

cone-incerteza

Entre os tipos de estimativas, devemos considerar as funcionalidades desejadas, a complexidade e o esforço.

  • Estimativa de complexidade: utiliza pontos de complexidade para dimensionar o tamanho das user stories. A partir do tamanho de uma história (mais conhecida), utiliza-se valores relativos para comparar com as demais. Exemplo: determinado que a história “consultar cliente” possui 1 ponto, a história “cadastrar cliente” possui o dobro do tamanho?
    iteração
  • Estimativa por afinidade: agrupa itens em categorias similares. Esta triangulação oferece uma visão comparativa das estimativas. É aplicável quando há um grande número de histórias para serem estimadas.

Roadmap de produto
O Roadmap de produto é um artefato que combina os objetivos do negócio, as necessidades do cliente e as tarefas necessárias para atingir esses objetivos. É com ele que planejamos e  comunicamos a visão de futuro do produto aos interessados.

O objetivo é alinhar diferentes visões, organizando as ideias de desenvolvimento do produto, definindo prioridades e agregando o máximo de valor ao seu negócio. Auxilia em questionamentos da evolução do produto “onde estamos?”, “ onde queremos chegar?” e “como chegaremos?” e outros aspectos:

  • Visibilidade do desenvolvimento e liberação de produtos
  • Facilita a comunicação dos interessados em relação a priorização e disponibilidade de novas funcionalidades

product-roadmap.png

Mapa de histórias (story mapping)
“User Story Mapping é um mapa que organiza as histórias de usuário em um modelo que ajuda a compreender a funcionalidade do sistema, a identificar falhas no seu backlog, e a, efetivamente, planejar releases holísticas que oferecem valor aos usuários e ao negócio a cada versão”. Jeff Patton – The New User Story Backlog Is a Map.

É a big picture utilizada pelos times ágeis quando precisam visualizar roadmaps de produtos de alto nível e planos de releases. Expõe uma visão da forma como o trabalho vai ser desdobrado em três elementos:

  • Backbone (user activities): os temas que o usuário será capaz de executar com o fluxo de trabalho.
  • Walking skeleton (user tasks): são as tarefas que suportam o backbone. 
  • Histórias de usuário: representa a quebra das histórias que permitem a conclusão das tarefas.

story-mapping

Veja agora em um exemplo prático do blog how to prioritize a User Story Map. Podemos ver a USM (User Story Mapping) e o passo a passo mapeado para histórias e releases.

usm-prioritize.png

 

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