Todos os posts de Oscar Luiz Casagrande

Executando sp_updatestats no banco de dados AWS RDS

Parte das tarefas de manutenção que executo em um banco de dados MSSQL Content Manager é executar o procedimento armazenado sp_updatestats.


exec sp_updatestats

No entanto, isso não é compatível com uma instância do AWS RDS. A mensagem de erro abaixo indica que somente a conta sa pode fazer isso:

Msg 15247, Level 16, State 1, Procedure sp_updatestats, Line 15 [Batch Start Line 0]
User does not have permission to perform this action.

Em vez disso, existem várias postagens que sugerem o uso de UPDATE STATISTICS: https://dba.stackexchange.com/questions/145982/sp-updatestats-vs-update-statistics

Me deparei com a seguinte postagem de 2008 (!!!), https://social.msdn.microsoft.com/Forums/sqlserver/en-US/186e3db0-fe37-4c31-b017-8e7c24d19697/spupdatestats-fails-to- run-with-permission-error-under-dbopriveleged-user, que descreve uma maneira de encapsular a chamada para sp_updatestats e executá-la em um usuário diferente:

create procedure dbo.sp_updstats
with execute as ‘dbo’
as
exec sp_updatestats
go

grant execute on dbo.sp_updstats to [TCMDBUser]
go

exec dbo.sp_updstats

Executei o código acima como usuário administrador do RDS e pareceu funcionar. A saída foi muito semelhante à saída do sp_updatestats, então concluo que realmente funcionou;)

fonte: https://yatb.mitza.net/2017/03/running-spupdatestats-on-aws-rds.html

Como usar Tema DARK no SQL Management Studio

Oi bacana, blz? Estava eu aqui estudando e já quando era de noite aquela tela clara no meu rosto… era a tela da SQL Management Studio… bom, não pensei duas, imediatamente fui no menu para mudar isso… para minha surpresa não tinha opção para isso, fiquei muito desapontado, dei uma pesquisada e vou compartilhar aqui contigo como fazer :).

Ao ao abrir o SQL Studio você vai se deparar com o ambiente assim

A primeira coisa que você deve fazer é ir tem Tools > Options


Em Environment > General, você vai nogrupo Visual experience em Color theme e seleciona dark, certo? Bom, não para todos, no meu caso o padrão estava assim (talvez seja o seu também agora):

Para resolver isso vá o Explorer em C:\Program Files (x86)\Microsoft SQL Server Management Studio 18\Common7\IDE*

* Microsoft SQL Server Management Studio 18 – Essa é minha versão, ai você coloca na sua versão

Abra o arquivo ssms.pkgundef em algum editor de texto do seu gosto, pesquise por // Remove Dark theme, e comente e a linha abaixo dele e salve o arquivo

Antes

Depois

Agora feche o SQL Studio e abra-o novamente, e você verá que o tema Dark agora está disponível.

Basta selecioná-lo e clicar em ok, pronto! Agora você terá um belo tema dark para trabalhar.

Espero que você tenha gostado. Abraço e até a próxima!

The Twelve-Factor App

Após ler e entender bem os 12 fatores, com certeza você passará a ter uma visão totalmente diferente do ponto de vista arquitetura e engenharia do seu produto/sistema.

O pessoal que fez esse documento é o mesmo quem toca o Heroku, dá para considerar pelo menos um pouco relevante o conteúdo.

Introdução

Na era moderna, software é comumente entregue como um serviço: denominados web apps, ou software-como-serviço. A aplicação doze-fatores é uma metodologia para construir softwares-como-serviço que:

  • Usam formatos declarativos para automatizar a configuração inicial, minimizar tempo e custo para novos desenvolvedores participarem do projeto;
  • Tem um contrato claro com o sistema operacional que o suporta, oferecendo portabilidade máxima entre ambientes que o executem;
  • São adequados para implantação em modernas plataformas em nuvem, evitando a necessidade por servidores e administração do sistema;
  • Minimizam a divergência entre desenvolvimento e produção, permitindo a implantação contínua para máxima agilidade;
  • E podem escalar sem significativas mudanças em ferramentas, arquiteturas, ou práticas de desenvolvimento.

A metodologia doze-fatores pode ser aplicada a aplicações escritas em qualquer linguagem de programação, e que utilizem qualquer combinação de serviços de suportes (banco de dados, filas, cache de memória, etc).

Experiência

Os contribuidores deste documento estão diretamente envolvidos no desenvolvimento e implantação de centenas de aplicações, e indiretamente testemunhando o desenvolvimento, operação e escalada de centenas de milhares de aplicações através de seu trabalho na plataforma Heroku.

Este documento sintetiza toda nossa experiência e observação em uma variedade de aplicações que operam como software-como-serviço. Isto é a triangulação de práticas ideais ao desenvolvimento de software, com uma atenção particular a respeito das dinâmicas de crescimento orgânico de uma aplicação ao longo do tempo, a dinâmica de colaboração entre desenvolvedores trabalhando em uma base de código, e evitando os custos de erosão de software

