Originalmente postado em Finextra. Escrito pelo CEO da CPQi, Terry Boyland.

Nunca houve um momento mais essencial para garantir que as equipes trabalhassem juntas e entregassem recursos com velocidade e eficiência.

Implementar práticas de DevOps em seus fluxos de trabalho dá aonosso negócio estrutura para evolução constante, corte de custos e otimização da eficiência.

Isso garante que você possa se tornar seguro no conhecimento de que você tem os melhores sistemas em vigor para apoiar o seu desenvolvimento, usando processos automatizados e uma estratégia personalizada para criar um crescimentoresiliente e à prova de futuro.

Here are the 4 layers of DevOps for financial institutions:

1 | Infrastructure to Code

É importante esclarecer que a definição de ‘DevOps‘ se desvia da definição bancária talvez mais tradicional, que é uma união de pessoas de Desenvolvimento e Operações, mas sim uma combinação de pessoas de Desenvolvimento Técnico e Operações de Máquinas.

Os operadores de máquinas que normalmente teriam construído a infraestrutura de computação física agora trabalham em projetos em conjunto com os desenvolvedores, tornando-se uma única equipe.

Os operadores de máquinas são, portanto, capazes de ajudar os desenvolvedores a entender como construir e codificar a infraestrutura de seus aplicativos para eficiência e longevidade. Essencialmente, recriar a infraestrutura de energia de processamento físico dentro do código.

2| Microservices

Microsserviços são sobre arquitetura de sistema. Eles são um fragmento de código que dá a cada função de uma aplicação seu próprio ‘contêiner’. As entradas e saídas de cada fragmento são estáticas.

Isso significa que podemos mudar qualquer coisa no código sem que ele afete o resto do sistema, dando-nos serviços independentemente implantáveis, isso significa que não precisaremos fazer um teste completo do sistema ou análise de impacto completo cada vez que quisermos fazer uma mudança.

Os benefíciosdos microsserviços podem ser facilmente vistos no site mais popular do mundo: Google.com, a imagem sentada acima da barra de pesquisa é um Microservice.

Considere com que frequência essa imagem muda? Agora compare isso com a frequência com que você viu o Google derrubar todo o seu sistema/site para ter certeza de que a imagem vai funcionar para todos na infinita variedade de dispositivos que visitam o site.

Os microsserviços podem ser pequenos, mas quando são apropriadamente construídos em seus fragmentos, interfacedos corretamente e construídos, os microsserviços podem fazer alguns dos sistemas mais complexos do mundo.

Desde o gerenciamento de garantias inteiramente feito na web usando microsserviços até sistemas de negociação de títulos e ações, os microsserviços são alavancados para ajudar a manter seus sistemas funcionando o tempo todo.

Os microsserviços reduzem a quantidade de testes que devem ser feitos substancialmente, e como muitos de vocês sabem, os testes muitas vezes mastigam 30% – 50% do seu orçamento em qualquer projeto bem executado.

3 | Build-to-Test

Isso é uma mudança de mentalidade. Costumávamos escrever uma especificação, ter um comitê sentado sobre ela e depois assiná-la, colocá-la sob controle de mudança, dá-la aos desenvolvedores para codá-la, e finalmente para a equipe de testes de garantia de qualidade.

Agora, ao usar uma coleção de microsserviços para atender às necessidades de um cliente, podemos construir para testar. Isso significa que o código pode ser construído dentro da ferramenta de teste, a vantagem disso é a facilidade com que podemos fazer alterações ou testar elementos de um sistema, mudando radicalmente o ritmo em que os modelos de teste ocorrem.

Through this, by having infrastructure-to-code, developing in microservices, and building to test (all of the above), we achieve what is known as CICD (Continuous Integration, Continuous Deployment), and that means we can put changes into production on a regular basis without impacting the client base, even while they are still using the system. Então, como vamos codificar isso?

4 | Agile Methodologies

É aqui que ocorre a mudança cultural da mente. Esta camada consistirá de 3 elementos.

O primeiro é a forma como conduzimos nossas necessidades de negócios. Em vez de ter analistas de negócios altamente qualificados sentados e consultando os usuários sobre como as coisas são feitas, e se agora os usuários puderem apenas “contar uma história”.

Talvez eles pudessem dizer algo como “Eu vim esta manhã e sentei na minha mesa e coloquei meu dedo no leitor de impressões digitais e isso me deu uma lista de coisas que eu tenho que fazer hoje.” Esse é um exemplo de uma “história de usuário”.

Para todas as pessoas técnicas que lêem isso: você pode imaginar o que você estaria codificando se você recebesse essa história?

Permita-me elaborar, seria algo assim – “Eu precisaria de reconhecimento de impressões digitais, portanto biometria. Em seguida, o aplicativo precisa abrir automaticamente no momento do reconhecimento e no lado direito o usuário deve ver uma lista de ações que ele precisa tomar hoje.”

Ao construir pipelines inteiros de histórias de usuários que atendam à necessidade de cada usuário específico, podemos descrever sistemas complexos em termos que qualquer usuário pode descrever.

Estes então vão para esquadrões, o segundo elemento, que consiste em cerca de 7-12 pessoas. Cada esquadrão receberá uma série de histórias de usuários.

O que é um esquadrão?

Um esquadrão tem funções definidas, é composto por um Proprietário de Produto, Scrum Master ou um Agile Coach e uma série de funções técnicas e de teste.

Para que esses esquadrões sejam altamente produtivos, eles precisam estar cooperando plenamente ao longo do dia. Mas para aqueles que estão se afastando de leste para oeste, ou vice-versa, como seus esquadrões podem ser produtivos quando há até uma diferença de tempo de 10 horas e meia? Mas se você fosse para offshore norte a sul você estará olhando para uma ou duas horas de diferença de tempo no máximo, então você pode começar a ver esquadrões altamente produtivos que todos estarão acordados ao mesmo tempo.

Agora, o terceiro e último elemento, os esquadrões receberão caixas de tempo, tipicamente de 2 a 3 semanas, e eles se sentarão e criarão o que é chamado de plano de sprint olhando para o número de histórias de usuários que eles têm, o tamanho de seu esquadrão, quantas eles podem fazer dentro de 2 a 3 semanas, e eles vão planejar talvez as próximas 3 ou 4 caixas de tempo.

À medida que passam pelo processo de desenvolvimento, teste e colocação em produção, eles podem precisar fazer ajustes para cumprir esse período de 2 a 3 semanas, seja trazendo alguns para a frente se eles estão indo bem e antes do previsto ou empurrando um casal de volta para o próximo sprint se houve um atraso.

Este método nos permite ter entregas definidas que podem ser facilmente alteradas.

Por que isso é valioso? Pergunte a si mesmo – quantas vezes você espera que o orçamento do próximo ano seja alterado após 3 meses, ou 6 meses ou 9 meses? Quantas vezes isso aconteceu com você no passado?

Usando esses métodos ágeis, a capacidade de cortar e mudar significa que você pode controlar melhor seus orçamentos em um mundo muito volátil, e vamos enfrentá-lo, o mundo mudou.

Seus clientes não podem esperar 6 meses por novos recursos, com o DevOps, os ciclos de vida de desenvolvimento são drasticamente diminuídos, a aplicação na produção é muito mais estável, o tempo de inatividade é reduzido em mais de 5x e o tempo de recuperação diminuiu em mais de 96x.

Minha equipe adoraria a oportunidade de discutir isso mais com você, por favor, reserve uma consulta gratuita no cpqi.com ou envie um e-mail no info@cpqi.com para obter uma proposta livre de compromissos sobre como o DevOps pode ser aproveitado em seu negócio.