Pause café #120. Opérateurs Java &, && (AND) || (OU). Introduction à GitOps et DevOps pour les développeurs

Opérateurs Java &, && (AND) || (OU)

Source : freeCodeCamp Dans le langage de programmation Java, nous utilisons des opérateurs pour effectuer des opérations sur des variables. Les opérateurs sont divisés en différentes catégories : opérateurs arithmétiques, opérateurs d'affectation, opérateurs de comparaison, opérateurs logiques, etc. Dans cet article, nous parlerons de l'opérateur ET au niveau du bit ( & ), ainsi que des opérateurs logiques AND ( && ) et OR ( || ).

Comment utiliser l'opérateur ET au niveau du bit

Le symbole & désigne l'opérateur ET au niveau du bit. Il évalue la valeur binaire de nombres donnés. Le résultat binaire de ces nombres nous sera renvoyé en base 10. Lorsque l' opérateur & commencera son travail, il évaluera la valeur des caractères des deux nombres, en commençant par la gauche. Regardons un exemple pour mieux comprendre cela :

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

Comment expliquer cela ? La valeur binaire de 10 est 1010. La valeur binaire de 12 est 1100. Voici ce que nous devons considérer avant de commencer l'opération : 1 et 0 => 0 0 et 1 => 0 1 et 1 => 1 0 et 0 = > 0 Alors faisons l'opération. Le premier symbole pour 10 est 1, le premier symbole pour 12 est également 1, donc : 1 et 1 = 1. Passons aux deuxièmes symboles - 0 pour 10 et 1 pour 12 : 1 et 0 = 0. Pour les troisièmes symboles - 1 pour 10 et 0 pour 12 : 1 et 0 = 0. Pour les quatrièmes caractères - 0 pour 10 et 0 pour 12 : 0 et 0 = 0. Combinons maintenant tous les caractères renvoyés. Cela nous donne 1 000. La valeur binaire de 1 000 en base 10 est 8, donc notre opération a renvoyé 8.

Comment utiliser l'opérateur logique AND

Notez que nous utilisons des opérateurs booléens pour évaluer les conditions. Ils renvoient vrai ou faux selon les conditions données. Le symbole && représente l'opérateur AND. Il évalue deux instructions/conditions et renvoie vrai uniquement si les deux instructions/conditions sont vraies. Voici à quoi ressemble sa syntaxe :

statment1/condition1 && statemnt2/condition2

Comme vous pouvez le voir ci-dessus, il existe deux instructions/conditions séparées par une instruction. L'opérateur évalue la valeur des deux instructions/conditions et nous donne le résultat - true ou false . Voici un exemple :

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

L'opération retournera true car les deux conditions sont vraies : 10 est supérieur à 2 et 8 est supérieur à 4. Si l'une ou l'autre des conditions avait une logique incorrecte, nous recevrions false . Pour mieux comprendre l' opérateur && , vous devez savoir que les deux conditions doivent être vraies pour être évaluées à true . Voici un autre exemple qui renvoie false :

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

Ici, 2 n'est pas supérieur à 10 et 8 est supérieur à 4 - nous obtenons donc false . C'est parce qu'une des conditions est incorrecte.

• Si les deux conditions sont vraies => vrai

• Si une des deux conditions est fausse => faux

• Si les deux conditions sont fausses => faux

Comment utiliser l'opérateur booléen OU

Pour désigner l'opérateur OR, nous utilisons le symbole || . Cet opérateur renvoie false uniquement si les deux conditions sont fausses. Autrement dit, si les deux conditions sont vraies, nous obtiendrons vrai , et si l'une des deux conditions est vraie, alors nous obtiendrons également vrai . Voici la syntaxe :

statment1/condition1 || statemnt2/condition2

Regardons quelques exemples.

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

True nous est renvoyé car l'une des conditions est vraie.

• Si les deux conditions sont vraies => vrai

• Si une des conditions est vraie => vrai

• Si les deux conditions sont fausses => faux

Conclusion

Dans cet article, nous avons appris à utiliser l'opérateur bit à bit & et les opérateurs logiques && et || en Java. . Nous avons également appris quelle valeur renvoie chaque opération en fonction de ses conditions.

Introduction à GitOps et DevOps pour les développeurs

Source : Hackernoon L'un des principaux objectifs de DevOps est d'aider les développeurs à déployer une fonctionnalité en production aussi rapidement et en toute sécurité que possible. Cela signifie créer des outils et des processus qui font tout, depuis la fourniture d'environnements de développement privés jusqu'au déploiement et à la sécurisation des charges de travail de production. Dans le même temps, la précipitation ne doit pas conduire à des échecs critiques. GitOps est un moyen d'automatiser DevOps. Plus précisément, il s'agit d'une tactique d'automatisation utilisant l'outil de développement Git. Étant donné que les développeurs valident déjà le code dans un référentiel Git centralisé (en utilisant quelque chose comme GitHub, GitLab ou BitBucket), les développeurs DevOps peuvent intégrer n'importe lequel de leurs scripts de travail pour créer, tester ou déployer des applications à exécuter après chaque modification de code. Cela signifie que les développeurs peuvent travailler exclusivement avec Git et que tout ce qui les aide à mettre leur code en production sera automatisé.