Nossa motivação é aumentar a consciência de alguns problemas sistêmicos que temos visto no desenvolvimento de aplicações modernas, prover um vocabulário comum para discussão destes, e oferecer um amplo conjunto de soluções conceituais para esses problemas com a terminologia que os acompanha. O formato é inspirado nos livros de Martin Fowler Padrões de Arquitetura de Aplicações Enterprise e Refatorando.

Quem deve ler este documento?

Qualquer desenvolvedor que esta construindo aplicações que rodam como serviço. Engenheiros de Operações que implantam ou administram tais aplicações.

Os Doze Fatores

I. Base de Código
Uma base de código com rastreamento utilizando controle de revisão, muitos deploys

II. Dependências
Declare e isole as dependências

III. Configurações
Armazene as configurações no ambiente

IV. Serviços de Apoio
Trate os serviços de apoio, como recursos ligados

V. Construa, lance, execute
Separe estritamente os builds e execute em estágios

VI. Processos
Execute a aplicação como um ou mais processos que não armazenam estado

VII. Vínculo de porta
Exporte serviços por ligação de porta

VIII. Concorrência
Dimensione por um modelo de processo

IX. Descartabilidade
Maximizar a robustez com inicialização e desligamento rápido

X. Dev/prod semelhantes
Mantenha o desenvolvimento, teste, produção o mais semelhante possível

XI. Logs
Trate logs como fluxo de eventos

XII. Processos de Admin
Executar tarefas de administração/gerenciamento como processos pontuais

XII. Processos de Admin
Executar tarefas de administração/gerenciamento como processos pontuais

Fontes
https://12factor.net/pt_br/ – português
https://12factor.net/ – inglês
https://pt.wikipedia.org/wiki/Metodologia_Twelve-Factor_App

de forma prática, a diferença dos arquitetos de ti

Ultimamente tenho visto muita gente falando sobre ser ou contratar arquiteto, ai começam as dicussões, o quanto o arquiteto que tem que liderar time, programar, fazer apresentações, saber DevOps/SRE, saber fazer testes… enfim, resolvi escrever de forma mais comportamental o que eu enxergo

Arquiteto técnico (ou líder técnico): foca na maior parte do tempo em aspectos de implementação tecnológica e está envolvido de forma ativa na codificação. A tecnologia envolvida nesse caso já é aplicada em outras frentes da organização e ele o faz no seu escopo de projeto com expertise e detalhe. Porém, não é esperado um amplo conhecimento da estratégia organizacional e do ciclo de vida completo da solução ou produto.

Arquiteto de soluções: é alocado em um projeto ou programa (conjunto de projetos) com a responsabildiade de garantir a integridade técnica e a consistência da solução ao longo de todo o seu ciclo de vida e da estratégia organizacional. Arquitetos de solução não estão normalmente codificando o tempo todo, pois a coordenação das atividades técnicas consome a maior parte do seu tempo. Além disso, em um contexto em que existem POCs ou incerteza, faz muito sentido o arquiteto de soluções faço o papel do arquiteto técnico.

Arquiteto corporativo: possui visão de toda a empresa, como o nome sugere. Preocupando-se com a visão holística de TI, desde a infraestrutura até frameworks arquiteturais de forma a otimizar resultados operacionais e entregar a estratégia corporativa.

Kafka – Uma visão executiva Inicial

O que é Event Stream Processing? E o que é o Kafka?

O processamento de fluxo de eventos, ou ESP, é um conjunto de tecnologias projetadas para auxiliar na construção de sistemas de informações orientados a eventos. – Wikipedia

Apache Kafka é uma plataforma open-source de processamento de streams desenvolvida pela Apache Software Foundation, escrita em Scala e Java. O projeto tem como objetivo fornecer uma plataforma unificada, de alta capacidade e baixa latência para tratamento de dados em tempo real. – Wikipédia

O Apache Kafka é uma solução largamente utilizada tanto em empresas de pequeno porte como em empresas de muito grande porte. – Confluent

Apache Kafka é um sistema de mensagens Publisher-subscriber/publicador-assinante originalmente projetado para resolver o problema de comunicação de dados ponto a ponto e processamento de dados entre vários sistemas dentro de uma organização. A maioria das organizações tem fontes de dados onde os dados são gerados e consumidos de várias formas, de dados estruturados transacionais a arquivos de log e saídas ETL. A troca de dados entre esses sistemas geralmente resulta em uma explosão de sistemas distintos, processando-os com diferentes pipelines de dados. O Kafka surgiu da necessidade de fornecer uma plataforma consolidada para oferecer suporte a um fluxo de dados contínuo e perfeito entre esses sistemas. – Gartner

