コーヒーブレイク#120。Java 演算子 &、&& (AND) || （または）。開発者のための GitOps と DevOps の概要

Java 演算子 &、&& (AND) || （または）

出典: freeCodeCamp Java プログラミング言語では、変数に対する演算を実行するために演算子を使用します。演算子は、算術演算子、代入演算子、比較演算子、論理演算子などのさまざまなカテゴリに分類されます。 この記事では、ビット単位の AND 演算子 ( & )、論理演算子 AND ( && ) および OR ( || ) について説明します。

ビットごとの AND 演算子の使用方法

記号& はビット単位の AND 演算子を示します。指定された数値のバイナリ値を評価します。これらの数値のバイナリ結果は、基数 10 で返されます。&演算子が作業を開始すると、両方の数値の文字の値が左から順に評価されます。これをよりよく理解するために例を見てみましょう。

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

これをどう説明すればいいでしょうか？10 のバイナリ値は 1010 です。12 のバイナリ値は 1100 です。操作を開始する前に考慮する必要があるのは次のとおりです: 1 と 0 => 0 0 と 1 => 0 1 と 1 => 1 0 と 0 = > 0 それでは、操作をしてみましょう。10 の最初のシンボルは 1、12 の最初のシンボルも 1、つまり 1 と 1 = 1 です。2 番目のシンボルに進みます - 10 は 0、12 は 1: 1 と 0 = 0。3 番目のシンボルの場合- 10 の場合は 1、12 の場合は 0: 1 および 0 = 0。 4 番目の文字の場合 - 10 の場合は 0、12 の場合は 0: 0 および 0 = 0。 次に、返されたすべての文字を結合しましょう。これにより 1000 が得られます。基数 10 の 1000 のバイナリ値は 8 であるため、この操作では 8 が返されました。

論理 AND 演算子の使用方法

条件の評価にはブール演算子を使用することに注意してください。与えられた条件に応じてtrueまたはfalseを返します。&&記号はAND 演算子を表します。2 つのステートメント/条件を評価し、両方のステートメント/条件が true の場合にのみtrueを返します。その構文は次のようになります。

statment1/condition1 && statemnt2/condition2

上でわかるように、ステートメントで区切られた 2 つのステートメント/条件があります。演算子は両方のステートメント/条件の値を評価し、結果 ( trueまたはfalse )を返します。以下に例を示します。

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

両方の条件が true であるため、操作はtrueを返します。10 は 2 より大きく、8 は 4 より大きいです。どちらかの条件のロジックが正しくない場合は、 falseを受け取ります。&&演算子をより深く理解するには、 trueと評価するには両方の条件が true でなければならないことを知っておく必要があります。falseを返す別の例を次に示します。

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

ここで 2 は 10 より大きくなく、8 は 4 より大きいため、falseが返されます。これは、条件の 1 つが間違っているためです。

• 両方の条件が true の場合 => true

• 2 つの条件のいずれかが false => falseの場合

• 両方の条件が false の場合 => false

ブール OR 演算子の使用方法

OR 演算子を示すには、記号||を使用します。。この演算子は、両方の条件が false の場合にのみfalseを返します。つまり、両方の条件が true の場合はtrueが得られ、両方の条件のいずれかが true の場合もtrueが得られます。構文は次のとおりです。

statment1/condition1 || statemnt2/condition2

いくつかの例を見てみましょう。

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

条件の 1 つが true であるため、True が返されます。

• 両方の条件が true の場合 => true

• いずれかの条件が true => trueの場合

• 両方の条件が false の場合 => false

結論

この記事では、 Java でビット単位の&演算子と論理演算子&&および||を使用する方法を学びました。。また、各操作が条件に応じてどのような値を返すかを学びました。

開発者のための GitOps と DevOps の概要

出典: Hackernoon DevOps の主な目標の 1 つは、開発者が機能をできるだけ迅速かつ安全に運用環境にデプロイできるようにすることです。これは、プライベート開発環境の提供から実稼働ワークロードのデプロイと保護まで、あらゆることを行うツールとプロセスを作成することを意味します。同時に、急いで重大な失敗を招いてはいけません。 GitOps は DevOps を自動化する方法です。具体的には、Git 開発ツールを使用した自動化戦略です。開発者はすでに集中型 Git リポジトリ (GitHub、GitLab、BitBucket などを使用) にコードをコミットしているため、DevOps 開発者は作業スクリプトをプラグインして、コードが変更されるたびに実行するアプリケーションを構築、テスト、またはデプロイできます。これは、開発者が Git のみを使用して作業できるようになり、コードを本番環境に導入するのに役立つすべてが自動化されることを意味します。

なぜ GitOps なのか?

