http://wiki.mstech.com.br/index.php?action=history&feed=atom&title=Trilha_DevOps_.NET 2026-05-08T02:34:00Z Histórico de revisões para esta página neste wiki MediaWiki 1.26.2 http://wiki.mstech.com.br/index.php?title=Trilha_DevOps_.NET&diff=1543&oldid=prev 2016-07-18T20:34:15Z

<p>Criou página com &#039;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...&#039;</p> <p><b>Página nova</b></p><div>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.<br /> 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.<br /> 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®.<br /> <br /> == Palestra 1 e 2 ==<br /> <br /> As duas primeiras palestras foram realizadas pelo mesmo grupo, portanto foram unidas.<br /> 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:<br /> * Organizar o código fonte<br /> * Gerenciar times remotos (uma nova filial na Costa Rica)<br /> * Build vai desde o empacotar o software até indicadores de engenharia <br /> * Criar dois builds, um para CI e um para CD<br /> <br /> Para atender as solicitações do cliente, os palestrantes usaram o TFS2015, o VS2015 e o TSVS.<br /> <br /> 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.<br /> 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:<br /> * CI (Continuous Integration); e<br /> * CD (Continuous Delivery) - Tratado na Palestra 3.<br /> <br /> 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:<br /> - Executa o ''code review'';<br /> - Compilar a aplicação; e<br /> - Executar os testes unitários;<br /> 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.<br /> <br /> Para apoiar a atividade de build, alguns softwares foram mencionados, tais como:<br /> - Sonarqube; e<br /> - Ndepend<br /> <br /> O SOnarqube é um dos plugins mais utilizados para a varredura de código, e uma das métricas mais interessantes é a &quot;débito técnico&quot;, 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.<br /> <br /> == Palestra 3 ==<br /> <br /> Build Noturno<br /> O processo de CD, mais conhecido como &quot;Build Noturno&quot;, é 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.<br /> <br /> O processo de &quot;Build Noturno&quot; contempla os seguintes passos:<br /> - Executa o ''code review'';<br /> - Compilar a aplicação;<br /> - Executar os testes unitários;<br /> - Publica o site e o banco de dados em um &quot;novo&quot; 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;<br /> - Executa os ''loads tests'' na aplicação;<br /> - Executa os testes funcionais;<br /> - Fecha o pacote do produto para um entregável;<br /> Caso algum passo falhe, o processo é abortado.<br /> <br /> 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''.<br /> <br /> Nesta palestra, amsi algumas ferramentas de testes foram mencionadas:<br /> - Selenium (ferramenta de teste funcionais); e<br /> - Azure Dev teste Lab;<br /> <br /> == Palestra 4 ==<br /> <br /> Plugins para VSTS.<br /> 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®.<br /> 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.<br /> <br /> Na visão do palestrante, DevOps é a união de três fatores:<br /> * Colaboração<br /> * Automação<br /> * Feedback<br /> E envolve:<br /> * Pessoas<br /> * Processos<br /> * Ferramentas Flexíveis<br /> ** Configuração/Customização<br /> ** Extensão<br /> ** Integração<br /> <br /> == Palestra 5 ==<br /> <br /> Integração com a AWS.<br /> 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.<br /> <br /> == Palestra 6 ==<br /> <br /> DevOps e DSC.<br /> 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.<br /> O DSC é uma linguagem declarativa, e não imperativa.<br /> <br /> Um sistema conhecido no mercado é o Puppet, que tem como finalidade a orquestração de ambientes de forma automática.<br /> <br /> == Palestra 7 ==<br /> <br /> Google Play CD.<br /> 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.<br /> 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.<br /> 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.<br /> <br /> 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.<br /> <br /> Vale ressaltar que todos os passos foram construídos utilizando a ferramenta VSTS.<br /> <br /> 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.<br /> <br /> == Palestra 8 ==<br /> <br /> Última palestra. DevOps, onde erramos?<br /> <br /> Porque o DevOps não está dando certo?<br /> * Parte da Mentalidade<br /> <br /> Tudo começa no Manifesto do Desenvolvimento Ágil de Software!<br /> O segredo está na forma como pensamos e tratamos com pessoas, afinal, o processo de DevOps envolve pessoas.<br /> - Medo das coisas funcionarem sem a nossa presença.<br /> - precisa engajar as pessoas no processo de DevOps, fazer elas se sentirem parte do processo, e não algo que elas recebem pronto.<br /> <br /> ''&quot;Nosso trabalho é habilitar o negócio para a mudança, reduzindo os riscos através de ferramentas e de uma mentalidade mais empreendedora&quot;.''<br /> <br /> O Software é feito por pessoas para pessoas! Isso é muito importante!<br /> <br /> O que eu preciso fazer para entregar valor primeiro? pois assim, conseguimos convencer as pessoas da mudança.....<br /> * monte um passo a passo do que é preciso para iniciar o processo automático, e vá engajando as pessoas necessários com o tempo.<br /> <br /> Responder as perguntas:<br /> - Qual é a situação ou problema que mais te atrapalha em ser ágil no seu dia-adia?<br /> - Como você pode engajar pessoas para apoiar sua iniciativa e obter mais confiança?</div>

Daniel.alves