Pourquoi GitOps ?

Auparavant, les méthodes DevOps et CI/CD étaient un ensemble de scripts et d'outils propriétaires qui effectuaient des tâches quotidiennes : exécuter des tests, provisionner une infrastructure ou déployer une application. Cependant, la disponibilité de nouveaux outils d'infrastructure tels que Kubernetes, associée à la montée en puissance des architectures de microservices, oblige les développeurs à s'impliquer davantage dans les processus CI/CD. Ce changement a créé des problèmes liés aux scénarios utilisateur, entraînant des flux de travail confus et incohérents, une duplication des efforts et une forte diminution de la vitesse de développement. Pour tirer parti des outils et des architectures cloud, les équipes ont besoin d'une approche cohérente et automatisée du CI/CD. Cela permettra aux développeurs de :

• Arrêtez de créer et de maintenir des scripts propriétaires et utilisez plutôt un processus universel.

• Créez des applications et des services plus rapidement grâce à un processus de déploiement spécifié et universel.

• Déployez plus rapidement après avoir modifié le code.

• Activez un déploiement automatisé pour des versions plus rapides, plus fréquentes et plus fiables.

• Effectuez des restaurations et des audits pour vérifier la conformité aux modèles de conception déclaratifs.

Les développeurs adorent GitOps

Pour toutes les raisons évoquées ci-dessus (et bien d’autres), les entreprises ont besoin d’approches gérées et automatisées du CI/CD et du DevOps pour réussir à créer et maintenir des applications cloud. Mais si l’automatisation est tout ce qu’il y a à faire, alors pourquoi GitOps est-il meilleur que d’autres stratégies (comme SlackOps, les déploiements planifiés ou les scripts simples) ? La réponse est simple : les développeurs adorent GitOps.

Git - un outil pour tout gérer

Ces dernières années, il est devenu clair que GitOps est l'une des stratégies d'automatisation DevOps les plus appréciées par les développeurs, et il n'est pas difficile de comprendre pourquoi. Les développeurs vivent dans Git. Ils stockent les modifications temporaires dans git, collaborent à l'aide de git, révisent le code à l'aide de git et conservent un historique et une piste d'audit de chaque modification apportée par quelqu'un, également dans git. Étant donné que les développeurs s'appuient désormais énormément sur git, des outils spéciaux sont disponibles pour travailler avec lui. Dans les systèmes d'intégration continue modernes qui sont le plus souvent utilisés pour prendre en charge GitOps, tels que CircleCI , Github Actions , Gitlab CI et autres, les configurations prenant en charge les pipelines se trouvent directement dans le référentiel Git. Comme le code source de l'application, ces configurations sont contrôlées en version et visibles par tous les développeurs travaillant sur le projet. Non seulement ils peuvent voir en quoi consiste le processus de pipeline, mais ils peuvent également y apporter rapidement et facilement les modifications nécessaires. Cette facilité d'accès pour les développeurs est essentielle lorsqu'ils écrivent des tests pour leurs applications et garantissent leur sécurité et leur stabilité.

Libre-service complet

Les nouvelles fonctionnalités ou corrections de bogues ne sont pas considérées comme terminées tant qu’elles ne sont pas mises en production. Cela signifie que tout ce qui empêche les modifications du code en production fait perdre du temps et de l’énergie aux développeurs. Supposons qu'un développeur doive attendre un certain temps qu'une autre équipe ou une autre personne termine une tâche avant de pouvoir clôturer son étape de travail. Cela peut créer des frictions et des conflits au sein de l’organisation. Faciliter la collaboration entre les équipes est l'un des principaux avantages de GitOps. Les développeurs ont non seulement la possibilité de travailler avec un outil familier, mais ils peuvent également publier leur code en production sans intervention manuelle. Cela signifie qu'ils n'attendent pas que quelqu'un d'autre accomplisse leurs tâches.

Travail continu dans tout

Un autre grand avantage de GitOps est que tous les processus sont toujours en cours d’exécution ! Chaque modification que nous apportons déclenche des versions de test et des déploiements sans aucune étape manuelle. Étant donné que les développeurs utiliseront git avec ou sans GitOps, la connexion à leur flux de travail existant pour exécuter des processus DevOps est une option idéale pour l'automatisation.

GitOps en pratique

Naturellement, l’implication des développeurs dans le processus a conduit les équipes à généraliser l’utilisation d’outils conviviaux tels que Git. Cela crée également une cohérence naturelle pour les phases d’intégration/déploiement de CI/CD. Après tout, il n'y a qu'un nombre limité de choses disponibles dans un référentiel Git (par exemple, les validations, les demandes d'extraction d'ouverture/fermeture, les fusions, etc.), de sorte que l'apparence de la plupart des implémentations GitOps implique un ensemble d'étapes typiques :

1. Demandes d'extraction, tests et environnements de prévisualisation