以前は、DevOps および CI/CD メソッドは、テストの実行、インフラストラクチャのプロビジョニング、アプリケーションのデプロイなどの日常的なタスクを実行する独自のスクリプトとツールのセットでした。ただし、Kubernetes などの新しいインフラストラクチャ ツールが利用可能になったことと、マイクロサービス アーキテクチャの台頭により、開発者は CI/CD プロセスにさらに関与する必要があります。この変更により、ユーザー シナリオに関連する問題が発生し、混乱と一貫性のないワークフロー、作業の重複、開発速度の急激な低下が生じました。クラウド ツールとアーキテクチャを活用するには、チームは CI/CD に対する一貫した自動化されたアプローチを必要とします。これにより、開発者は次のことが可能になります。

• 独自のスクリプトの作成と保守をやめ、代わりに汎用プロセスを使用してください。

• 指定されたユニバーサル展開プロセスを使用して、アプリとサービスをより迅速に構築します。

• コード変更後のデプロイを迅速化します。

• 自動展開を有効にして、より迅速、より頻繁、より信頼性の高いリリースを実現します。

• 宣言的な設計パターンに準拠しているかどうかのロールバックと監査を実行します。

開発者は GitOps を愛しています

上記のすべての理由 (およびその他の理由) により、企業がクラウド アプリケーションの構築と保守を成功させるには、CI/CD および DevOps に対する管理された自動化されたアプローチが必要です。しかし、自動化だけがすべてであるなら、なぜ GitOps が他の戦略 (SlackOps、スケジュールされたデプロイメント、単純なスクリプトなど) よりも優れているのでしょうか? 答えは簡単です。開発者は GitOps を愛しているからです。

Git - すべてを管理する 1 つのツール

近年、GitOps が開発者の間で最も高く評価されている DevOps 自動化戦略の 1 つであることが明らかになり、その理由を理解するのは難しくありません。開発者は Git に住んでいます。これらは、一時的な変更を git に保存し、git を使用して共同作業し、git を使用してコードをレビューし、これまでに行われたすべての変更の履歴と監査証跡を git に保存します。開発者は git に大きく依存するようになっているため、git を操作するための特別なツールが用意されています。CircleCI、Github Actions、Gitlab CIなど、GitOps をサポートするために最もよく使用される最新の継続的インテグレーション システムでは、パイプラインをサポートする構成は Git リポジトリに直接配置されます。アプリケーションのソース コードと同様に、これらの構成はバージョン管理されており、プロジェクトに取り組んでいるすべての開発者に表示されます。パイプライン プロセスが何であるかを確認できるだけでなく、必要に応じて迅速かつ簡単に変更を加えることができます。開発者にとって、アプリケーションのテストを作成し、セキュリティと安定性を確保する場合、このアクセスのしやすさは非常に重要です。

フルセルフサービス

新機能やバグ修正は、運用環境にリリースされるまで完了したとはみなされません。これは、本番環境でのコード変更を妨げるものは開発者の時間とエネルギーを無駄にすることを意味します。開発者が自分の作業ステップを閉じる前に、別のチームまたは人が何らかのタスクを完了するまでしばらく待たなければならないとします。これにより、組織内に摩擦や対立が生じる可能性があります。チーム間のコラボレーションを促進することは、GitOps の主な利点の 1 つです。開発者は、使い慣れたツールで作業する機会を得るだけでなく、手動介入なしでコードを実稼働環境にリリースすることもできます。これは、他の人が自分のタスクを完了するのを待たないことを意味します。

すべてにおいて継続的な取り組み

GitOps のもう 1 つの大きな利点は、すべてのプロセスが常に実行されていることです。変更を加えるたびに、手動の手順を行わずにテストのビルドとデプロイメントがトリガーされます。開発者は GitOps の有無にかかわらず git を使用するため、既存のワークフローに接続して DevOps プロセスを実行することは自動化の理想的なオプションです。

GitOps の実践

当然のことながら、開発者がプロ​​セスに関与することで、チームは Git などの使いやすいツールを広く使用するようになりました。これにより、CI/CD の統合/展開フェーズの自然な一貫性も生まれます。結局のところ、Git リポジトリで利用できるものは限られているため (コミット、プル リクエストのオープン/クローズ、マージなど)、ほとんどの GitOps 実装のルック アンド フィールには、一連の一般的な手順が含まれます。

1. プル リクエスト、テスト、プレビュー環境

