喝咖啡休息#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 模板可以进行版本控制并在团队中的所有开发人员之间共享。