5 passos para adoção do Kafka

  1. Interesse inicial: O desenvolvedor (engenheiro/arquiteto) faz o download de Kafka e faz experimentos e pilotos;
  2. Identificação de um projeto / Iniciar a configuração do pipeline: LOBs: experimento de pequenas equipes: 1-3 casos de uso de pipeline básico – mover rapidamente para a produção – mas fragmentado;
  3. Missão crítica, porém com LOBs díspares:Vários casos de uso de missão crítica em produção, incluindo aplicativos orientados a eventos contextuais com escala, DR e SLAs. Streaming claramente entregando valor de negócios, com visibilidade C-Levels, mas fragmentado em LOBs;
  4. Missão crítica, LOBs conectadas: Plataforma de streaming que gerencia a maioria dos processos de missão crítica globalmente com replicação de vários datacenters em nuvens locais e híbridas; em paralelo com outras infraestruturas de big data; LOBs conectados;
  5. Sistema nervoso central baseado em Event Stream: Todos os dados na organização são gerenciados por meio de uma única plataforma de streaming. Normalmente produtos nascidos no mundo digital ou que se tornaram 100% digital, provavelmente usando Machine Learning e AI;

LOB – Line of business

Arquitetura do Kafka


  • Broker: um único nó Kafka é um broker. Ele recebe mensagens de produtores, atribui deslocamento e confirma as mensagens para armazenamento. Ele atende às solicitações de busca dos consumidores para partições de tópico e envia a mensagem.
  • Produtor/Producer: um aplicativo ou sistema que pode gravar dados no cluster Kafka é o produtor. Esta é a fonte de mensagens para tópicos do Kafka. Os produtores publicam mensagens de acordo com os protocolos Kafka. O produtor se conecta a pelo menos um broker para buscar metadados e, em seguida, envia a sequência de bytes ordenada ao broker. É responsabilidade do produtor Kafka determinar quais dados de partição de tópico precisam ser enviados.
  • Consumidor/Consumer: os consumidores Kafka consomem as mensagens criadas pelos produtores dos tópicos Kafka. Os consumidores assinam um ou mais tópicos. Cada consumidor tem uma identidade única e controla como lê os dados da partição de tópico Kafka. Os consumidores têm compensações de consumidor que são armazenadas no Apache ZooKeeper.
  • Registro: os dados gravados no Kafka são chamados de registro. Geralmente não há limite de tamanho, mas os registros geralmente têm menos de 1 MB.
  • Tópico: Kafka organiza conjuntos de registros em tópicos. Um tópico é um agrupamento de informações relacionadas que seriam do interesse de um consumidor. Da mesma forma que um cliente se inscreve em uma lista de correio ou grupo de distribuição específico, um consumidor Kafka se inscreve em um tópico.
  • Partição: cada tópico é armazenado como várias partições. Novos registros gravados em um tópico Kafka são anexados a uma partição para esse tópico. O Kafka escolhe e equilibra automaticamente as partições para o tópico (isso também pode ser feito manualmente). Mais partições permitem o dimensionamento paralelo de gravações e leituras de tópicos.
  • Replicação: Cada partição é replicada entre os brokers. Os produtores e consumidores irão gravar e ler em uma partição líder, mas várias partições de réplicas sincronizadas são mantidas em cada partição líder. Isso fornece redundância de dados em caso de falhas do corretor.
  • Cluster: coleções de corretores formam clusters Kafka. Como as partições são replicadas entre os brokers, os consumidores chamam os dados de vários brokers. Cada partição pertence a um broker, conhecido como líder dessa partição. Existem cópias de cada partição em outros brokers, conhecidos como réplicas.
  • Offset: Cada mensagem no Kafka é atribuída com um offset. Os tópicos consistem em partições, e cada partição armazena mensagens na ordem em que chegam. Os consumidores reconhecem as mensagens com um deslocamento, indicando que todas as mensagens anteriores ao deslocamento foram recebidas pelo consumidor.
  • ZooKeeper: uma ferramenta como o Apache ZooKeeper é necessária para gerenciar um cluster de corretores. O ZooKeeper mantém metadados de cluster, incluindo tópicos e listas de corretores ativos.
  • Persistente: o Kafka usa armazenamento durável para manter todos os registros. Os dados gravados no Kafka são retidos por parâmetros de tempo configuráveis chamados tempo de vida (TTL), como horas, dias ou mais. O conceito de persistência de dados de Kafka permite que Kafka armazene o consumo de seus conjuntos de dados. Os consumidores podem extrair dados em suas próprias velocidades – em milissegundos ou dias. O TTL padrão é sete dias.
  • Append-only/Somente anexo: depois que os dados são gravados no Kafka, eles se tornam imutáveis. Os registros não são alterados, apenas novos adicionados. Isso cria uma trilha de auditoria e permite a reconstrução e a proveniência de todos os registros em um sistema Kafka. Os dados brutos também são preservados e se prestam a casos de uso de consumo adicionais.
  • Publisher-subscriber/Publicador-assinante: comunicação dos corretores Kafka entre os processos do cliente que produzem ou consomem registros. Kafka implementa essa comunicação usando o padrão publicar-assinar (pub-sub). Esse padrão é fundamental para arquiteturas orientadas a eventos, permitindo que um ou mais produtores publiquem registros de eventos em um tópico sem conhecimento dos destinatários e permitindo que um número arbitrário de consumidores receba e processe esses eventos de forma independente e assíncrona.