開発者は、時間をかけて新機能のコードを作成した後、通常、そのコードを新しい Git ブランチにコミットし、プル リクエストまたはマージリクエストをリポジトリのメイン ブランチに送信します。開発者はこれを毎日行っています。このプロンプトでは、技術マネージャーがコードの変更をレビューし、メインのアプリケーション コードにマージすることを承認する必要があります。これは、DevOps にとってタスクを追加する絶好の機会です。継続的インテグレーション (CI) ツールを使用して、このプル リクエスト プロセスによって生成されたオープン/クローズ イベントに接続することで、DevOps チームは単体テストの実行、プレビュー環境の作成、およびそれらの環境に対する統合テストの実行をトリガーできます。このツールを使用すると、エンジニアはコードの変更に対する信頼を迅速に確立でき、製品マネージャーはマージ前のプレビュー環境を通じてコードの変更を確認できるようになります。より緊密な信頼は、より迅速な融合を意味します。データを入力する頻度が減れば増えるほど、複雑で混乱を招くロールバックが少なくなります。この GitOps テクニックは、開発チームと運用チームをより迅速かつ健全にするための鍵となります。

2. マスターとマージし、ステージングにデプロイします

すべての関係者が変更を確認したら、コードを残りの開発チームが加えた変更とともにリポジトリのマスター ブランチにマージできます。このマスター ブランチは、本番環境の準備がほぼ整ったコードのステージング領域としてよく使用されます。テストや展開など、いくつかの運用タスクを完了するにはまだ時間があります。通常、プル リクエストごとにコードをマージする前にテストしますが、テストを再実行して、チームの他のメンバーが加えた他の変更でもコードが機能することを確認することをお勧めします。また、これらすべての変更を、顧客にリリースする前にチーム全体が最新の変更をレビューおよびテストするために使用できる共通の環境 (「ステージング」と呼ばれる) にデプロイすることも価値があります。

3. リリースを減らして実稼働環境にデプロイする

最後に、マネージャーとエンジニアが上流ブランチへの最新の変更を確認してテストする時間をとった後、チームはリリースをリリースして運用環境にデプロイする準備が整います。このタスクは多くの場合、リリース マネージャー、つまり展開スクリプトの実行とリリースの監視を担当する専任 (またはローテーション) チーム メンバーによって実行されます。GitOps を使用せずに、このチーム メンバーは、正しいスクリプトがどこにあるか、スクリプトを実行する順序、スクリプトの実行に必要なすべての正しいライブラリとパッケージがマシンにインストールされているかどうかを確認する必要があります。GitOps を使用すると、このデプロイメントを別の Git ベースのイベント (リリースまたはタグの作成) にリンクできます。リリース マネージャーが行う必要があるのは、新しい「リリース」を作成することだけです (多くの場合、名前に semver を使用します)。コード変更をビルドしてデプロイするタスクは自動的に実行されます。CI ツールによって実行されるほとんどのタスクと同様に、これらのタスクは、スクリプトの場所と、それらの実行に必要なライブラリとパッケージの順序で構成されます。

GitOps ツール

この記事で説明したような GitOps プロセスを実装するために必要なのは、堅牢で直感的な継続的インテグレーション ツールだけではありません。CI システムは git イベントに基づいてスクリプトをトリガーできますが、これらのスクリプトを実行し、簡単かつ安全に実行および保守できるようにするための強力なツールが必要です。コード変更のデプロイ (継続的デリバリー、CD とも呼ばれます) は、自動化するのが最も難しいステップの 1 つです。そのため、GitOps の取り組みに役立ついくつかのカテゴリのツールを選択しました。

Dockerによるコンテナ化

Docker はクラウド開発を全く新しい分散環境にもたらし、開発者がマイクロサービス アーキテクチャを実行可能な選択肢として現実的に検討し始めるのに役立ちました。Docker が非常に強力である理由の 1 つは、前世代の仮想化ソリューションと比較して、開発者にとって Docker がいかに便利であるかです。リポジトリにある宣言型 CI 構成と同様に、開発者はリポジトリに Dockerfile を作成して維持するだけで、コンテナ内にデプロイされた仮想マシンの自動ビルドを有効にできます。コンテナ化はクラウド チームにとって非常に強力な戦術であり、レパートリーの中核ツールとなる必要があります。

コードとしてのインフラストラクチャ (IaC)

インフラストラクチャの準備と、Dockerfile に保存されていないアプリケーションのデプロイには多くの労力がかかります。その他すべてについては、 Terraform、Cloudformationなどのコードとしてのインフラストラクチャ (IaC) ソリューションがあります。これらのソリューションを使用すると、開発者は、Kubernetes リソース、ロード バランサー、ネットワーク、セキュリティなど、アプリケーションの他の部分を宣言的な方法で記述することができます。前に説明した CI 構成や Dockerfile と同様に、IaC テンプレートはバージョン管理でき、チーム内のすべての開発者間で共有できます。