喝咖啡休息#120。Java 運算子 &、&& (AND) || （或）。開發人員的 GitOps 和 DevOps 簡介

Java 運算子 &、&& (AND) || （或）

來源：freeCodeCamp 在Java程式語言中，我們使用運算子對變數進行操作。運算子分為不同的類別：算術運算子、賦值運算子、比較運算子、邏輯運算子等。 在本文中，我們將討論位元 AND 運算子 ( & )，以及邏輯運算子 AND ( && ) 和 OR ( || )。

如何使用位元與運算符

符號&表示位元與運算子。它評估給定數字的二進制值。這些數字的二進位結果將以 10 為基數傳回給我們。當&運算子開始工作時，它將從左側開始計算兩個數字中字元的值。讓我們看一個例子來幫助更好地理解這一點：

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

這怎麼解釋呢？10 的二進位值為 1010。12 的二進位值為 1100。在開始運算之前，我們需要考慮以下內容： 1 and 0 => 0 0 and 1 => 0 1 and 1 => 1 0 and 0 = > 0 那麼我們來做一下操作吧。10 的第一個符號是1，12 的第一個符號也是1，因此：1 和1 = 1。繼續討論第二個符號- 10 為0，12 為1：1 和0 = 0。對於第三個符號- 1 代表 10，0 代表 12：1 和 0 = 0。對於第四個字元 - 0 代表 10，0 代表 12：0 和 0 = 0。現在讓我們組合所有返回的字元。這給了我們 1000。1000 以 10 為基數的二進位值為 8，所以我們的操作回傳 8。

如何使用邏輯 AND 運算符

請注意，我們使用布林運算符來評估條件。它們根據給定條件傳回true或false 。&&符號代表 AND 運算子。它評估兩個語句/條件，並且僅當兩個語句/條件都為 true 時才傳回true。它的語法如下：

statment1/condition1 && statemnt2/condition2

正如您在上面看到的，有兩個語句/條件，由一個語句分隔。此運算子評估兩個語句/條件的值並給出結果 - 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。這是因為其中一個條件不正確。

• 如果兩個條件都為 true => true

• 如果兩個條件之一為 false => false

• 如果兩個條件都為 false => false

如何使用布林或運算符

為了表示 OR 運算符，我們使用符號|| 。只有當兩個條件都為 false 時，此運算子才會傳回false。也就是說，如果兩個條件都為真，我們就會得到true，如果兩個條件之一都為真，那麼我們也會得到true。文法如下：

statment1/condition1 || statemnt2/condition2

讓我們來看幾個例子。

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

True 會回傳給我們，因為其中一個條件為 true。

• 如果兩個條件都為 true => true

• 如果條件之一為 true => true

• 如果兩個條件都為 false => false

結論

在本文中，我們學習如何在 Java 中使用位元&運算子以及邏輯運算子&&和|| 。。我們還了解了每個操作根據其條件傳回的值。

開發人員的 GitOps 和 DevOps 簡介

資料來源：Hackernoon DevOps 的主要目標之一是幫助開發人員盡可能快速、安全地將功能部署到生產中。這意味著創建可以執行從提供私有開發環境到部署和保護生產工作負載的所有操作的工具和流程。同時，倉促行事不應導致嚴重失敗。 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－一款管理一切的工具

近年來，很明顯 GitOps 是開發人員中評價最高的 DevOps 自動化策略之一，原因也不難理解。開發人員生活在 Git 中。他們在 git 中儲存臨時更改，使用 git 進行協作，使用 git 審查程式碼，並在 git 中保留任何人所做的每個更改的歷史記錄和審計追蹤。由於開發人員已經嚴重依賴 git，因此有一些特殊的工具可以使用它。在最常用於支援 GitOps 的現代持續整合系統中，例如CircleCI、Github Actions、Gitlab CI等，支援管道的配置直接位於 Git 儲存庫中。與應用程式的原始程式碼一樣，這些配置受到版本控制，並且對參與該專案的每個開發人員都是可見的。他們不僅可以看到管道流程是什麼，還可以根據需要快速輕鬆地對其進行更改。對於開發人員來說，這種存取的便利性至關重要，因為他們為應用程式編寫測試並確保其安全性和穩定性。

全程自助服務

新功能或錯誤修復在發佈到生產環境之前才被視為完成。這意味著任何阻止在生產中進行程式碼更改的行為都會浪費開發人員的時間和精力。假設開發人員必須等待其他團隊或個人完成某些任務一段時間才能關閉其工作步驟。這可能會在組織中產生摩擦和衝突。促進團隊之間的協作是 GitOps 的主要好處之一。開發人員不僅有機會使用熟悉的工具工作，還可以將程式碼發佈到生產環境中，而無需手動幹預。這意味著他們不會等待其他人完成任務。

