Pausa caffè #120. Operatori Java &, && (AND) || (O). Introduzione a GitOps e DevOps per sviluppatori

Operatori Java &, && (AND) || (O)

Fonte: freeCodeCamp Nel linguaggio di programmazione Java, utilizziamo gli operatori per eseguire operazioni sulle variabili. Gli operatori sono suddivisi in diverse categorie: operatori aritmetici, operatori di assegnazione, operatori di confronto, operatori logici e così via. In questo articolo parleremo dell'operatore AND bit a bit ( & ), nonché degli operatori logici AND ( && ) e OR ( || ).

Come utilizzare l'operatore AND bit a bit

Il simbolo & denota l'operatore AND bit a bit. Valuta il valore binario di determinati numeri. Il risultato binario di questi numeri ci verrà restituito in base 10. Quando l' operatore & inizia il suo lavoro, valuterà il valore dei caratteri in entrambi i numeri, iniziando da sinistra. Facciamo un esempio per aiutarci a capirlo meglio:

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

Come spiegarlo? Il valore binario di 10 è 1010. Il valore binario di 12 è 1100. Ecco cosa dobbiamo considerare prima di iniziare l'operazione: 1 e 0 => 0 0 e 1 => 0 1 e 1 => 1 0 e 0 = > 0 Quindi eseguiamo l'operazione. Il primo simbolo di 10 è 1, il primo simbolo di 12 è anche 1, quindi: 1 e 1 = 1. Passando ai secondi simboli - 0 per 10 e 1 per 12: 1 e 0 = 0. Per il terzo simbolo - 1 per 10 e 0 per 12: 1 e 0 = 0. Per il quarto carattere - 0 per 10 e 0 per 12: 0 e 0 = 0. Ora combiniamo tutti i caratteri restituiti. Questo ci dà 1000. Il valore binario di 1000 in base 10 è 8, quindi la nostra operazione ha restituito 8.

Come utilizzare l'operatore logico AND

Tieni presente che utilizziamo operatori booleani per valutare le condizioni. Restituiscono vero o falso a seconda delle condizioni date. Il simbolo && rappresenta l'operatore AND. Valuta due istruzioni/condizioni e restituisce vero solo se entrambe le istruzioni/condizioni sono vere. Ecco come appare la sua sintassi:

statment1/condition1 && statemnt2/condition2

Come puoi vedere sopra, ci sono due dichiarazioni/condizioni separate da una dichiarazione. L'operatore valuta il valore di entrambe le istruzioni/condizioni e ci fornisce il risultato: true o false . Ecco un esempio:

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

L'operazione restituirà true perché entrambe le condizioni sono vere: 10 è maggiore di 2 e 8 è maggiore di 4. Se una delle condizioni avesse una logica errata, riceveremmo false . Per comprendere meglio l' operatore && , dovresti sapere che entrambe le condizioni devono essere vere per essere valutate come vere . Ecco un altro esempio che restituisce false :

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

Qui 2 non è maggiore di 10 e 8 è maggiore di 4, quindi otteniamo false . Ciò è dovuto al fatto che una delle condizioni non è corretta.

• Se entrambe le condizioni sono vere => vero

• Se una delle due condizioni è falsa => falsa

• Se entrambe le condizioni sono false => false

Come utilizzare l'operatore booleano OR

Per denotare l'operatore OR utilizziamo il simbolo || . Questo operatore restituisce false solo se entrambe le condizioni sono false. Cioè, se entrambe le condizioni sono vere, diventeremo true , e se una di entrambe le condizioni è vera, diventeremo anche true . Ecco la sintassi:

statment1/condition1 || statemnt2/condition2

Diamo un'occhiata ad alcuni esempi.

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

Ci viene restituito True perché una delle condizioni è vera.

• Se entrambe le condizioni sono vere => vero

• Se una delle condizioni è vera => vera

• Se entrambe le condizioni sono false => false

Conclusione

In questo articolo abbiamo imparato come utilizzare l'operatore bit a bit & e gli operatori logici && e || in Java. . Abbiamo anche imparato quale valore restituisce ciascuna operazione a seconda delle sue condizioni.

Introduzione a GitOps e DevOps per sviluppatori

Fonte: Hackernoon Uno degli obiettivi principali di DevOps è aiutare gli sviluppatori a distribuire una funzionalità in produzione nel modo più rapido e sicuro possibile. Ciò significa creare strumenti e processi che facciano di tutto, dalla fornitura di ambienti di sviluppo privati ​​alla distribuzione e alla protezione dei carichi di lavoro di produzione. Allo stesso tempo, la fretta non dovrebbe portare a fallimenti critici. GitOps è un modo per automatizzare DevOps. Più specificamente, si tratta di una tattica di automazione che utilizza lo strumento di sviluppo Git. Poiché gli sviluppatori già inviano il codice a un repository Git centralizzato (utilizzando qualcosa come GitHub, GitLab o BitBucket), gli sviluppatori DevOps possono collegare qualsiasi script di lavoro per creare, testare o distribuire applicazioni da eseguire dopo ogni modifica al codice. Ciò significa che gli sviluppatori possono lavorare esclusivamente con Git e tutto ciò che li aiuta a mettere in produzione il loro codice sarà automatizzato.

