Trilha DevOps .NET
No TDS 2016 a organização optou por dividir a trilha de DevOps em .NET e Java, porém a ideia é realizar um evento conjunto nos próximos anos. A ideia de um DevOps voltado para .NET foi devido a grande procura de pessoas que se utilizam da linguagem e buscam automatizar cada vez mais o seu processo de build, testes e entrega. Ao todo foram ministradas 7 palestras, das quais 6 foram muito proveitosas em todos os aspectos. A seguir, uma breve descrição das palestras. Infelizmente não existe nenhum material de apoio (power point, video, etc), pois todos os palestrantes utilizaram-se da prática. por se tratar de DevOps .NET todos os softwares utilizados pelos palestrantes são majoritários da Microsoft®.
Índice
Palestra 1 e 2
As duas primeiras palestras foram realizadas pelo mesmo grupo, portanto foram unidas. O intuito desta palestra era simular uma implantação de CI (Continuous Integration) e CD (Continuous Delivery) em um cliente fictício, o qual fez as seguintes solicitações:
- Organizar o código fonte
- Gerenciar times remotos (uma nova filial na Costa Rica)
- Build vai desde o empacotar o software até indicadores de engenharia
- Criar dois builds, um para CI e um para CD
Para atender as solicitações do cliente, os palestrantes usaram o TFS2015, o VS2015 e o TSVS.
Para organizar o código fonte foi utilizado o TFS com o GIT, desta forma, além de organizar o código fonte o gerenciamento dos times remotos também era alcançado. Além disso, definiu-se as etapas de execução para o build fosse integrado, de forma que em nenhum momento houvesse intervenção humana no processo. Assim, o processo de build foi dividido em duas etapas:
- CI (Continuous Integration); e
- CD (Continuous Delivery) - Tratado na Palestra 3.
O processo de CI não deve demorar mais do que 5 minutos de tempo de execução além de contemplar os seguintes passos: - Executa o code review; - Compilar a aplicação; e - Executar os testes unitários; O CI é executado TODA vez que um commit é realizado no repositório, a fim de validar se as alterações realizadas no projeto não comprometeram a integridade do mesmo, motivo pelo qual deve ser um processo rápido.
Para apoiar a atividade de build, alguns softwares foram mencionados, tais como: - Sonarqube; e - Ndepend
O SOnarqube é um dos plugins mais utilizados para a varredura de código, e uma das métricas mais interessantes é a "débito técnico", que é a fórmula interna do sonar que analisa o código e gera o gap entre o número de issues e o tempo para corrigi-los, quanto maior este número, mais difícil corrigir o código.
Palestra 3
Build Noturno O processo de CD, mais conhecido como "Build Noturno", é um processo mais lento e, como o próprio nome já diz, deve ser executado fora de horário de expediente. Este processo deve ser executado diariamente, ou em casos específicos por necessidade, no Release apenas, pois é o entregável.
O processo de "Build Noturno" contempla os seguintes passos: - Executa o code review; - Compilar a aplicação; - Executar os testes unitários; - Publica o site e o banco de dados em um "novo" ambiente. Este processo é executado para evitar que o sistema antigo seja sobrescrito e para não atrapalhar os testes exploratórios que por ventura estejam em execução. O servidor é o mesmo, porém o site e banco são novos, utilizando como nome final o número do build gerado; - Executa os loads tests na aplicação; - Executa os testes funcionais; - Fecha o pacote do produto para um entregável; Caso algum passo falhe, o processo é abortado.
Durante a palestra, foi mencionado à respeito dos arquivos PDB que são gerados durante a compilação dos projetos. A grande maioria das empresas descarta estes arquivos, porém, eles são muito importantes pois eles guardam todos os endereçamentos que foram usados na compilação das dll's e podem ser usados no stacktrace de um dump de memória do IIS.
Nesta palestra, amsi algumas ferramentas de testes foram mencionadas: - Selenium (ferramenta de teste funcionais); e - Azure Dev teste Lab;
Palestra 4
Plugins para VSTS. A palestra 4 apenas corroborou com as anteriores, na questão de como o Build deve ser estruturado, mantido e utilizado. A novidade foi mostrar os Plugins disponíveis para o VSTS, como podemos escrever nossos próprios Plugins para a ferramenta e publica-los na loja do VSTS da Microsoft®. Ao que tudo indica, a Microsoft® está deixando de manter o TFS On-premise e está investindo em sua plataforma online, basta ver a distância entre as atualizações, que para a ferramenta online são de 15 em 15 dias e para a plataforma On-premise a cada 6 meses aproximadamente.
Na visão do palestrante, DevOps é a união de três fatores:
- Colaboração
- Automação
- Feedback
E envolve:
- Pessoas
- Processos
- Ferramentas Flexíveis
- Configuração/Customização
- Extensão
- Integração
Palestra 5
Integração com a AWS. O palestrante abordou a integração do TFS com a AWS (no modelo IaaS) para o deploy automático dos sistemas. Todo o processo é feito pela próprio TFS com auxílio do Plugin da AWS para o mesmo. Vale salientar que a AWS disponibiliza um help vasto sobre a sua ferramenta de integração via linha de comando, que permite realizar diversas atividades na nuvem.
Palestra 6
DevOps e DSC. Para quem nunca ouviu falar, DSC é o acrônimo de Desired State Configuration, ou seja, Estado Desejado de Configuração. Nada mais é que um powershell específico para a orquestração de máquinas virtuais, onde, por meio de um script DSC é possível verificar se as configurações de uma determinada máquina atendem as necessidades, caso não atendem, o script executa a instalação das mesmas, deixando a máquina em questão com a configuração desejada. O DSC é uma linguagem declarativa, e não imperativa.
Um sistema conhecido no mercado é o Puppet, que tem como finalidade a orquestração de ambientes de forma automática.
Palestra 7
Google Play CD. Nesta palestra, o apresentador mostrou como é feita a publicação na loja da Google de um aplicativo automaticamente. Para tanto ele utilizou apenas o VSTS. No exemplo, foi levado um aplicativo simples desenvolvido para Android utilizando o VSTS. O aplicativo possuía uma caixa de texto que copiava o conteúdo digitado para outra combo e um botão que limpava todo o conteúdo. No sistema de CD criado pelo apresentador, o aplicativo tem seu build solicitado e automaticamente envia o resultado para uma loja local, mantida por um sistema que simula a Google Play.
Caso ninguém reclama dentro de um período de 2 dias, o aplicativo é promovido automaticamente para a loja Alpha da Google Play. Caso em 3 dias nenhum usuário habilitado para testes Alpha reclame da APK enviada, o aplicativo é promivido automaticamente para a loja Beta da Google Play. E, novamente, após 3 dias, caso não haja reclamações é promovido automaticamente para Produção.
Vale ressaltar que todos os passos foram construídos utilizando a ferramenta VSTS.
Um ponto interessante é que eles não utilizam nenhum smartphone para testar as aplicações. Existe uma empresa que oferece o serviço de locação de aparelhos, onde o teste é realizado em aparelhos físicos, e pode-se escolher a quantidade, modelo e SO a ser utilizado. porém, como tem um custo elevado, geralmente escolhe-se apenas os 10 mais famosos. Porém, é uma forma de se testar em diversas plataformas e não existe a necessidade de mater na empresa uma quantidade de aparelhos para isso. Vale lembrar que todos esses testes devem ser automatizados, pois não existe interação humana com os aparelhos.
Palestra 8
Última palestra. DevOps, onde erramos?
Porque o DevOps não está dando certo?
- Parte da Mentalidade
Tudo começa no Manifesto do Desenvolvimento Ágil de Software! O segredo está na forma como pensamos e tratamos com pessoas, afinal, o processo de DevOps envolve pessoas. - Medo das coisas funcionarem sem a nossa presença. - precisa engajar as pessoas no processo de DevOps, fazer elas se sentirem parte do processo, e não algo que elas recebem pronto.
"Nosso trabalho é habilitar o negócio para a mudança, reduzindo os riscos através de ferramentas e de uma mentalidade mais empreendedora".
O Software é feito por pessoas para pessoas! Isso é muito importante!
O que eu preciso fazer para entregar valor primeiro? pois assim, conseguimos convencer as pessoas da mudança.....
- monte um passo a passo do que é preciso para iniciar o processo automático, e vá engajando as pessoas necessários com o tempo.
Responder as perguntas: - Qual é a situação ou problema que mais te atrapalha em ser ágil no seu dia-adia? - Como você pode engajar pessoas para apoiar sua iniciativa e obter mais confiança?