Referências

https://en.wikipedia.org/wiki/Event_stream_processing
https://pt.wikipedia.org/wiki/Apache_Kafka
https://www.infoq.com/br/articles/apache-kafka-licoes/
https://www.confluent.io/apache-kafka-report/


Manifesto para Desenvolvimento Ágil de Software

Estamos descobrindo maneiras melhores de desenvolver
software, fazendo-o nós mesmos e ajudando outros a
fazerem o mesmo. Através deste trabalho, passamos a valorizar:

Indivíduos e interações mais que processos e ferramentas
Software em funcionamento mais que documentação abrangente
Colaboração com o cliente mais que negociação de contratos
Responder a mudanças mais que seguir um plano

Ou seja, mesmo havendo valor nos itens à direita,
valorizamos mais os itens à esquerda.

Princípios por trás do Manifesto Ágil

Nós seguimos estes princípios:

Nossa maior prioridade é satisfazer o cliente
através da entrega contínua e adiantada
de software com valor agregado.

Mudanças nos requisitos são bem-vindas,
mesmo tardiamente no desenvolvimento.
Processos ágeis tiram vantagem das
mudanças visando vantagem competitiva para o cliente.

Entregar frequentemente software funcionando,
de poucas semanas a poucos meses,
com preferência à menor escala de tempo.

Pessoas de negócio e desenvolvedores devem trabalhar
diariamente em conjunto por todo o projeto.

Construa projetos em torno de indivíduos motivados.
Dê a eles o ambiente e o suporte necessário
e confie neles para fazer o trabalho.

O método mais eficiente e eficaz de transmitir
informações para e entre uma equipe de desenvolvimento
é através de conversa face a face.

Software funcionando é a medida primária de progresso.

Os processos ágeis promovem desenvolvimento
sustentável. Os patrocinadores, desenvolvedores e
usuários devem ser capazes de manter um ritmo
constante indefinidamente.

Contínua atenção à excelência técnica e bom design
aumenta a agilidade.

Simplicidade–a arte de maximizar a quantidade de
trabalho não realizado–é essencial.

As melhores arquiteturas, requisitos e designs
emergem de equipes auto-organizáveis.

Em intervalos regulares, a equipe reflete sobre como
se tornar mais eficaz e então refina e ajusta seu
comportamento de acordo.

Fontes:
https://agilemanifesto.org/iso/ptbr/manifesto.html
https://agilemanifesto.org/iso/ptbr/principles.html

As Oito Falácias da Computação Distribuída

Essencialmente, todos, quando criam um aplicativo distribuído pela primeira vez, fazem as oito seguintes suposições. Todos se revelam falsos a longo prazo e todos causam grandes problemas e experiências de aprendizado dolorosas.

  1. A rede é confiável
  2. Latência é zero
  3. A largura de banda é infinita
  4. A rede é segura
  5. A topologia não muda
  6. Existe um administrador
  7. Custo de transporte é zero
  8. A rede é homogênea

Para mais detalhes, leia o artigo de Arnon Rotem-Gal-Oz

Fonte: http://nighthacks.com/jag/res/Fallacies.html

Como escolher uma licença para seu projeto

Bacanas, estou estudando bastante e acabado salvando no github todos os meus estudos, ai comecei a pensar “qual licença devo utilizar para esses estudos?”, e isso é bem importante uma vez as pessoas podem utilizar o meus estudos de forma educativa ou comercial, claro se o repositório estiver público. Ao pesquisar no Google me esbarrei com esse belo post do pessoal da Alura (onde faço curso tbm hehe) e nele estão explicando muito bem qual é a melhor licença para nossos trabalhos. https://www.alura.com.br/artigos/como-escolher-uma-licenca-para-seu-projeto

Abaixo estão textos extraídos do blog da Alura.

GNU General Public License v3.0 (GNU GPLv3)

A GNU GPLv3 permite que meu software seja usado e distribuído, contanto que, quando distribuído, o código fonte esteja abertamente disponível.

GNU General Public License v3.0 (GNU GPLv3)

A GNU GPLv3 permite que meu software seja usado e distribuído, contanto que, quando distribuído, o código fonte esteja abertamente disponível.
Essa licença também exige uma cópia dela mesma, com um aviso de copyright, sempre que o software for distribuído de alguma forma. Se houver alguma modificação no código de nosso software, essa licença faz com que essas modificações tenham que ser lançadas com uma licença no mínimo similar. Além do mais, qualquer mudança no código tem que ser documentada.

The Unlicense

The Unlicense é uma licença cheia de permissões, com nenhuma condição. Qualquer pessoa é livre para copiar, modificar, publicar, usar, vender ou distribuir nosso software de qualquer maneira possível, sem nenhuma pendência.

