Pausa para café #120. Operadores Java &, && (AND) || (OU). Introdução ao GitOps e DevOps para desenvolvedores

Operadores Java &, && (AND) || (OU)

Fonte: freeCodeCamp Na linguagem de programação Java, usamos operadores para realizar operações em variáveis. Os operadores são divididos em diferentes categorias: operadores aritméticos, operadores de atribuição, operadores de comparação, operadores lógicos e assim por diante. Neste artigo, falaremos sobre o operador AND bit a bit ( & ), bem como os operadores lógicos AND ( && ) e OR ( || ).

Como usar o operador AND bit a bit

O símbolo & denota o operador AND bit a bit. Ele avalia o valor binário de determinados números. O resultado binário desses números nos será retornado na base 10. Quando o operador & iniciar seu trabalho, ele avaliará o valor dos caracteres em ambos os números, começando pela esquerda. Vejamos um exemplo para ajudar a entender isso melhor:

System.out.println(10 & 12);
// returns 8

Como explicar isso? O valor binário de 10 é 1010. O valor binário de 12 é 1100. Aqui está o que precisamos considerar antes de iniciar a operação: 1 e 0 => 0 0 e 1 => 0 1 e 1 => 1 0 e 0 = > 0 Então vamos fazer a operação. O primeiro símbolo para 10 é 1, o primeiro símbolo para 12 também é 1, portanto: 1 e 1 = 1. Passando para os segundos símbolos - 0 para 10 e 1 para 12: 1 e 0 = 0. Para os terceiros símbolos - 1 para 10 e 0 para 12: 1 e 0 = 0. Para os quartos caracteres - 0 para 10 e 0 para 12: 0 e 0 = 0. Agora vamos combinar todos os caracteres retornados. Isso nos dá 1.000. O valor binário de 1.000 na base 10 é 8, então nossa operação retornou 8.

Como usar o operador lógico AND

Observe que usamos operadores booleanos para avaliar condições. Eles retornam verdadeiro ou falso dependendo das condições fornecidas. O símbolo && representa o operador AND. Ele avalia duas declarações/condições e retorna verdadeiro somente se ambas as declarações/condições forem verdadeiras. Esta é a aparência de sua sintaxe:

statment1/condition1 && statemnt2/condition2

Como você pode ver acima, existem duas instruções/condições separadas por uma instrução. O operador avalia o valor de ambas as declarações/condições e nos dá o resultado - true ou false . Aqui está um exemplo:

System.out.println((10 > 2) && (8 > 4));
//true

A operação retornará verdadeiro porque ambas as condições são verdadeiras: 10 é maior que 2 e 8 é maior que 4. Se alguma das condições tivesse lógica incorreta, receberíamos false . Para entender melhor o operador && , você deve saber que ambas as condições devem ser verdadeiras para serem avaliadas como verdadeiras . Aqui está outro exemplo que retorna false :

System.out.println((2 > 10) && (8 > 4));
// false

Aqui 2 não é maior que 10 e 8 é maior que 4 - então obtemos false . Isso ocorre porque uma das condições está incorreta.

• Se ambas as condições forem verdadeiras => verdadeiras

• Se uma das duas condições for falsa => falsa

• Se ambas as condições forem falsas => falsas

Como usar o operador booleano OR

Para denotar o operador OR usamos o símbolo || . Este operador retorna falso somente se ambas as condições forem falsas. Ou seja, se ambas as condições forem verdadeiras, obteremos true e, se uma das duas condições for verdadeira, também obteremos true . Aqui está a sintaxe:

statment1/condition1 || statemnt2/condition2

Vejamos alguns exemplos.

System.out.println((6 < 1) || (4 > 2));
// true

True é retornado para nós porque uma das condições é verdadeira.

• Se ambas as condições forem verdadeiras => verdadeiras

• Se uma das condições for verdadeira => verdadeira

• Se ambas as condições forem falsas => falsas

Conclusão

Neste artigo, aprendemos como usar o operador bit a bit & e os operadores lógicos && e || em Java. . Também aprendemos qual valor cada operação retorna dependendo de suas condições.

Introdução ao GitOps e DevOps para desenvolvedores

Fonte: Hackernoon Um dos principais objetivos do DevOps é ajudar os desenvolvedores a implantar um recurso na produção da maneira mais rápida e segura possível. Isso significa criar ferramentas e processos que fazem tudo, desde fornecer ambientes de desenvolvimento privados até implantar e proteger cargas de trabalho de produção. Ao mesmo tempo, a pressa não deve levar a falhas críticas. GitOps é uma forma de automatizar DevOps. Mais especificamente, é uma tática de automação utilizando a ferramenta de desenvolvimento Git. Como os desenvolvedores já enviam código para um repositório Git centralizado (usando algo como GitHub, GitLab ou BitBucket), os desenvolvedores DevOps podem conectar qualquer um de seus scripts de trabalho para construir, testar ou implantar aplicativos para execução após cada alteração no código ser feita. Isso significa que os desenvolvedores podem trabalhar exclusivamente com Git, e tudo que os ajuda a colocar seu código em produção será automatizado.