Une fois que les développeurs ont passé du temps à écrire du code pour leur nouvelle fonctionnalité, ils valident généralement ce code dans une nouvelle branche Git et soumettent une demande Pull ou une demande de fusion à la branche principale du référentiel. Les développeurs le font tous les jours. L'invite demande aux responsables techniques d'examiner les modifications du code et d'approuver leur fusion dans le code de l'application principale. C'est une excellente opportunité pour DevOps d'ajouter des tâches supplémentaires. En se connectant aux événements d'ouverture/fermeture générés par ce processus de pull request à l'aide d'un outil d'intégration continue (CI), les équipes DevOps peuvent déclencher l'exécution de tests unitaires, la création d'environnements de prévisualisation et l'exécution de tests d'intégration sur ces environnements. Cet outil permet aux ingénieurs d'établir rapidement la confiance dans les modifications du code et permet aux chefs de produit de voir les modifications du code via un environnement de prévisualisation avant la fusion. Une confiance plus étroite signifie une fusion plus rapide. Moins les données sont saisies souvent, moins les restaurations sont complexes et déroutantes. Cette technique GitOps est essentielle pour des équipes de développement et de production plus rapides et plus saines.

2. Fusionner avec le maître et déployer sur la scène

Une fois que toutes les parties ont examiné les modifications, le code peut être fusionné dans la branche principale du référentiel avec les modifications apportées par le reste de l'équipe de développement. Cette branche principale est souvent utilisée comme zone de préparation pour le code presque prêt pour la production. Il est encore temps de réaliser certaines tâches opérationnelles telles que les tests et le déploiement. Bien que nous testions généralement le code de chaque pull request avant de le fusionner, c'est une bonne idée de réexécuter les tests pour nous assurer que le code fonctionne avec les autres modifications apportées par le reste de l'équipe. Il vaut également la peine de déployer toutes ces modifications dans un environnement commun (appelé « stade ») que toute l'équipe peut utiliser pour examiner et tester les dernières modifications avant qu'elles ne soient publiées auprès des clients.

3. Réduisez les versions et déployez en production

Enfin, après que managers et ingénieurs ont eu le temps d'examiner et de tester les dernières modifications apportées à la branche amont, les équipes sont prêtes à publier la release et à la déployer en production ! Cette tâche est souvent effectuée par un gestionnaire de versions, un membre de l'équipe dédié (ou en rotation) chargé d'exécuter les scripts de déploiement et de surveiller la version. Sans utiliser GitOps, ce membre de l'équipe doit vérifier où se trouvent les bons scripts, dans quel ordre les exécuter et si toutes les bibliothèques et packages appropriés nécessaires à l'exécution des scripts sont installés sur leur machine. Avec GitOps, nous pouvons lier ce déploiement à un autre événement basé sur Git : la création d'une version ou d'une balise. Tout ce qu'un gestionnaire de versions doit faire est de créer une nouvelle « version », en utilisant souvent semver pour le nom. Les tâches de création et de déploiement des modifications de code s'exécuteront automatiquement. Comme la plupart des tâches effectuées par un outil CI, elles seront configurées avec l'emplacement des scripts et l'ordre des bibliothèques et packages nécessaires à leur exécution.

Outils GitOps

Un outil d'intégration continue robuste et intuitif n'est pas la seule chose nécessaire pour instrumenter les processus GitOps comme ceux décrits dans cet article. Un système CI peut déclencher des scripts basés sur des événements git, mais vous avez toujours besoin d'outils puissants pour exécuter ces scripts et les rendre faciles et sûrs à exécuter et à maintenir. Le déploiement des modifications de code (également appelé livraison continue, CD) est l'une des étapes les plus difficiles à automatiser. C'est pourquoi nous avons sélectionné plusieurs catégories d'outils qui peuvent vous aider dans votre parcours GitOps :

Conteneurisation avec Docker

Docker a introduit le développement cloud dans un tout nouvel environnement distribué et a aidé les développeurs à commencer à considérer de manière réaliste les architectures de microservices comme une option viable. L’une des choses qui rend Docker si puissant est sa commodité pour les développeurs par rapport aux solutions de virtualisation de la génération précédente. Comme pour les configurations déclaratives CI trouvées dans nos référentiels, les développeurs doivent simplement écrire et maintenir un Dockerfile dans leur référentiel pour permettre la construction automatisée de machines virtuelles déployées dans des conteneurs. La conteneurisation est une tactique extrêmement puissante pour les équipes cloud et devrait constituer un outil essentiel de votre répertoire.

Infrastructure en tant que code (IaC)

Beaucoup de choses sont nécessaires pour préparer l'infrastructure et déployer des applications qui ne sont pas stockées dans un Dockerfile. Pour tout le reste, il existe des solutions d'infrastructure en tant que code (IaC) telles que Terraform , Cloudformation et autres. Ces solutions permettent aux développeurs de décrire d'autres parties de l'application, telles que les ressources Kubernetes, les équilibreurs de charge, la mise en réseau, la sécurité, etc., de manière déclarative. Tout comme les configurations CI et les Dockerfiles décrits précédemment, les modèles IaC peuvent être contrôlés en version et partagés entre tous les développeurs de votre équipe.