凡事持續努力

GitOps 的另一個好處是所有進程始終運行！我們所做的每項變更都會觸發測試建置和部署，無需任何手動步驟。由於開發人員將在有或沒有 GitOps 的情況下使用 git，因此連接到現有工作流程來執行 DevOps 流程是自動化的理想選擇。

GitOps 實踐

當然，開發人員參與這個過程導致團隊廣泛使用 Git 等用戶友好的工具。這也為 CI/CD 的整合/部署階段創建了自然的一致性。畢竟，Git 儲存庫中可用的東西有限（例如提交、開啟/關閉拉取請求、合併等），因此大多數 GitOps 實現的外觀都涉及一組典型步驟：

1. 拉取請求、測試和預覽環境

開發人員花時間為新功能編寫程式碼後，他們通常會將程式碼提交到新的 Git 分支，並將 Pull 請求或合併請求提交回儲存庫的主分支。開發人員每天都這樣做。此提示要求技術經理審查程式碼變更並批准將其合併到主應用程式程式碼中。這是 DevOps 增加額外任務的絕佳機會。透過使用持續整合 (CI) 工具連接到此拉取請求流程產生的開啟/關閉事件，DevOps 團隊可以觸發單元測試的執行、預覽環境的建立以及針對這些環境執行整合測試。該工具允許工程師快速建立對程式碼變更的信任，並允許產品經理透過預合併預覽環境查看程式碼變更。更緊密的信任意味著更快的整合。輸入資料的次數越少、越頻繁，複雜和令人困惑的回滾就越少。這種 GitOps 技術是更快、更健康的開發和生產團隊的關鍵。

2. 與master合併並部署到staging

一旦所有各方都審查了更改，程式碼就可以與開發團隊其他成員所做的更改一起合併到儲存庫的主分支中。此主分支通常用作幾乎可以用於生產的程式碼的暫存區域。還有時間完成一些操作任務，例如測試和部署。雖然我們通常在合併每個拉取請求之前測試程式碼，但最好重新執行測試以確保程式碼與團隊其他成員所做的其他變更相容。將所有這些變更部署到一個公共環境（稱為「暫存」）也是值得的，整個團隊可以使用該環境在發布給客戶之前審查和測試最新的變更。

3. 減少版本並部署到生產中

最後，在經理和工程師有時間審查和測試上游分支的最新變更後，團隊準備好發布版本並將其部署到生產中！此任務通常由發布經理執行，發布經理是負責執行部署腳本和監視發布的專門（或輪調）團隊成員。如果不使用 GitOps，該團隊成員必須檢查正確的腳本在哪裡、運行它們的順序以及運行腳本所需的所有正確的庫和套件是否都安裝在其電腦上。借助 GitOps，我們可以將此部署連結到另一個基於 Git 的事件——建立版本或標籤。發布經理所需要做的就是創建一個新的“發布”，通常使用 semver 作為名稱。建置和部署程式碼變更的任務將自動執行。與 CI 工具執行的大多數任務一樣，它們將配置腳本的位置以及運行它們所需的庫和套件的順序。

GitOps 工具

強大且直覺的持續整合工具並不是像本文中描述的那樣檢測 GitOps 流程所需的唯一工具。CI 系統可以基於 git 事件觸發腳本，但您仍然需要強大的工具來執行這些腳本並使其易於安全地運行和維護。部署程式碼變更（也稱為持續交付，CD）是最困難的自動化步驟之一。這就是為什麼我們選擇了幾類可以幫助您完成 GitOps 之旅的工具：

使用 Docker 進行容器化

Docker 將雲端開發引入了全新的分散式環境，並幫助開發人員開始切實地將微服務架構視為可行的選擇。Docker 如此強大的原因之一是，與上一代虛擬化解決方案相比，它對開發人員來說非常方便。與我們儲存庫中的宣告式 CI 配置一樣，開發人員只需在其儲存庫中編寫和維護 Dockerfile，即可自動建置容器中已部署的虛擬機器。對於雲端團隊來說，容器化是一種極其強大的策略，應該成為您的核心工具。

基礎設施即代碼 (IaC)

準備基礎架構和部署未儲存在 Dockerfile 中的應用程式需要做很多工作。對於其他一切，還有基礎架構即程式碼 (IaC) 解決方案，例如Terraform、Cloudformation等。這些解決方案允許開發人員以聲明性方式描述應用程式的其他部分，例如 Kubernetes 資源、負載平衡器、網路、安全性等。就像前面描述的 CI 配置和 Dockerfile 一樣，IaC 模板可以進行版本控制並在團隊中的所有開發人員之間共用。