Azure Blog Ninja - Fabricio Catae

Hit Refresh

Fabricio Catae — Thu, 09 Aug 2018 09:00:00 GMT

Olá pessoal! Estava revendo meu blog e vi que meu primeiro post foi em agosto de 2009 (já faz quase 10 anos). Ao longo dessa jornada, pude compartilhar um pouco da experiência de campo como Premier Field Engineer (PFE) de SQL Server. Mas houve mudanças… Em 2014 mudei para o time de Evangelismo da Microsoft, trabalhando com games (Mobile, PC, XBox).

Criei um blog de desenvolvimento de jogos. http://aka.ms/jogos
Ensinei muitas crianças a programar com o Kudu (https://blogs.msdn.microsoft.com/jogos/2015/03/24/ensinando-a-programar-kodu-game-labs/)
Tinha até um canal de eventos. https://channel9.msdn.com/Events/Games-Brasil

Em 2015 investimos pesado no evangelismo do Microsoft Edge (sucessor do Internet Explorer).

Criei artigos sobre HTML5 no blog do Lab27 (http://www.lab27.com.br/, que foi desligado!)
Gravei vídeos (https://www.youtube.com/channel/UCXF9mbDYamSiS43WpSnDiaw)
Participei de eventos usando a camisa do Internet Explorer (!!!) e do Edge

Em 2016 iniciei os trabalhos com nuvem (Microsoft Azure).

Escrevi muito código no GitHub (https://github.com/fcatae)
Criamos o projeto ARDA para apontamento de horas do time (https://github.com/CSELATAM/arda)
Atuei com o time de Startups (que mundo diferente!) para adoção do Azure

Em 2017 fiquei dedicado a um único cliente: Linx, atuando como Arquiteto de Cloud.

Azure: Virtual Machine, VM Scale Sets, Storage Account, WebApps, EventHub, etc..
DevOps: Acompanhamento do processo de Build e Release
Microserviços: Projetos com API REST e backend NoSQL

Ainda em 2017 me tornei professor de pós-graduação na FIAP.

Curso MBA: Arquitetura e Desenvolvimento na Plataforma .NET
Inclusão dos temas de Cloud e NoSQL na disciplina de Persistência de Dados
Escrevi o "famoso" artigo: Entity Framework: Code-First, Database-Never

Apesar de todas essas mudanças, sempre continuei escrevendo artigos sobre SQL Server. É um assunto que gosto muito! Foi essa paixão que me ajudou a continuar escrevendo. Entretanto, hoje sinto que não tenho mais tanta experiência como antes. Os últimos posts nem foram sobre SQL, mas sobre os aprendizados de um projeto chamado ARDA. Sinto que chegou a hora de parar de escrever. Há vários profissionais que continuam trabalhando diariamente com SQL Server e que publicam material de melhor conteúdo. HIT REFRESH Acabei de rodar um sp_cycle_errorlog (ou receber um SIGHUP, do Unix). Estava na hora de me "reconfigurar":

Oficialmente desde julho de 2018 meu cargo é Senior Software Engineer, atuando na área de Open Source e Inovação.
Passei na prova de certificação LFCS (Linux Foundation Certified Sysadmin).
Retornei ao blog para escrever novos artigos.

Embora as futuras publicações talvez não sejam assuntos muito atraentes ao DBA (desculpe!), pelo menos consigo dar continuidade ao blog. Aprendi muito com o SQL Server e ele ainda continua no coração! Mas já comecei o refresh... Abraços, Fabricio

Treinamento de Big Data

Fabricio Catae — Fri, 03 Aug 2018 09:00:00 GMT

Final de semana passada fui no treinamento do Luan Moreno para saber um pouco mais de Big Data. Fui surpreendido! Eis aqui o meu resumo do curso: (note que retirei os nomes e deixei somente a parte das imagens – igual a aqueles jogos de adivinhar o logo)

Como que o Luan consegue falar tanta coisa em tão pouco tempo???

O curso começa dando uma visão geral sobre os conceitos (Cloud e Big Data), sendo que logo no primeiro dia já somos apresentados ao universo de produtos disponíveis. O segundo dia foi quase que uma imersão no mundo Hadoop com foco em Batch processing. Por fim, no terceiro dia tivemos Streaming e transferência de dados.

Valeu a pena participar do curso. Mesmo já conhecendo a maioria dessas ferramentas, o Luan consegue transmitir um conhecimento que não está escrito em livros.

Por exemplo, quando ele explica HDFS.

Assim como o cenário de IoT:

O treinamento abriu minha cabeça ao mostrar que há uma mudança de paradigma no profissional. Não existe como ser especialista em uma única tecnologia. Há muitos produtos ou muitas mudanças, por isso, não da tempo de aprender tudo.

Recentemente tenho trabalhado com Azure e a situação não é diferente:

Além do conhecimento adquirido e das reflexões pós-curso, foi ótimo conhecer novas pessoas e reencontrar alguns amigos.

Exceptions: Sempre use try-finally

Fabricio Catae — Thu, 03 Aug 2017 09:00:00 GMT

A interface IDisposable e try-finally tem uma relação muito próxima.

IDisposable é uma interface que implementa o método Dispose, que realiza a limpeza dos recursos de forma determinística. Normalmente esse método é chamado dentro de um bloco finally.

Existe a forma equivalente de chamar o Dispose através do using.

A regra é simples: se o objeto implementa a interface IDisposable e possui o método Dispose, então use try-finally ou using. Alguns exemplos importantes de objetos que devem ser limpos:

Banco de dados: SqlConnection e DataReader
Arquivos: StreamWriter, StreamReader, FileStream

No último artigo, mostrei um exemplo de um erro muito comum: “The timeout period elapsed prior to obtaining a connection from the pool”. Esse erro ocorre porque as conexões não são fechadas corretamente e ficam aguardando para serem finalizadas pela Finalizer thread.

A solução apresentada foi:

No entanto, o código não está 100% correto. Note que o objeto SqlCommand também implementa a interface IDisposable e, portanto, a solução ideal seria:

Embora o SqlCommand use somente recursos gerenciados, essa escrita tem a vantagem de chamar o GC.SupressFinalize contra o objeto, evitando adicionar o objeto à fila de finalização.

Implementando o IDisposable

Existem casos que precisamos implementar a interface IDisposable na nossa classe. Por exemplo, quando alocamos um objeto Disposable e armazenamos em uma variável membro.

O código acima está incorreto. Ninguém chama o método Dispose do SqlConnection, portanto, a conexão fica aberta e será fechada pela Finalizer Thread em um momento posterior (normalmente logo depois de um Garbage Collection).

O correto é implementar a interface IDisposable para permitir a limpeza de recursos:

Encontrei uma discussão muito boa sobre o IDisposable no Stack Overflow.

Proper use of the IDisposable interface
https://stackoverflow.com/questions/538060/proper-use-of-the-idisposable-interface

Vou aproveitar um dos exemplos (reescrevi o código) para mostrar uma situação que NÃO devemos usar o IDisposable. A pergunta inicial é se a classe MyCollection deve implementar o método Dispose para agilizar a limpeza de memória. A resposta é NÃO para memória gerenciada.

O objetivo do método Dispose é realizar a limpeza determinística de recursos não-gerenciados e objetos IDisposable. No exemplo anterior, a classe MyCollection possui a variável membro do tipo List, que não é IDisposable.

Conclusão

Nesse artigo comentei sobre a interface IDisposable e sua relação próxima com o try-finally. Infelizmente esse é um tema que ninguém presta atenção. Já vi pessoas defendendo o uso do GC.Collect no código para garantir performance! Não tenho dúvida de que esquecer de chamar o método Dispose é um dos erros mais comuns de programação C#.

A regra é sempre usar try-finally ou using nos objetos Disposable.

Exceptions: The timeout period elapsed prior to obtaining a connection from the pool

Fabricio Catae — Wed, 02 Aug 2017 09:00:00 GMT

Use try-finally para resolver seu problema de “The timeout period elapsed prior to obtaining a connection from the pool”.

Já comentei nos artigos anteriores sobre as construções:

Dessa vez vou falar quando usar o try-finally.

Exemplo

Criei um programa que executa uma Stored Procedure no SQL Server. A versão é bastante simplificada, mas ela tem um erro grave. Procure o problema no código abaixo.

Observe que, apesar do erro, o código funciona normalmente.

Encontrou o trecho incorreto?

Problema

Quando codificamos, sempre pensamos no “caminho feliz”, quando tudo dá certo. Entretanto, é possível que determinados comandos falhem. Por exemplo, o método cmd.ExecuteNonQuery pode gerar exceções por diversos motivos: comando inexistente, acesso negado, timeout.

Se houver uma SqlException durante a execução desse comando, a conexão não será fechada. Isso significa que a conexão aberta pelo método conn.Open não será encerrada por conn.Close.

Repetimos essa operação 100 vezes e temos a seguinte mensagem:

Timeout expired. The timeout period elapsed prior to obtaining a connection from the pool. This may have occurred because all pooled connections were in use and max pool size was reached.

Esse erro não é novo. Já havia comentado antes:

https://blogs.msdn.microsoft.com/fcatae/2013/12/09/the-timeout-period-elapsed-prior-to-obtaining-a-connection-from-the-pool/

Sempre use try-finally

A forma correta de escrever esse código seria:

Um atalho seria usar a sintaxe using:

Nesse caso, o método Dispose é automaticamente chamado e fecha a conexão correspondente.

Conclusão

Se você recebeu o erro “Timeout expired. The timeout period elapsed prior to obtaining a connection from the pool. This may have occurred because all pooled connections were in use and max pool size was reached”, então a causa mais provável é que esqueceu de fazer o Dispose do objeto SqlConnection.

Note que eu poderia ter usado try-finally ou using para o objeto SqlCommand. Por que usar ou não usar? Deixarei isso para um próximo artigo.

Cuidado com o GC.Collect

Fabricio Catae — Tue, 01 Aug 2017 11:00:00 GMT

Você já usou o comando GC.Collect? Há inúmeros casos que esse comando resolve problemas de memory leak. Entretanto, esse procedimento é somente uma solução temporária e não resolve a real causa raiz. Pense: se o Garbage Collector (GC) do .NET faz a limpeza automática de memória, então por que rodá-lo manualmente? Nesse artigo, vou abordar 3 pontos: Memory leak, Unmanaged code, Finalizers. Depois explico qual a relação com o GC.

Memory Leak

No C/C++, a memória alocada deve ser liberada posteriormente: A possibilidade de memory leak (vazamento de memória) existe quando o programador deixa de chamar a função de free/delete correspondente ao bloco de memória. Diferente do C/C++, consideramos o .NET como código gerenciado (managed code), pois não existe a necessidade de liberar explicitamente a memória. Não existe free ou delete. Podemos fazer alocações de memória sem nos preocuparmos com a forma de desalocação, pois toda “memória gerenciada” é liberada automaticamente pelo Garbage Collector. Isso diminui os riscos de memory leak. Ainda fica a pergunta: por que rodar o GC.Collect manualmente em .NET?

Unmanaged Code

Você pode escrever um programa 100% em C#, mas sempre haverá trechos do runtime que dependem de recursos não-gerenciados. Por exemplo, veja os trechos abaixos: StreamReader e SqlConnection são objetos gerenciado e, portanto, o GC faz a limpeza da memória associada. Entretanto, esses objetos usam recursos nativos do Sistema Operacional. No Windows, StreamReader possui uma referência a um handle de arquivo, porque internamente ele chama as funções do CreateFileEx do Kernel32.dll. De forma semelhante, o SqlConnection faz referência a uma DLL nativa (escrita em C++), que por sua vez abre sockets TCP via WinSock2. Portanto, ambos os objetos dependem de recursos nativos e não-gerenciados, que não são da responsabilidade do Garbage Collector.

Finalizers

Os objetos do .NET possuem destrutores denominados de Finalizers. Esses métodos são chamados antes do Garbage Collector e são responsáveis por liberar a memória não-gerenciada relacionado ao unmanged code.

System.Object: Finalize method https://msdn.microsoft.com/en-us/library/system.object.finalize Finalizers (C# programming guide) https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/destructors

O conceito de destrutor no C++ é bem conhecido. Sempre quando um objeto é desalocado, o destrutor é chamado e depois a memória é devolvida. Entretanto, o comportamento no C# é ligeiramente diferente. O método Finalize roda em uma thread dedicada chamada de Finalizer Thread e não ocorre de forma determinística. Existe inclusive uma lista de objetos a serem finalizados: Somente objetos que possuem recursos não-gerenciados entram na fila. É importante lembrar que o Garbage Collector (GC) e a Finalizer Thread trabalham em paralelo. Ambos são não-determinísticos, ou seja, não é possível determinar o momento em que rodam. Entretanto, existe uma ordem: a remoção do objeto pelo GC ocorre somente depois de sua finalização. Em muitos casos, os "problemas de memory leaks do .NET" estão associados a uma longa fila de finalização. Enquanto a thread de finalização está suspensa, essa fila pode crescer e aumentar o consumo de recursos não-gerenciados.

Conclusão

A conclusão é que o GC.Collect resolve o problema de memory leak associado com unmanaged resource/code, que não passou ainda pelo finalizer. Portanto, o memory leak ocorre somente nessas condições:

Garbage collector mantém os objetos com finalização pendente
Objetos são finalizados de forma não-determinística (e pode demorar)
A fila de finalização cresce em número de objetos e causa o esgotamento de recurso

A solução é que normalmente adotar o Dispose pattern. Isso significa que os recursos não-gerenciados podem ser liberados de forma determinística através do método Dispose do objeto. Assim como citado no exemplo anterior, os objetos StreamReader e SqlConnection possuem recursos nativos e que devem ser desalocados manualmente. Embora o finalizer da classe faça a liberação desses recursos, o ideal é sempre chamar o método Dispose depois de usar o objeto. Nos próximos artigos, vou falar sobre o uso do try-finally para garantir que os recursos sejam sempre desalocados.

Deploy do ambiente de Staging

Fabricio Catae — Mon, 31 Jul 2017 09:00:00 GMT

Esse é um artigo rápido para falar de recursos úteis do WebApp:

Integração contínua com GitHub
Console administrativa com linha de comando
Monitoração proativa do Application Insight

Configuramos a aplicação Web em apenas 5 minutos no Azure App Services.

Web App

No portal do Azure, há um dashboard com as principais métricas de requisições, throughput de dados, tempo de resposta e outras métricas pertinentes a servidores Web. Esse é o ponto de partida para a configuração da aplicação.

É possível escolher quais frameworks serão pré-instalados na imagem: .NET, php, Java, Python. No momento, estamos trabalhando com a versão do .NET Core, mas estamos avaliando voltar o uso do .NET Framework 4.6 para agilizar os deployments.

A aba de “app settings” permite configurar as variáveis de configuração específicas por ambiente.

Nessa seção, portanto, configuramos a connection string com os bancos de dados e com as credenciais do Redis.

Integração Contínua

A melhor funcionalidade do WebApp é a configuração de deployment, que faz a integração contínua com o Git e deployment para o ambiente. Esse recurso de CI/CD pode ser habilitado em menos de 1 minuto!

Note que os deployments correspondem aos commits realizados no repositório.

Existe integração nativa com o GitHub, BitBucket e VSTS.

Console Administrativo

O servidor de WebApp possui um console administrativo rodando na mesma máquina.

Site: http://.azurewebsites.net
Admin: https://.scm.azurewebsites.net

Esse site administrativo, conhecido também como Kodu, roda somente em HTTPS e requer autenticação.

Uma vez logado é possível listar todos os processos ativos na máquina.

É possível usar o terminal do CMD ou Powershell para navegar nos diretórios.

Monitoração Proativa do Application Insight

Fizemos a monitoração do aplicativo usando as ferramentas do Application Insight. Colocamos alguns gráficos no nosso dashboard inicial do Azure para acompanhar o desempenho.

Um dos recursos mais legais do Application Insight são as notificações por email. Em uma delas, tenho um resumo semanal da quantidade de acesso e uma comparação com a semana anterior.

Há uma notificação proativa para detectar erros e problemas. Em alguns momentos, recebemos alertas avisando sobre um aumento de carga ou degradação do desempenho de uma determinada requisição.

No portal do Application Insight, existem uma série de alertas que podem ser configurados.

Exceptions: Evite o try-catch

Fabricio Catae — Tue, 25 Jul 2017 09:00:00 GMT

Nesse artigo vou falar para evitar o uso do try-catch e try-catch-finally.

No artigo anterior sobre try-catch-finally, comentei sobre o tratamento de exceptions usando o try-catch ao invés de try-catch-finally.

Pense duas vezes antes de adicionar um bloco de catch para capturar o erro.

Na dúvida, evite o uso do try-catch.

O que é uma Exception?

Uma Exception corresponde a uma situação de exceção, que não deveria acontecer em situações normais. Veja esses exemplos:

Chipset pegando fogo porque a máquina está operando no deserto
Placa de memória em curto circuito por causa de uma chuva inundando o data center
Sistema operacional escrevendo aleatoriamente no disco por conta de um ransomware

Esses foram exemplos exagerados de exceções que podem acontecer. Por que você faria o tratamento de erro? Afinal, o que você pode fazer em um bloco try-catch quando nem a CPU ou a memória RAM funciona direito?

Entretanto, existem situações de Exception que encontramos no dia a dia:

Stack overflow
Falta de memória
Kernel panic

Novamente, por que fazer um try-catch? O ideal é deixar que o processo falhe completamente e seja reiniciado do zero. Esse é o chamado processo de fail fast: ao encontrar uma situação inesperada, o processo reinicia ao invés de tentar tratar o problema.

Portanto, evite o uso do try-catch e prefira o fail-fast.

Engolindo Exceptions

Não engula exceções. Em inglês seria “DO NOT swallow exceptions”.

No nosso código do ARDA, temos um problema reportado pelo @lucaslra:

Issue #4 - Hidden Exceptions

https://github.com/DXBrazil/Arda/issues/4

Imagine a situação de falta de memória ou algo mais crítico. “Engolir a exceção” e retornar valores nulos não vai ajudar em nada. Existem algumas opções para tratamento (ex: gravar em um log), mas minha sugestão é sempre evitar o try-catch.

Tratamento de Exceção

A correção para o problema reportado foi remover o try-catch. Veja o trecho original abaixo:

https://github.com/DXBrazil/Arda/blob/771695ec90b651098f43dd6296930682a285fd5f/src/Arda.Kanban/Controllers/ActivityController.cs

Esse código é ruim porque “engole a exception”: a requisição retorna o status HTTP 200 (sucesso) com conteúdo nulo (No content).

Compare com a versão sem try-catch, que simplifica a lógica:

https://github.com/DXBrazil/Arda/blob/2c9e79f84f1e00a3c75d5e4964bd8a28bc834318/src/Arda.Kanban/Controllers/ActivityController.cs

Se uma exceção acontecer, um midlleware do ASP.NET intercepta a Exception e transforma em uma resposta HTTP 500 (erro interno). Acredito que o status HTTP 500 é mais adequado que o HTTP 200.

Usando Try-Catch em Console Application

Uma exception não tratada força o cancelamento da thread que, por sua vez, pode derrubar o processo inteiro. Portanto, existem casos que queremos evitar que uma exception cancele o processo inteiro.

Nesse caso, voce deve usar um try-catch no método estático Main do arquivo Program.cs.

Note que estou sendo bastante específico com relação ao try-catch: dentro do método Main do Program.cs. Em qualquer outra situação, recomendo que pense duas vezes.

Quando usar try-catch

Infelizmente ainda existem casos que precisam do try-catch: determinados trechos do código não devem disparar Exceptions e, por isso, devemos adicionar um bloco de tratamento de erro.

Um exemplo é o ARDA, que acessa dados do SQL Server e mantém um cache no Redis. Quando o serviço do RedisCache fica indisponível, a requisição deve ignorar o cache e consultar diretamente ao banco de dados. No nosso caso, implementamos um try-catch especificando a captura somente da exceção RedisConnectionException.

https://github.com/DXBrazil/Arda/blob/0dcc8f283d52e85d3ba47f3529ffb0fa9f06c93b/src/Arda.Permissions/Repositories/PermissionRepository.cs

Nesse caso, usamos o try-catch para evitar que a falha do Cache impacte na disponibilidade do serviço. O mais importante é que somos bastante específico com relação ao tipo de exceção, pois não é a genérica System.Exception.

Usando Try-Catch no ASP.NET

Se você usa o ASP.NET, então não há motivo para usar try-catch porque o middleware faz esse trabalho por você. Observamos isso ao longo do trabalho com o ARDA, quando limpamos os try-catch do código.

https://github.com/DXBrazil/Arda/issues/4

Entretanto, veja que ainda há casos importantes de try-catch que devem ser mantidos.

Na grande maioria dos casos, usamos try-catch com exceções específicas.

Check transient errors (RedisConnectionException)
https://github.com/DXBrazil/Arda/commit/b10a4fcf9f68001b7f2f2f92974ad3b4802a3d71
Removed try/catch from VerifyUserAccessToResource exception
https://github.com/DXBrazil/Arda/commit/229acae260ce727a2cf7f9aa4eb389c73b00dbaa
Catch RedisConnectionException thrown in GetUserMenuSerialized
https://github.com/DXBrazil/Arda/commit/b3eb3c2c2a40d0aff3352b15278528ff62aedfe9
Remove generic exceptions from GetUserPhoto
https://github.com/DXBrazil/Arda/commit/d4555d22021dc05a18ca0f6a222293498a6fb863
Remove unused function CallMicrosoftGraph
https://github.com/DXBrazil/Arda/commit/84b1086a0f828e004fbae94496e87e059da635eb

Conclusão

Nesse artigo, falei que minhas regras com relação ao try-catch são:

Na dúvida, evite o uso do try-catch
Use no Program.cs para evitar o crash do processo
Se for necessário tratar a exceção, especifique o tipo de exceção

Na dúvida, pense no fail-fast e evite “engolir exceptions”.

Exceptions: Não use try-catch-finally

Fabricio Catae — Mon, 24 Jul 2017 13:00:00 GMT

Essa semana estava revendo um trecho do ARDA (https://github.com/DXBrazil/Arda) e os primeiros issues e pull requests estavam relacionados com o tratamento de exceção. Por coincidência, nessa mesma semana, fui perguntado sobre as melhores práticas de Exceptions sobre como e quando usar. Comecei olhando a documentação do C# sobre o try-catch-finally.

Try-catch-finally https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/try-catch-finally

Nesse artigo, há o seguinte trecho de código: Então, pergunto:

O que há de errado nesse exemplo?

Embora a linguagem permita a construção e a documentação confirma que é possível, sigo o pensamento de que a sintaxe try..catch..finally não deveria existir no C#. Na minha opinião, não se deve usar try-catch-finally. Essa é uma afirmação forte e, antes de que alguém se desespere, deixo explicar meu ponto de vista.

Por que não existe “finally” no C++?

Você sabia que a linguagem C++ suporta exceções e somente a construção try-catch? Não existe finally!

http://www.stroustrup.com/bs_faq2.html#finally Why doesn't C++ provide a "finally" construct?

Resposta do Bjarne Stroustrup:

Because C++ supports an alternative that is almost always better: The "resource acquisition is initialization" technique (TC++PL3 section 14.4).

A linguagem do C++ adota o padrão de Resource Acquisition is Initialization (RAII). Em outras palavras, os recursos devem ser desalocados dentro do destrutor das classes, dispensando o uso do finally.

Use try-catch

Quando lidamos com exceção, tratamos as exceptions através de blocos try-catch. https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/try-catch Não tem segredo: as exceções são capturadas pelo bloco catch para tratamento do erro.

Use try-finally

A linguagem suporta a construção try-finally para liberar os recursos alocados. https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/try-finally Diferente do C++, o garbage collector do C# (.NET) é não-determinístico. Por isso, sempre garanta que os recursos são liberados no momento certo através do finally.

Não use try-catch-finally

A construção try-catch-finally mistura dois propósitos distintos no mesmo código. Por isso, deixe claro a intenção e use a sintaxe adequada com os blocos:

try-catch: Tratar os erros e exceções
try-finally: Liberar explicitamente os recursos

Reescrevi o trecho anterior usando try-catch-finally e, ao invés de melhorar o código, parece que ficou mais confuso: Nesse momento, é natural encapsular o trecho do código de leitura de arquivo dentro de outra função. Veja como o código fica mais claro: A função ReadFileBlock gerencia o objeto File, fazendo a alocação de recurso e liberando no finally. Compare como ficou muito melhor que a versão try-catch-finally.

Conclusão

Nesse artigo, apresentei a ideia de evitar o try-catch-finally porque essa construção mistura os conceitos de tratamento de exceção e liberação de recurso. Ao invés disso, recomendo que use try-catch ou try-finally.

Bots, Devops e Docker

Fabricio Catae — Thu, 20 Jul 2017 09:00:00 GMT

Participamos de um Hackathon de Bots.

Whitepaper: Bots, DevOps e Docker - Lições aprendidas em 48 horas [Download do Whitepaper]

Já faz quase um ano que nos juntamos para trabalhar em um projeto de Bot. Nosso time era composto por pessoas com diferentes especialidades e, por isso, decidimos empregar as técnicas de DevOps para garantir uma entrega ágil e sem perda de qualidade durante o evento.

Cockpit da NASA

Uma coisa é certa: desde o início já sabíamos como seria nosso dashboard. Teria que todos os indicadores de processo, incluindo cada fase do nosso pipeline de entrega (Build, Release e Teste) até o ambiente de produção. Construímos um pipeline de entrega para remover os passos manuais dos processos de compilação até a publicação. Todos enxergavam o status do projeto pelo dashboard do VSTS, que fornecia informações sobre:

Tarefas pendentes
Resultado dos builds
Distribuição da aplicação
Resultado dos testes
Monitoração da aplicação e infraestrutura

Uma das vantagens da integração contínua no VSTS era a visão do histórico de compilação. Acredite ou não, ver tantos indicadores na cor verde aumentava a nossa confiança, pois sabíamos que estávamos fazendo o trabalho certo. Lógico que, no começo, estava tudo vermelho. Em um cenário sem esse acompanhamento detalhado, talvez a gente não estivesse tão confortável em fazer modificações próximos ao final do evento. Você já certamente viu isso acontecer na empresa – o período de freezing. Entretanto, nosso time não teve freezing e seguimos codificando até o último minuto.

Linux e Containers

Desde o começo imaginamos criar um projeto para rodar em Linux. Todo o desenvolvimento foi realizado com o Visual Studio 2015 rodando em Windows, porém, utilizamos a versão do .NET Core. Usamos o Windows e Linux ao mesmo tempo. Isso é confuso? Começamos configurando os agentes VSTS no Linux para compilar nossos microserviços baseados em ASP.NET Core. Nosso ambiente de produção era baseado no Docker: Embora pareça apenas um Docker Host, esse ambiente era um cluster de container.

Azure Container Services contém um conjunto de máquinas virtuais instalados com o Docker Engine. Quando um container é instanciado, sua execução será direcionada para um dos nós (VMs) deste grupo de agentes. Assim, temos a garantia de alta disponibilidade.

Bots

Por fim, faltou falar do nosso projeto. A ideia era criar um Bot para responder dúvidas sobre Azure. No front-end, usamos o Microsoft Bot Framework para conectar o Bot com diferentes canais de comunicação (Skype, SMS, e-mail, etc). No back-end, criamos microserviços de busca rodando em Linux e containers Docker.

Ganhamos o Hackathon?

Com tudo isso rodando, não chegamos nem perto de ganhar o Hackathon. Investimos bastante tempo na “engenharia” do projeto e realmente avançamos pouco na inovação do projeto. O time que ganhou combinou uma série de tecnologias: IoT, Machine Learning, PowerBI, e nem me lembro mais o que. Perdemos o hackaton, mas nem tudo foi em vão. Conseguimos finalizar o projeto do Bot usando as tecnologias propostas inicialmente. Ganhamos muito conhecimento ao longo desses dois dias. Escrevemos um whitepaper sobre o projeto e também aplicamos esse conhecimento em outros projetos (ex: Arda). Foi um ótimo aprendizado.

Conclusão

O evento foi fantástico e pode ser resumido em 3 pontos:

Perdemos o hackathon: Durante um hackathon, o ótimo é inimigo do bom. Se você participar de um, exponha sua ideia da forma mais criativa possível. Esqueça a engenharia nos bastidores do projeto, pois isso não ganha ponto (ninguém vê).
Aprendemos DevOps: Trabalhamos com uma equipe de 2 ITPros e 3 Developers. Vimos na prática como é difícil definir as responsabilidades dentro da equipe, mas conseguimos enxergar o benefício de adotar os processos de Continuous Integration (CI) para Dev e Continuous Delivery (CD) para Infra.
DevOps requer investimento: Dividimos o tempo de 3 desenvolvedores entre código e DevOps. No nosso caso, parece que gastamos 75% em DevOps e apenas 25% codificando. Poderíamos ter investido 100% do tempo em código e ignorado nossa “engenharia em DevOps”. Se você quiser fazer DevOps, então saiba que há um preço a se pagar.

Como o evento de Hackathon durou apenas 2 dias (prazo curtíssimo), não conseguimos usufruir dos benefícios do DevOps. Porém, sempre que começamos um projeto, recomendo que haja um investimento de pelo menos 50% em DevOps. Esse tempo aumenta a eficiência dos desenvolvedores e traz retorno em médio e longo prazo.

Falha Nossa no Git (TOP 5)

Fabricio Catae — Wed, 19 Jul 2017 09:00:00 GMT

Fiz aqui um TOP 5 das coisas mais estranhas que notei no nosso repositório do ARDA. Seguem os links dos repositórios:

Antigo: https://github.com/DXBrazil/Arda_old Recente: https://github.com/DXBrazil/Arda

Bons desenvolvedores mantém o histórico do GIT linear e conciso usando um workflow definido (ex: gitflow), squash commit, rebase, etc. Nosso time é bom, mas ignoramos essas práticas e mantivemos todos os commits intermediários. Felizmente como o histórico ficou intacto, hoje é possível entender a história do ARDA em todos os detalhes, principalmente com os nossos erros.

Falha #5: Trabalhar sem feature branches

Por um tempo, mantivemos branches individuais por usuários e isso gerou um histórico visualmente não-linear: Em nosso projeto, não adotamos o rebase e sempre fizemos pontos de merge. Embora o rebase torne o histórico mais linear, a vantagem do merge é manter o histórico fiel aos commits realizados. Apenas como brincadeira, peguei um screenshot do SourceTree e rotacionei a imagem, tornando o nosso histórico musicalmente mais interessante: Que confusão! Hoje vejo que poderíamos ter feito um histórico mais limpo se tivéssemos adotado o workflow do Gitflow (ou semelhante) desde o princípio do projeto.

Falha #4: Guardar senhas dentro do repositório

O pior é que esse erro é muito comum nos projetos. No nosso caso, adicionamos o arquivo de secrets.json com informações de login no Redis, SQL Server e Azure Blob Storage. Em seguida, tentamos remover as senhas com um commit “removido string de conexão do sql server”. Esse commit também poderia ser renomeado para “hackers, aqui tem senha -- veja os detalhes do commit”. Embora as senhas sejam removidas dos arquivos, os commits são mantidos dentro do repositório do GIT e qualquer um que tenha acesso pode olhar o histórico do arquivo. Lição: esse erro sempre vai acontecer e se repetir, então esteja preparado para definir um processo de reset de senhas nos ambientes de desenvolvimento, teste e produção.

Falha #3: Configurar incorretamente o GIT Client

Durante a instalação do cliente do Git, você configura um usuário e email para acessar o repositório. Se tiver máquinas diferentes, então deve repetir a configuração em todas as máquinas. Falhamos nisso. Temos diversos emails registrados:

@microsoft
@hotmail
@live
[sem domínio]

Fabricio Sanchez, por exemplo, usou várias configurações de email diferente:

fabsanc@DESKTOP-GM6LNGT
fabriciosanchez@MacBook-Pro-de-Fabricio.local
fabriciosanchez@mbp-de-fabricio.guest.corp.microsoft.com

Configurar usuário e email errado tem um impacto muito baixo, mas gerou uma estatística interessante: a contribuição do Fabricio Sanchez foi apagar 165 mil linhas do projeto contra 135 mil adicionadas! Ele destruiu mais do que criou (merece um prêmio hehe). Obrigado Fabricio Sanchez por todos os seus deletes no projeto! Mas suspeito que, pelo fato de configurar o usuário/email errado, fez com que suas adições fossem ignoradas. No final, isso não tira o mérito dele em ser um grande contribuidor do projeto ARDA.

Falha #2: Erro no arquivo Git Ignore

Outro erro comum é esquecer de configurar o arquivo do Git Ignore (.gitignore) e incluir arquivos desnecessários no controle de versão. Entre os casos mais comuns estão os diretórios bin, out, obj, bower_components, node_modules.

O que há de errado em incluir as dependências do NodeJS (diretório node_modules)?

Simples: esse diretório tem 7302 arquivos que não precisam estar versionados no Git. Mas por incrível que pareça, nosso time do ARDA não cometeu essa falha!!! O Visual Studio cria automaticamente o arquivo com as extensões a serem ignoradas e, por isso, o .gitignore estava correto desde o começo do projeto. Entretanto, nós fizemos melhor: nosso estagiário (sempre ele!) adicionou o caminho do nosso projeto Arda.Main dentro do Git ignore. Quando você faz isso, erros estranhos acontecem no projeto do Arda.Main:

Arquivo existentes: continuam “trackeados” pelo git e a atualização funciona
Arquivos novos: são ignorados pelo .gitignore e não são incluídos no projeto

Esse comportamento gerou erros aleatórios por um bom tempo. Determinadas modificações do Arda.Main funcionavam, outras não. Só fomos descobrir a causa do problema dias depois.

Falha #1: Falta de controle no master

Nossos repositórios (GitHub e VSTS) são protegidos por senha, mas qualquer um do time podia entrar no repositório e editar os arquivos. Pela descrição, dá para identificar algumas gambiarras. Por exemplo, commits correspondentes a Work in Progress (WIP) estão em vários lugares no histórico do Git. Tem outros commits de “adjusting dockerfile again” ou “once again, trying to adjust the path” realizados direto na master. Isso sem contar que usamos o repositório master para demonstrações no Tech Summit 2016. A coisa fica feia quando aparece um root fazendo commit. Até hoje não sei de onde veio esse commit, mas acho que foi alguém usando o VIM dentro de um Ubuntu para rodar os containers. Entendo que diversas vezes usamos essa aplicação para demonstração em eventos. Entretanto, a nossa branch master ficou uma bagunça. Se esse projeto fosse crítico (mais crítico do que é atualmente), a gente deveria fazer Fork do repositório e trabalhar nele. Enfim, várias formas de organizar o acesso aos repositórios.

Conclusão

Seu time realmente sabe trabalhar com o Git? No nosso caso, estamos (sempre) aprendendo… E vocês? Compartilhem suas experiências ruins nos comentários - as boas experiências já conhecemos!