Por que GitOps?

Anteriormente, os métodos DevOps e CI/CD eram um conjunto de scripts e ferramentas proprietários que executavam tarefas diárias: execução de testes, provisionamento de infraestrutura ou implantação de um aplicativo. No entanto, a disponibilidade de novas ferramentas de infraestrutura, como o Kubernetes, juntamente com o surgimento de arquiteturas de microsserviços, exige que os desenvolvedores se envolvam mais nos processos de CI/CD. Essa mudança criou problemas relacionados aos cenários dos usuários, resultando em fluxos de trabalho confusos e inconsistentes, duplicação de esforços e uma diminuição acentuada na velocidade de desenvolvimento. Para aproveitar as vantagens das ferramentas e arquiteturas de nuvem, as equipes precisam de uma abordagem consistente e automatizada de CI/CD. Isso permitirá que os desenvolvedores:

• Pare de criar e manter scripts proprietários e, em vez disso, use um processo universal.

• Crie aplicativos e serviços mais rapidamente com um processo de implantação universal especificado.

• Implante mais rapidamente depois de fazer alterações no código.

• Habilite a implantação automatizada para lançamentos mais rápidos, frequentes e confiáveis.

• Execute reversões e auditorias para conformidade com padrões de design declarativos.

Os desenvolvedores adoram GitOps

Por todas as razões expostas acima (e muitas outras), as empresas precisam de abordagens gerenciadas e automatizadas de CI/CD e DevOps para ter sucesso na construção e manutenção de aplicações em nuvem. Mas se a automação é tudo o que existe, então por que o GitOps é melhor do que outras estratégias (como SlackOps, implantações agendadas ou scripts simples)? A resposta é simples: os desenvolvedores adoram o GitOps.

Git – uma ferramenta para gerenciar tudo

Nos últimos anos, ficou claro que o GitOps é uma das estratégias de automação DevOps mais bem avaliadas entre os desenvolvedores, e não é difícil perceber porquê. Os desenvolvedores vivem no Git. Eles armazenam alterações temporárias no git, colaboram usando o git, revisam o código usando o git e mantêm um histórico e uma trilha de auditoria de todas as alterações que alguém já fez, também no git. Como os desenvolvedores passaram a depender tanto do git, existem ferramentas especiais disponíveis para trabalhar com ele. Em sistemas modernos de integração contínua que são mais frequentemente usados ​​para suportar GitOps, como CircleCI , Github Actions , Gitlab CI e outros, as configurações que suportam pipelines estão localizadas diretamente no repositório Git. Assim como o código-fonte do aplicativo, essas configurações são controladas por versão e visíveis para todos os desenvolvedores que trabalham no projeto. Eles não apenas podem ver como é o processo do pipeline, mas também podem fazer alterações nele de maneira rápida e fácil, conforme necessário. Essa facilidade de acesso para os desenvolvedores é fundamental, pois eles escrevem testes para seus aplicativos e garantem sua segurança e estabilidade.

Autoatendimento completo

Novos recursos ou correções de bugs não são considerados completos até serem lançados em produção. Isso significa que qualquer coisa que impeça que alterações no código sejam feitas na produção desperdiça tempo e energia do desenvolvedor. Suponha que um desenvolvedor precise esperar algum tempo até que outra equipe ou pessoa conclua alguma tarefa antes de poder encerrar sua etapa de trabalho. Isso pode criar atritos e conflitos na organização. Facilitar a colaboração entre equipes é um dos principais benefícios do GitOps. Os desenvolvedores não apenas têm a oportunidade de trabalhar em uma ferramenta familiar, mas também podem liberar seu código para produção sem intervenção manual. Isso significa que eles não esperam que outra pessoa conclua suas tarefas.

Trabalho contínuo em tudo

Outro grande benefício do GitOps é que todos os processos estão sempre em execução! Cada mudança que fazemos aciona compilações e implantações de teste sem quaisquer etapas manuais. Como os desenvolvedores usarão git com ou sem GitOps, conectar-se ao fluxo de trabalho existente para executar processos DevOps é uma opção ideal para automação.

GitOps na prática

Naturalmente, o envolvimento dos desenvolvedores no processo levou as equipes a fazer uso generalizado de ferramentas fáceis de usar, como o Git. Isso também cria uma consistência natural para as fases de integração/implantação de CI/CD. Afinal, existem tantas coisas disponíveis em um repositório Git (por exemplo, commits, pull requests de abertura/fechamento, mesclagens, etc.), então a aparência da maioria das implementações de GitOps envolve um conjunto de etapas típicas:

1. Solicitações pull, testes e ambientes de visualização