Licença MIT

A MIT é uma licença que se encaixa muito bem nos meus objetivos. No geral, é bem permissiva, sendo o requisito uma atribuição de volta a mim, com um aviso de copyright, e uma cópia dela incluída.

Essa licença não carrega muitas regras e também não chega a me prejudicar em nada, atribuindo meu trabalho a mim.

choosealicense.com

O pessoal do github fez esse site (choosealicense.com) para ajudar vc a escolher a melhor licença para o seu software choosealicense.com. Achei bem bacana tbm!

E é isso bacana, até a próxima!

O que são as siglas DDL, DML, DQL, DTL e DCL?

DDL – Data Definition Language – Linguagem de Definição de Dados.
São os comandos que interagem com os objetos do banco. São comandos DDL : CREATE, ALTER e DROP

DML – Data Manipulation Language – Linguagem de Manipulação de Dados.
São os comandos que interagem com os dados dentro das tabelas. São comandos DML : INSERT, DELETE e UPDATE

DQL – Data Query Language – Linguagem de Consulta de dados. São os comandos de consulta.
São comandos DQL : SELECT (é o comando de consulta). Aqui cabe um parenteses. Em alguns livros o SELECT fica na DML em outros tem esse grupo próprio.

DTL – Data Transaction Language – Linguagem de Transação de Dados.
São os comandos para controle de transação. São comandos DTL: BEGIN TRANSACTION, COMMIT E ROLLBACK

DCL – Data Control Language – Linguagem de Controle de Dados.
São os comandos para controlar a parte de segurança do banco de dados.São comandos DCL : GRANT, REVOKE E DENY.

fonte: https://pt.stackoverflow.com/questions/262867/o-que-s%C3%A3o-as-siglas-ddl-dml-dql-dtl-e-dcl

O que é DevOps – minha experiência como executivo nessa frente.

Aqui quero trazer um pouco da minha experiência com DevOps passando por questões bem técnicas e gestão do processo. Muitas das coisas que eu pude fazer foi por uma questão de experiência em projetos e por isso tive condições de pavimentar uma estrada de sucesso para essa frente!

Eu tive a oportunidade de criar a área de DevOps por uma empresa na qual passei, então pude aprender desde subir uma máquina com wizard (next, next e finish) nas clouds AWS, Azure, e GCP, como também aprendi coisas como versionamento de imagens, configurações de Redis, pipelines simples e complexos no Jenkins, com certeza me diverti muito com isso. Também tive a oportunidade de pensar em processo e gestão dessa área, além de implantar isso,pois, claramente sem um mínimo de gestão e organização a frente de DevOps pode sucumbir e ao invés de facilitar pode travar todo o processo de melhoria e entrega contínua.

Na Ciência da Computação o DevOps (contração de development e operations), é uma prática da engenharia de software que unifica o desenvolvimento de software (Dev) e a operação de software (Ops), com característica principal de defender a automação e monitoramento em todas as fases da construção de um software (desde a integração, teste, liberação para implantação, ao gerenciamento de infraestrutura), auxiliam empresas no gerenciamento de lançamento de novas versões, padronizando ambientes em ciclos de desenvolvimento menores, frequência de implantação aumentada, liberações mais seguras, em alinhamento próximo com os objetivos de negócio. Isso segundo a Wikipedia.

CALMS

  • (C)ultura – pessoas e processos são mais importantes. Se a cultura não estiver presente, qualquer tentativa de automação está destinada a falhar;
  • (A)utomação – libere humanos para realizar tarefas que exigem criatividade e intuição e deixe as tarefas repetitivas para os computadores, que sabem executá-las rapidamente e de forma bem mais confiável;
  • (L)ean (pensamento enxuto) – diversos princípios lean influenciam a cultura DevOps, como a melhoria contínua, o foco em qualidade, a eliminiação de desperdícios, a otimização do todo e o respeito às pessoas;
  • (M)edição – se você não souber medir, não saberá avaliar se está melhorando ou piorando. Uma adoção de DevOps de sucesso irá medir tudo o que for possível, por exemplo: métricas de desempenho, métricas de processo, métricas de negócio etc;
  • (S)haring (compartilhamento) – a colaboração e o compartilhamento de ideias e conhecimento ajudam a criar a cultura necessária para o sucesso com DevOps.

FOCO

  • Provisionamento – Provisionar ambientes de infraestrutura como código significa de forma automática e escalável;
  • Monitoria– Utilização e construção de ferramentas para monitoria do ambiente;
  • Automação – Criação de pipeline CI/CD de produtos e ambientes.

PROBLEMA







O problema cosutma ser aumento de deploys, o que aumenta a quantidade de mudanças e por consequência acabamos tendo mais processo o que tende a diminuir a frequência de deploys, ou seja, temos mais dificuldade em colocar em produção o que foi construído.

SOLUÇÃO

