Veja o artigo publicado na revista Computerworld sobre o nosso case de DevOps e automação de testes em parceria com a empresa Taking:
Revista: Computerworld
Tema: Azure DevOps e automação de testes no processo de matriculas online
Data: 15/10/2018
Download do material: https://computerworld.com.br/2018/10/15/laureate-brasil-automatiza-processos-de-matriculas/
Após a introdução do framework SAFe (Scaled Agile) e de duas importantes reuniões – Scrum of Scrums e PO Sync, chegou a hora de falar sobre a System Demo, outro evento imprescindível em projetos ágeis de larga escala, que provêm visibilidade das features entregues pelos times no ART (Agile Release Train).
A System Demo é uma demonstração do trabalho realizado por todos os times durante a última iteração (Sprint). Um ótimo meio de coletar feedbacks e validar as dependências. Portanto, mantenha ativo o processo de CI (Continuous Integration) no seu time para facilitar as publicações e apresentações do sistema.
(exemplo do processo de Continuous Deployment no Azure Devops)
A integração dos sistemas, componentes, etc. no cada final de Sprint pode exigir capacidade e custo de transação inaceitável. Por isso, se você trabalha em estágios iniciais de CI, evolua gradativamente o CI e automação de testes para diminuir o custo de futuras integrações.
Figura: otimização de custo de “curva em U” para os esforços de integração
Algumas características sugeridas para a System Demo:
Frequência: a cada duas semanas, após a conclusão da Sprint.
Duração: o timebox sugerido para este evento é de uma hora. O tempo curto e direto ao ponto mantém o envolvimento de pessoas chaves na reunião.
Participantes: PM (Product Managers) e PO (Product Owners); um ou mais membros do time de sistemas; BO (Business Owners), Arquiteto, Infra e stakeholders necessários
Facilitador da reunião: PM (Product Managers) e PO (Product Owners)
E um roteiro sugerido para a System Demo:
1. Visão de produto: Epic > Feature > User Story. É importante cada time trazer um rápido overview do produto a todos presentes na reunião.
2. A representação das histórias e a carga realizada na Sprint. Também recomendo demonstrar se o critério de aceitação foi obtido.
3. E por fim, dedicar o maior tempo na demonstração do sistema em funcionamento no ambiente de homologação. Percorrer as features e user stories entregues na última Sprint e compartilhar se a DoD (definition of done) foi cumprida.
A última System Demo de cada PI (Program Increment) exige uma estruturação maior, percorrendo todas as features desenvolvidas naquela PI. Em geral, este evento acontece na I&A (Inspect and Adapt) e orienta o progresso daquela PI. Outras recomendações para uma boa System Demo:
Já iniciamos a Jornada DevOps e os seus benefícios para as organizações. E como avaliar então o progresso destas iniciativas e a das práticas DevOps em seu processo? As M-É-T-R-I-C-A-S são fundamentais para um direcionamento adequado dos três pilares do DevOps: pessoas, processos e ferramentas.
O livro Continuous Delivery – Jez Humble e David Farley – exalta a importância da visibilidade dos resultados: “Feedback is at the heart of any software delivery process. The best way to improve feedback is to make the feedback cycles short and the results visible. Measure what really matters… Once you know the cycle time for your application, you can work out how best to reduce it. You can use the Theory of Constraints to do this“.
E by the book vale começar monitorando o Throughput (capacidade de vazão do time) com indicadores de frequência do deployment e lead time e a Stability (estabilidade destas implementações), verificando MTTR e taxa de falha em mudanças.
Entre os principais benefícios das empresas High IT Performers estão: a evolução do time to market, melhor experiência do usuário, agilidade na resolução de problemas, etc.
As métricas DevOps refletem este processo de continuous delivery, com foco em velocidade, qualidade e performance das aplicações. Ter um pipeline de publicações rápido e com poucas quebras em produção é o resultado esperado pelas empresas e um bom sinal de competitividade! Fica a recomendação de algumas métricas:
Este post é direcionado as empresas regidas por compliance e que possuem um processo mais formal de publicação de releases em produção. Sem dúvida, precisamos trabalhar com o mínimo de intervenção manual, utilizando ferramentas para automatizar e rastrear os pontos de controle exigidos em auditorias.
E o que é SOX? E como as empresas que estão no Brasil são impactadas?
E quais as principais recomendações para as empresas neste cenário?
Teste técnico: um dos primeiros passos é a evidência do teste técnico. Que tal consolidar com o Quality Gates do SonarQube? Este step pode ser configurado no pipeline do Build/Release.
Homologação: os planos de teste (na área de testes do Azure DevOps) são criados e vinculados com os Work Items. Eles possuem os recursos de gravação ou screenshot para apoiar a validação do sistema. Em caso de erro, você pode abrir um novo bug para aquele Work Item.
O Request Feedback é outro recurso para solicitar a homologação do usuário e armazenar as evidências.
Procedimento de publicação: por fim, a configuração do pipeline no Azure DevOps permite o controle das releases e aprovação para a liberação em ambientes como o de QA e produção.
Vamos demonstrar em poucos passos como configurar o Build e Release (Azure Pipelines) no Azure DevOps.
Build
1. Definição de tarefas e as etapas do Build.
2. O versionamento é essencial para o Continuous Integration e a gerência de configuração. O Get Sources é o local das configurações e apontamento para o código-fonte.
3. A compilação do código-fonte e a análise da cobertura dos testes unitários. O IntelliTest pode apoiar nesta atividade.
4. Também há uma etapa para incluir a análise de código. O SonarQube é uma recomendação para analisar bugs, code smells, vulnerabilities e duplications.
Release
5. E o posterior deploy da aplicação, identificando as tarefas, variáveis e opções. Por aqui referencia-se o Build realizado.
6. O processo de aprovações é muito válido para empresas regidas por compliance. Pode ser configurado aprovadores antes do deploy em cada ambiente – desenvolvimento, homologação, QA e produção.
Em posts anteriores, fizemos a introdução de ALM (Application Lifecycle Management), CI (Continuous Integration) / CD (Continuous Delivery e Continuous Deployment) e da Jornada DevOps na organização. E como mudar então a cultura da empresa para que o DevOps seja implementado em seus processos?
Um dos pontos iniciais desta mudança é o patrocínio onipresente em diversas camadas da empresa. Este direcionamento certamente vai acelerar alguns dos itens abaixo, entre eles, a adoção de boas práticas em desenvolvimento (arquitetura escalável, padrões, engajamento com CI e gestão da configuração) e operações (infra as code).
A integração entre as áreas e o compartilhamento do conhecimento devem fazer parte do dia-a-dia em seu ambiente de trabalho. Promova eventos como DOJOs, Webinars, entre outros para disseminar o conhecimento e manter seu time sempre em evolução de práticas e tecnologias. Pense em gamification e como engajar o time a melhorar seus testes, qualidade do código e processo de CI.
Em muitos casos de transformação digital, vimos que as empresas adotaram métodos ágeis e práticas DevOps como premissas para habilitar o time to market. Criar esteiras eficientes, capazes de colocar o tempo todo novas releases no mercado, tornaram-se essenciais para validar o aprendizado com o mercado e investir em features que realmente trazem retorno. O Lean Startup aborda mais destes pontos.
A estratégia de começar “pequeno” é a mais recomendável. Escolha um projeto piloto para consolidar as práticas, os processo e as ferramentas. Assim, com o ganho observado, fica mais fácil de propagar as demais equipes e engajá-los na adoção de práticas e ferramentas. Trabalhe com times multifuncionais! Eles precisam ter o conhecimento e empoderamento para entregar os produtos.
Tenha uma boa solução de ferramentas! Considere a automação de tarefas como do build, release e testes. Só assim você conseguirá escalar e ter um processo high performer. Uma boa gestão de ambientes (virtualização, containers, etc.) e versionamento do código-fonte são essenciais também. O Azure DevOps é uma ótima solução de DevOps.
Por fim, não esqueça de mensurar os resultados e compartilhar os benefícios. Como está a frequência do deployment e do check-in do seu time? Há quebras no build? Retrabalho de atividades? Qual a causa?
E o lead time? O ciclo de vida da aplicação possui gargalos? Possui métricas de qualidade? Quais são as métricas de análise de código? A área de testes tem KPIs? O time está engajado com testes unitários? Como está a taxa de falhas (change failure rate)? E o MTTR? Há feedbacks do usuário? Os critérios de aceitação estão sendo atingidos?
O Azure DevOps possui a área de Analytics no pipeline de Build e Release para representar informações do processo de CI (Continuous Integration) como cobertura de código (em testes unitários), validação de testes, execução dos builds, etc.
Palestrante: Leonardo Matsumota
Cargo: IT Innovation Manager
Evento: Agile Trends (Florianópolis)
Tema: DevSOXOps – Habilitando o Continuous Deployment em empresas regidas por SOX e compliance
Data: 10/10/2018
Download do material: Apresentação DevSOXOps – Agile Trends
Tópicos da apresentação
Quando trabalhamos com projetos ágeis em larga escala, utilizando o SAFe como framework, temos a PI Planning como um dos mais importantes eventos. É uma reunião de planejamento com duração de 2 dias e que acontece a cada 10 semanas. O plano estabelecido e aprovado é o alinhamento entre todos os times do ART (Agile Release Train) para estas próximas 10 semanas (5 Sprints).
E o que devemos considerar na preparação deste evento? By SAFe:
Adicionalmente, fiz um resumo que pode ajudar na preparação para a PI Planning:
A Lean Inception, por exemplo, é uma ótima oportunidade de cocriar o produto a ser discutido na PI Planning. Desta forma, o escopo do produto ficará muito mais claro para o time durante a reunião de PI Planning, onde será feito o refinamento de atividades e estimativas (planning poker).
A organização do backlog do produto é essencial: Epic > Features > User Story > Tasks. Uma boa prática é criar tudo em sua ferramenta de gestão ágil (no meu caso utilizei o Azure DevOps) nesta fase de Inception e refinar o entendimento com as estimativas na PI Planning. A prototipação das telas complementa este trabalho.
Criar uma WBS (work breakdown structure) para representar as Epics e Features que serão discutidas na PI Planning é outro recurso que pode ser utilizado por PMs e POs na apresentação do produto nesta reunião.
Quando estiver iniciando um novo projeto (1ª PI Planning), vale a pena acompanhar o entendimento de todos os times, principalmente PM, POs e SMs. Recomendo inclusive executar uma mini jornada (2 horas) de PI Planning com os principais participantes.
Em estágios mais avançados, vale verificar se os feedbacks coletados no final da última PI foram trabalhados e os pontos que não foram bem, devem estar resolvidos.
Alguns dos principais pontos técnicos que devem ser garantidos antes das PI Plannings:
* The Architectural Runway consists of the existing code, components, and technical infrastructure needed to implement near-term features without excessive redesign and delay.
Garantir a reserva das salas com capacidade para todos os participantes. Também confirmar a reserva das salas necessárias para os breakouts – recursos de videoconferência, Datashow, etc.
Viabilizar materiais para PI Planning (flipcharts, post-its, canetas, canetões e folhas de sulfite) e acesso a ferramentas que serão utilizadas no projeto. O coffee é outro ponto a ser considerado no evento.
Ao criar seus projetos e times no Azure DevOps, temos outro passo importante que é a gestão de usuários e permissões de quais recursos irão utilizar. Os principais planos de usuários são:
Para visualizar os usuários da conta de sua organização, acesse o Azure DevOps em Organization Settings e Users. Veja no sumário quantos usuários estão utilizando cada tipo de licença e as extensões de Test Manager e Package Management.
Já em Organization Settings > Security do Azure DevOps, podemos criar grupos e habilitar as permissões relacionadas a estes grupos. Os membros do grupo herdam as permissões concedidas ou revogadas.
O quadro abaixo exibe as principais permissões que podemos gerenciar no Azure DevOps. As permissões estão relacionadas a estrutura (projetos ou times de projetos) ou as features. Veja que as configurações vão desde repositórios, CI (build/release), aprovações até análise de dados e manipulação de work items.
Fonte: Permissions – Azure Devops
O Azure DevOps já atribui permissões padrão aos usuários, como por exemplo de acesso a ferramenta.
E a gestão de acessos – inclusão e revogação de usuários, assim como a gestão dos grupos e permissões de acesso podem ser feitos nas mesmas áreas citadas anteriormente (Organization Settings > Security e Organization Settings > Users).
É isso… em breve falaremos sobre a gestão de usuários com Azure Active Directory (Azure AD) e os detalhes de como distribuir os recursos entre usuários e grupos.
Digital Strategy and IT Innovation 