Depois que os desenvolvedores passaram algum tempo escrevendo o código para seu novo recurso, eles normalmente enviam esse código para uma nova ramificação do Git e enviam uma solicitação Pull ou uma solicitação Merge de volta à ramificação principal do repositório. Os desenvolvedores fazem isso todos os dias. O prompt exige que os gerentes técnicos revisem as alterações no código e as aprovem para serem mescladas no código do aplicativo principal. Esta é uma grande oportunidade para o DevOps adicionar tarefas adicionais. Ao conectar-se aos eventos de abertura/fechamento gerados por esse processo de pull request usando uma ferramenta de integração contínua (CI), as equipes de DevOps podem acionar a execução de testes unitários, a criação de ambientes de visualização e a execução de testes de integração nesses ambientes. Essas ferramentas permitem que os engenheiros estabeleçam rapidamente confiança nas alterações de código e permite que os gerentes de produto vejam as alterações no código por meio de um ambiente de visualização pré-mesclagem. Uma confiança mais próxima significa uma fusão mais rápida. Quanto menos e com mais frequência os dados forem inseridos, menos reversões complexas e confusas. Essa técnica GitOps é fundamental para equipes de desenvolvimento e produção mais rápidas e saudáveis.

2. Mesclar com master e implantar para teste

Depois que todas as partes tiverem revisado as alterações, o código poderá ser mesclado no branch master do repositório junto com as alterações feitas pelo restante da equipe de desenvolvimento. Este branch master é frequentemente usado como área de teste para código que está quase pronto para produção. Ainda há tempo para concluir algumas tarefas operacionais, como testes e implantação. Embora normalmente testemos o código para cada solicitação pull antes de mesclá-lo, é uma boa ideia executar novamente os testes para garantir que o código funcione com outras alterações feitas pelo restante da equipe. Também vale a pena implantar todas essas alterações em um ambiente comum (chamado de “teste”) que toda a equipe possa usar para revisar e testar as alterações mais recentes antes de serem lançadas para os clientes.

3. Reduza as versões e implante na produção

Finalmente, depois que os gerentes e engenheiros tiveram tempo para revisar e testar as alterações mais recentes na ramificação upstream, as equipes estão prontas para lançar a versão e implantá-la na produção! Essa tarefa geralmente é executada por um gerente de lançamento, um membro da equipe dedicado (ou rotativo) encarregado de executar scripts de implantação e monitorar o lançamento. Sem usar GitOps, esse membro da equipe deve verificar onde estão os scripts corretos, em que ordem executá-los e se todas as bibliotecas e pacotes corretos necessários para executar os scripts estão instalados em sua máquina. Com o GitOps, podemos vincular essa implantação a outro evento baseado em Git: a criação de uma versão ou tag. Tudo o que um gerente de lançamento precisa fazer é criar um novo “lançamento”, geralmente usando semver como nome. As tarefas para criar e implantar alterações de código serão executadas automaticamente. Como a maioria das tarefas executadas por uma ferramenta de CI, elas serão configuradas com a localização dos scripts e a ordem das bibliotecas e pacotes necessários para executá-los.

Ferramentas GitOps

Uma ferramenta de integração contínua robusta e intuitiva não é a única coisa necessária para instrumentar processos GitOps como os descritos neste artigo. Um sistema de CI pode acionar scripts com base em eventos git, mas você ainda precisa de ferramentas poderosas para executar esses scripts e torná-los fáceis e seguros de executar e manter. A implantação de alterações de código (também conhecidas como entrega contínua, CD) é uma das etapas mais difíceis de automatizar. Por isso selecionamos diversas categorias de ferramentas que podem te ajudar em sua jornada no GitOps:

Conteinerização com Docker

O Docker trouxe o desenvolvimento em nuvem para um ambiente distribuído totalmente novo e ajudou os desenvolvedores a começar a considerar de forma realista as arquiteturas de microsserviços como uma opção viável. Uma das coisas que torna o Docker tão poderoso é o quão conveniente ele é para os desenvolvedores em comparação com as soluções de virtualização da geração anterior. Tal como acontece com as configurações de CI declarativas encontradas em nossos repositórios, os desenvolvedores simplesmente precisam escrever e manter um Dockerfile em seu repositório para permitir construções automatizadas de máquinas virtuais implantadas em contêineres. A conteinerização é uma tática extremamente poderosa para equipes de nuvem e deve ser uma ferramenta central em seu repertório.

Infraestrutura como Código (IaC)

Muito é necessário para preparar a infraestrutura e implantar aplicativos que não estão armazenados em um Dockerfile. Para todo o resto, existem soluções de infraestrutura como código (IaC), como Terraform , Cloudformation e outras. Essas soluções permitem que os desenvolvedores descrevam outras partes do aplicativo, como recursos do Kubernetes, balanceadores de carga, rede, segurança e muito mais, de forma declarativa. Assim como as configurações de CI e Dockerfiles descritos anteriormente, os modelos IaC podem ter versão controlada e compartilhados entre todos os desenvolvedores da sua equipe.