Aqui começa a ficar claro que quanto mais automação no processo você faz, mais fácil fica fazer deploy, logo seus deploys levam quantidades menores de alteração para produção e seu risco diminui. E tem mais, como a alteração é pequena se gerar algum erro, com o processo automatizado fazer um rollback é mais fácil, mais rápido e mais seguro.

STACK TECNOLÓGICO

Há uma gama vasta de sabores para o mundo de DevOps, porém eu segui essa linha.

DOCUMENTAÇÃO E GESTÃO

  • Slack – uma ferramenta (talvez até uma plataforma) de comunicação parecida com WhatsApp, porém com mais possibilidades, sendo permitido conectar a ela produtos como repositórios Git, Jenkins, Google Drive entre outros, é uma ferramenta para ter as comunições do time além das comunicações de deploys, merges e até mesmo alertas de produção.
  • Confluence – de forma muito simples e resumida, esse é um portal wiki, também é possível plugar aqui o Jira para ter reports relacionados ao andamento de suas sprints por exemplo, há série de templates nessa solução desde retrospectiva de sprint até visão de valores.
  • Jira – é um software comercial desenvolvido pela empresa Australiana Atlassian. É uma ferramenta que permite o monitoramento de tarefas e acompanhamento de projetos garantindo o gerenciamento de todas as suas atividades em único lugar.
  • BitBucket – Bitbucket é um serviço de hospedagem de projetos controlados através do Mercurial, um sistema de controle de versões distribuído. É similar ao GitHub.

CODIFICAÇÃO E CONSTRUÇÃO

  • Visual Studio Code – é um editor de código-fonte desenvolvido pela Microsoft para Windows, Linux e macOS. Ele inclui suporte para depuração, controle Git incorporado, realce de sintaxe, complementação inteligente de código, snippets e refatoração de código.
  • Aptana – é um software open source gratuito para IDE desenvolvido em Java que suporta as linguagens PHP, Python, Ruby, Ruby on Rails, CSS3, HTML5, JavaScript, ScriptDoc, XML e texto comum, embora também seja possível configurá-lo para suportar Adobe® AIR e Bibliotecas AJAX.
  • Vue.js – é um framework JavaScript de código-aberto, focado no desenvolvimento de interfaces de usuário e aplicativos de página única.
  • Angular – uma plataforma de aplicações web de código-fonte aberto e front-end baseado em TypeScript liderado pela Equipe Angular do Google e por uma comunidade de indivíduos e corporações. Angular é uma reescrita completa do AngularJS, feito pela mesma equipe que o construiu.
  • .Net Core – framework livre e de código aberto para os sistemas operacionais Windows, Linux e macOS. É um sucessor de código aberto do .NET Framework. O projeto é desenvolvido principalmente pela Microsoft e lançado com a Licença MIT.
  • Node.js – um interpretador de JavaScript assíncrono com código aberto orientado a eventos, criado por Ryan Dahl em 2009, focado em migrar a programação do Javascript do cliente (frontend) para os servidores, criando aplicações de alta escalabilidade (como um servidor web), manipulando milhares de conexões/eventos simultâneas em tempo real numa única máquina física.
  • MongoDB – banco de dados orientado a documentos livre, de código aberto e multiplataforma, escrito na linguagem C++. Classificado como um programa de banco de dados NoSQL, o MongoDB usa documentos semelhantes a JSON com esquemas.
  • Redis – base de dados em rede open-source, que armazena chaves com durabilidade opcional, patrocinado pela Pivotal Software e pela VMware, a partir de 2015 mudou para a Redis Labs. De acordo com o ranking mensal da DB-Engines.com, Redis é o banco de dados de valores-chave mais popular do mundo

INTEGRAÇÃO CONTÍNUA E ENTREGA CONTÍNUA

  • Jenkins – Jenkins é um servidor de automação gratuito e de código aberto. Ajuda a automatizar as partes do desenvolvimento de software relacionadas à construção, teste e implantação, facilitando a integração contínua e a entrega contínua.
  • Ansible – uma ferramenta de código aberto de provisionamento, gerenciamento de configurações e implantação de aplicativos. É executado em muitos sistemas tipo Unix e pode configurar sistemas tipo Unix, bem como Microsoft Windows. Ela inclui sua própria linguagem declarativa para descrever a configuração do sistema.
  • Nexus – É um gerenciador de repositório de arquivos binários. Permite buscar, coletar e gerenciar suas dependências para que você não esteja constantemente manipulando suas dependências dentro de seus projetos. Facilita a distribuição do seu software. Internamente, você configura sua compilação para publicar artefatos no Nexus e eles ficam disponíveis para outros desenvolvedores