Perché GitOps?

In precedenza, i metodi DevOps e CI/CD erano un insieme di script e strumenti proprietari che eseguivano attività quotidiane: esecuzione di test, provisioning dell'infrastruttura o distribuzione di un'applicazione. Tuttavia, la disponibilità di nuovi strumenti infrastrutturali come Kubernetes, unita alla crescita delle architetture di microservizi, richiede che gli sviluppatori siano maggiormente coinvolti nei processi CI/CD. Questa modifica ha creato problemi relativi agli scenari utente, determinando flussi di lavoro confusi e incoerenti, duplicazione degli sforzi e una forte diminuzione della velocità di sviluppo. Per sfruttare gli strumenti e le architetture cloud, i team necessitano di un approccio coerente e automatizzato a CI/CD. Ciò consentirà agli sviluppatori di:

• Smetti di creare e mantenere script proprietari e utilizza invece un processo universale.

• Crea app e servizi più velocemente con un processo di distribuzione specifico e universale.

• Distribuisci più velocemente dopo aver apportato modifiche al codice.

• Abilita la distribuzione automatizzata per rilasci più rapidi, più frequenti e più affidabili.

• Esegui rollback e controlli per la conformità con i modelli di progettazione dichiarativi.

Gli sviluppatori adorano GitOps

Per tutti i motivi sopra indicati (e molti altri), le aziende necessitano di approcci gestiti e automatizzati a CI/CD e DevOps per riuscire a creare e mantenere applicazioni cloud. Ma se l’automazione è tutto ciò che serve, allora perché GitOps è migliore di altre strategie (come SlackOps, distribuzioni pianificate o semplici script)? La risposta è semplice: gli sviluppatori adorano GitOps.

Git: uno strumento per gestire tutto

Negli ultimi anni è diventato chiaro che GitOps è una delle strategie di automazione DevOps più apprezzate dagli sviluppatori e non è difficile capirne il motivo. Gli sviluppatori vivono in Git. Memorizzano modifiche temporanee in git, collaborano utilizzando git, rivedono il codice utilizzando git e mantengono una cronologia e una traccia di controllo di ogni modifica apportata da chiunque, anche in git. Poiché gli sviluppatori fanno così tanto affidamento su Git, sono disponibili strumenti speciali per lavorarci. Nei moderni sistemi di integrazione continua che vengono spesso utilizzati per supportare GitOps, come CircleCI , Github Actions , Gitlab CI e altri, le configurazioni che supportano le pipeline si trovano direttamente nel repository Git. Come il codice sorgente dell'applicazione, queste configurazioni sono controllate dalla versione e visibili a ogni sviluppatore che lavora al progetto. Non solo possono vedere in cosa consiste il processo della pipeline, ma possono anche apportarvi modifiche in modo rapido e semplice secondo necessità. Questa facilità di accesso per gli sviluppatori è fondamentale poiché scrivono test per le loro applicazioni e ne garantiscono la sicurezza e la stabilità.

Self-service completo

Le nuove funzionalità o le correzioni di bug non sono considerate complete finché non vengono rilasciate in produzione. Ciò significa che tutto ciò che impedisce l'esecuzione di modifiche al codice in produzione spreca tempo ed energia per lo sviluppatore. Supponiamo che uno sviluppatore debba attendere un po' di tempo affinché un altro team o persona completi alcune attività prima di poter chiudere la fase di lavoro. Ciò può creare attriti e conflitti nell’organizzazione. Facilitare la collaborazione tra i team è uno dei principali vantaggi di GitOps. Gli sviluppatori non solo hanno l'opportunità di lavorare con uno strumento familiare, ma possono anche rilasciare il proprio codice in produzione senza intervento manuale. Ciò significa che non aspettano che qualcun altro completi i loro compiti.

Lavoro continuo in tutto

Un altro grande vantaggio di GitOps è che tutti i processi sono sempre in esecuzione! Ogni modifica apportata attiva build e distribuzioni di test senza passaggi manuali. Poiché gli sviluppatori utilizzeranno git con o senza GitOps, la connessione al flusso di lavoro esistente per eseguire i processi DevOps è un'opzione ideale per l'automazione.

GitOps in pratica

Naturalmente, il coinvolgimento degli sviluppatori nel processo ha portato i team a fare un uso diffuso di strumenti facili da usare come Git. Ciò crea anche una coerenza naturale per le fasi di integrazione/distribuzione di CI/CD. Dopotutto, ci sono solo un certo numero di cose disponibili in un repository Git (ad esempio commit, richieste pull di apertura/chiusura, fusioni, ecc.), quindi l'aspetto della maggior parte delle implementazioni GitOps prevede una serie di passaggi tipici:

1. Pull richieste, test e ambienti di anteprima