CONTAIENERS (RECIPIENTES?!)

  • Kubernetes – é um sistema de orquestração de contêineres open-source que automatiza a implantação, o dimensionamento e a gestão de aplicações em contêineres. Ele foi originalmente projetado pelo Google e agora é mantido pela Cloud Native Computing Foundation.
  • Docker – é um software contêiner da empresa Docker, Inc, que fornece uma camada de abstração e automação para virtualização de sistema operacional no Windows e no Linux, usando isolamento de recurso do núcleo do Linux como cgroups e espaços de nomes do núcleo, e um sistema de arquivos com recursos de união, como OverlayFS criando contêineres independentes para executar dentro de uma única instância do sistema operacional, evitando a sobrecarga de manter máquinas virtuais (VM).

TESTES

  • Selenium – Selenium é uma estrutura portátil para testar aplicativos da web. O Selenium fornece uma ferramenta de reprodução para a criação de testes funcionais sem a necessidade de aprender uma linguagem de script de teste.
  • Sonarqube – plataforma de código aberto desenvolvida pela SonarSource para inspeção contínua da qualidade do código, para executar revisões automáticas com análise estática do código para detectar bugs, odores de código e vulnerabilidades de segurança em mais de 20 linguagens de programação.
  • BrowserStack – é uma plataforma de teste móvel e na nuvem que permite que os desenvolvedores testem seus sites e aplicativos móveis em navegadores sob demanda, sistemas operacionais e dispositivos móveis reais, sem exigir que os usuários instalem ou mantenham um laboratório interno de máquinas, dispositivos ou emuladores virtuais.
  • JMeter – é uma ferramenta que realiza testes de carga e de estresse em recursos estáticos ou dinâmicos oferecidos por sistemas computacionais. Além disso, é parte do projeto Jakarta, da Apache Software Foundation.
  • Postman – uma ferramenta com a função de testar e desenvolver APIs em uma interface bastante simples e intuitiva. Ele nos permite simular requisições HTTP de forma rápida, armazenando-as para que possamos usá-las posteriormente.

MONITORIA E LOG

  • Elasticsearch – um servidor de buscas distribuído baseado no Apache Lucene. Foi desenvolvido por Shay Banon e disponibilizado sobre os termos Apache License. ElasticSearch foi desenvolvido em Java e possui código aberto liberado sob os termos da Licença Apache.
  • Fluentd – é um coletor de dados open source que permite unificar a coleta e o consumo para melhorar o uso e compreensão dos dados. O maior usuário da ferramenta atualmente coleta logs de mais de 5.000 servidores e 5TB de dados diários, movimentando 50.000 mensagens por segundo no horário de pico. Sim, a principal razão para usá-lo é o desempenho.
  • Kibana – é um plugin de visualização de dados de fonte aberta para o Elasticsearch. Ele fornece recursos de visualização em cima do conteúdo indexado em um cluster Elasticsearch. Os usuários podem criar gráficos de barra, linha e dispersão, ou gráficos e mapas de torta em cima de grandes volumes de dados.
  • Grafana – O Grafana é uma solução de código aberto de várias plataformas para executar análises de dados, extrair métricas que compreendem a enorme quantidade de dados e monitorar aplicativos por meio de painéis personalizáveis.
  • Prometheus – é um aplicativo de software gratuito usado para monitoramento e alerta de eventos. Ele grava métricas em tempo real em um banco de dados de séries temporais criado usando um modelo de recepção HTTP, com consultas flexíveis e alertas em tempo real.

OPERAÇÃO

Em uma visão de governança a operação ficará mais ou menos assim:

  • Toda comiunicação sempre é feita pelo Slack;
  • Todo planejamento está no Jira e toda documentação está no Confluence;
  • Toda condificação está nas IDE’s e já aqui os desenvolvedores podem versionar suas imagens, com ou sem utilização de pipeline;
  • A qualidade de código está no Sonarqube;
  • O Jenkins faz a orquestração entre todos os sistemas após o commit/push no repositório
  • Através dos scripts Ansible podemos subir novas máquinas e já deixá-las configuradas por lá;
  • O Docker participa o tempo do processo de deploym uma vez que baixamos as imagens do Nexus e fazmos o deploy das mesmas através de um container Docker dentro do cluster Kubernetes;
  • As ferramentas de teste podem ser executadas em qualquer ambiente e a qualquer momento.

CI/CD

Um dos processos que pode ser seguido é:

  • Um push feito pelo desenvolvedor, o código chegará no repositório;
  • Através de SCM Pool o Jenkins pode buscar o código alterado ou através de um Webhook feito pelo BitBucket o Jenkins faz um pull no repositório;
  • O code review é disparado pelo Jenkins para o Sonarqube, só passa para a etapa de build se estiver atendendo os requisitos mínimos de qualidade;
  • A etapa de build é feita no Jenkins (já com todos as dependências) e gera o pacote de binários do produto/sistema;
  • Uma imagem do pacote é feita ou seja é feito versionamento no Nexus;
  • O deploy do pacote é feito no ambiente previsto (dev, homolog, pré-prod, prod, beta etc.)
  • Testes funcionais automatizados são executados em cima do ambiente que o deploy foi executado. Testes de carga quando são automatizados geralmente não ficam no mesmo pipeline que o deploy, são feitos em momentos apartados;
  • Para cada etapa uma notificação deve ser feita, aqui no caso é no Slack.

MÉTRICAS

É possível ter uma série de métricas através plugins do Jenkins mesmo. Mas, acho que podemos começar essas aqui:

  • Frequência de deployment – Quantidade de deploys feitos por dia, semana, mês etc., com essa métrica é possível identificar:
    • se a equipe de tecnologia é responsiva às demandas por novos recursos nos produtos ou serviços;
    • se as equipes e ferramentas de desenvolvimento são eficientes;
    • se a equipe de tecnologia está apressando a entrega de produtos incompletos ou defeituosos (caso a frequência de deployment seja muito alta).
  • Duração do ciclo de vida do desenvolvimento – aqui vemos desde a ideação do produto, conffecção de códigos até chegar no deploy e entedemos:
    • se o processo de desenvolvimento é eficiente, complexo ou burocrático demais;
    • se as equipes desenvolvedoras são competentes;
    • se algumas etapas do desenvolvimento estão apresentando gargalos (caso o ciclo tenha uma duração muito longa).
  • Números de falhas e incidentes – Agilidade e velocidade no deploy trazem o benefício de acelerar o negócio e trazer para um momento mais próximo funcionalidades para a operação. Entretanto, se subir isso com falhas, é o mesmo que acelerar problemas, e por isso devem ser medidas e jamais devem sair do radar, pois essa métrica ajudará a medir:
    • a qualidade do processo de desenvolvimento, testes e levantamento de requisitos;
    • a qualidade dos produtos ou serviços entregues;
    • o grau de colaboração entre a QA, desenvolvimento e operações.
  • Tempo Médio Para Restauração de um Serviço – Se um microsserviço ou API cair, quanto tempo demoramos para resolver isso? A velocidade em resolver esse problema determinará o sucesso da cultura de DevOps na organização. Uma vez que o serviço de DevOps deve garantir monitoria do ambiente e estabilização do ambiente, com essa métrica iremos medir:
    • a produtividade e a eficiência das equipes DevOps, de modo geral;
    • a agilidade da empresa ao responder às mudanças, considerando as pessoas, os processos e as tecnologias envolvidos no desenvolvimento;
    • o grau de feedback entre os responsáveis pelo desenvolvimento, QA, operações, negócios e usuários finais.

PROCESSO PARA DELIVERY

O que estive fazendo nos últimos anos é basicamente um processo de sempre refinar o backlog como um todo, baseado nas necessidade dos times de desenvolvimento, infra-estrutura e segurança, após isso fazia um comitê de priorização com todos e depois partia para a execução, bem simples, bem direto e sem complexidades para gestão.

Além disso eu fazia uma comunicação do que tinha combinado de ser entregue após o planejamento e antes do comitê eu mandava o que tinha sido executado, por muitas vezes um item ou outro era trocado por alguma demanda mais importante, e até chegarmos a uma maturidade sobre as estimativas a gente errava para menos ou para mais as estimativas.

Acho que a parte mais importante aqui era comunicar a todos os envolvidos sobre as entregas, principalmente quando alguma entrega não seria feita.

PADRONIZAÇÃO PARA VERSIONAMENTO DE IMAGENS

NOMEDOPRODUTO-X.Y.Z
X – Major
Y – Minor
0 – Patch
Major – Todo projeto deve começar na versão zero (ex: 0.1.0), ou seja, ainda não temos uma API definida. A partir da primeira versão de API, podemos ter a versão 1.0.0 e qualquer alteração que quebre a API, mesmo que pequena, uma nova major version deve ser lançada.
Minor – Quando a versão minor é incrementada, significa que uma nova feature foi lançada.
Patch – Versões patch (ou de correção) são lançadas quando há correção de bugs ou mudanças de segurança que não quebram a API.

CONCLUSÃO

Foi muito importante conhecer a cultura dentro de DevOps, hoje em qualquer projeto que eu inicie que tem como entregável algum produto digital/tecnológico eu já coloco pelo menos esse conteúdo em pauta, uma vez que isso acelera de forma incrível as entregas. Mas, até mesmo antes de falarmos de entrega do produto, isso força na maioria dos casos a estruturação tecnológica do projeto, os times terão que já definir os frameworks para trabalho no começo da construção, os PO’s e PM’s terão que se preocupar em utilizar melhor o repositório de estória de usuário/requerimento e a Wiki disponível para comunicar da melhor forma o que deve ser feito.

Há coisas aqui que não abordei como a monitoria com EFK, por exemplo, ou a utilização de uma ferramenta como Dynatrace ou New Relic nessa frente, isso vai em linha com um assunto de NOC/Command Center, e não queria falar disso agora, queria mesmo falar da parte mais divertida que vejo no DevOps que é de fato prover infra e automaizar isso.

Referências
https://pt.wikipedia.org/wiki/DevOps
DevOps na prática: Entrega de software confiável e automatizada eBook Kindle https://amzn.to/2Xsy0Ky