Dopo che gli sviluppatori hanno dedicato del tempo a scrivere il codice per la loro nuova funzionalità, in genere eseguono il commit del codice in un nuovo ramo Git e inviano una richiesta Pull o Merge al ramo principale del repository. Gli sviluppatori lo fanno ogni giorno. La richiesta richiede ai responsabili tecnici di rivedere le modifiche al codice e approvarne l'unione nel codice dell'applicazione principale. Questa è una grande opportunità per DevOps di aggiungere ulteriori attività. Collegandosi agli eventi di apertura/chiusura generati da questo processo di richiesta pull utilizzando uno strumento di integrazione continua (CI), i team DevOps possono attivare l'esecuzione di test unitari, la creazione di ambienti di anteprima e l'esecuzione di test di integrazione su tali ambienti. Questi strumenti consentono agli ingegneri di stabilire rapidamente l'attendibilità delle modifiche al codice e consentono ai product manager di visualizzare le modifiche al codice attraverso un ambiente di anteprima pre-unione. Una fiducia più stretta significa una fusione più rapida. Meno e più spesso vengono immessi i dati, meno rollback complessi e confusi. Questa tecnica GitOps è fondamentale per team di sviluppo e produzione più rapidi e più sani.

2. Unisciti al master e distribuiscilo nello staging

Una volta che tutte le parti hanno esaminato le modifiche, il codice può essere unito al ramo principale del repository insieme alle modifiche apportate dal resto del team di sviluppo. Questo ramo principale viene spesso utilizzato come area di preparazione per il codice quasi pronto per la produzione. C'è ancora tempo per completare alcune attività operative come test e distribuzione. Sebbene in genere testiamo il codice per ogni richiesta pull prima di unirlo, è una buona idea eseguire nuovamente i test per assicurarsi che il codice funzioni con le altre modifiche apportate dal resto del team. Vale anche la pena distribuire tutte queste modifiche in un ambiente comune (chiamato "staging") che l'intero team può utilizzare per rivedere e testare le ultime modifiche prima che vengano rilasciate ai clienti.

3. Ridurre le versioni e distribuirle in produzione

Infine, dopo che manager e ingegneri hanno avuto il tempo di rivedere e testare le ultime modifiche al ramo upstream, i team sono pronti a rilasciare la versione e a distribuirla in produzione! Questa attività viene spesso eseguita da un release manager, un membro del team dedicato (o a rotazione) incaricato di eseguire gli script di distribuzione e monitorare il rilascio. Senza utilizzare GitOps, questo membro del team deve verificare dove sono gli script corretti, in quale ordine eseguirli e se tutte le librerie e i pacchetti corretti necessari per eseguire gli script sono installati sul proprio computer. Con GitOps, possiamo collegare questa distribuzione a un altro evento basato su Git: la creazione di una versione o di un tag. Tutto ciò che un release manager deve fare è creare una nuova “release”, spesso usando semver come nome. Le attività per creare e distribuire le modifiche al codice verranno eseguite automaticamente. Come la maggior parte delle attività eseguite da uno strumento CI, verranno configurate con la posizione degli script e l'ordine delle librerie e dei pacchetti necessari per eseguirli.

Strumenti GitOps

Uno strumento di integrazione continua robusto e intuitivo non è l'unica cosa necessaria per gestire processi GitOps come quelli descritti in questo articolo. Un sistema CI può attivare script basati su eventi git, ma sono comunque necessari strumenti potenti per eseguire tali script e renderli facili e sicuri da eseguire e mantenere. La distribuzione delle modifiche al codice (nota anche come distribuzione continua, CD) è uno dei passaggi più difficili da automatizzare. Ecco perché abbiamo selezionato diverse categorie di strumenti che possono aiutarti nel tuo percorso GitOps:

Containerizzazione con Docker

Docker ha portato lo sviluppo cloud in un ambiente distribuito completamente nuovo e ha aiutato gli sviluppatori a iniziare a considerare realisticamente le architetture di microservizi come un'opzione praticabile. Una delle cose che rende Docker così potente è la sua comodità per gli sviluppatori rispetto alle soluzioni di virtualizzazione della generazione precedente. Come per le configurazioni CI dichiarative presenti nei nostri repository, gli sviluppatori devono semplicemente scrivere e mantenere un Dockerfile nel loro repository per abilitare build automatizzate di macchine virtuali distribuite nei container. La containerizzazione è una tattica estremamente potente per i team cloud e dovrebbe essere uno strumento fondamentale nel tuo repertorio.

Infrastruttura come codice (IaC)

C'è molto da fare nella preparazione dell'infrastruttura e nella distribuzione di applicazioni che non sono archiviate in un Dockerfile. Per tutto il resto, esistono soluzioni Infrastructure-as-Code (IaC) come Terraform , Cloudformation e altre. Queste soluzioni consentono agli sviluppatori di descrivere altre parti dell'applicazione, come risorse Kubernetes, bilanciatori del carico, rete, sicurezza e altro, in modo dichiarativo. Proprio come le configurazioni CI e i Dockerfile descritti in precedenza, i modelli IaC possono essere controllati in base alla versione e condivisi tra tutti gli sviluppatori del tuo team.