Coffee break #120. Java operators &, && (AND) || (OR). Introduction to GitOps and DevOps for Developers

Java operators &, && (AND) || (OR)

Source: freeCodeCamp In the Java programming language, we use operators to perform operations on variables. Operators are divided into different categories: arithmetic operators, assignment operators, comparison operators, logical operators, and so on. In this article, we will talk about the bitwise AND operator ( & ), as well as the logical operators AND ( && ) and OR ( || ).

How to use the bitwise AND operator

The symbol & denotes the bitwise AND operator. It evaluates the binary value of given numbers. The binary result of these numbers will be returned to us in base 10. When the & operator begins its work, it will evaluate the value of the characters in both numbers, starting from the left. Let's look at an example to help understand this better:

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

How to explain this? The binary value of 10 is 1010. The binary value of 12 is 1100. Here's what we need to consider before we start the operation: 1 and 0 => 0 0 and 1 => 0 1 and 1 => 1 0 and 0 => 0 So let's do operation. The first symbol for 10 is 1, the first symbol for 12 is also 1, therefore: 1 and 1 = 1. Moving on to the second symbols - 0 for 10 and 1 for 12: 1 and 0 = 0. For the third symbols - 1 for 10 and 0 for 12: 1 and 0 = 0. For the fourth characters - 0 for 10 and 0 for 12: 0 and 0 = 0. Now let's combine all the returned characters. This gives us 1000. The binary value of 1000 in base 10 is 8, so our operation returned 8.

How to Use the Logical AND Operator

Note that we use Boolean operators to evaluate conditions. They return true or false depending on the given conditions. The && symbol represents the AND operator. It evaluates two statements/conditions and returns true only if both statements/conditions are true. This is what its syntax looks like:

statment1/condition1 && statemnt2/condition2

As you can see above, there are two statements/conditions separated by a statement. The operator evaluates the value of both statements/conditions and gives us the result - true or false . Here's an example:

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

The operation will return true because both conditions are true: 10 is greater than 2 and 8 is greater than 4. If either condition had incorrect logic, we would receive false . To better understand the && operator , you should know that both conditions must be true to evaluate to true . Here's another example that returns false :

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

Here 2 is not greater than 10, and 8 is greater than 4 - so we get false . This is because one of the conditions is incorrect.

• If both conditions are true => true

• If one of the two conditions is false => false

• If both conditions are false => false

How to use the Boolean OR operator

To denote the OR operator we use the symbol || . This operator returns false only if both conditions are false. That is, if both conditions are true, we will get true , and if one of both conditions is true, then we will also get true . Here's the syntax:

statment1/condition1 || statemnt2/condition2

Let's look at a few examples.

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

True is returned to us because one of the conditions is true.

• If both conditions are true => true

• If one of the conditions is true => true

• If both conditions are false => false

Conclusion

In this article, we learned how to use the bitwise & operator and the logical operators && and || in Java. . We also learned what value each operation returns depending on its conditions.

Introduction to GitOps and DevOps for Developers

Source: Hackernoon One of the main goals of DevOps is to help developers deploy a feature to production as quickly and securely as possible. This means creating tools and processes that do everything from providing private development environments to deploying and securing production workloads. At the same time, haste should not lead to critical failures. GitOps is a way to automate DevOps. More specifically, it is an automation tactic using the Git development tool. Since developers already commit code to a centralized Git repository (using something like GitHub, GitLab, or BitBucket), DevOps developers can plug in any of their work scripts to build, test, or deploy applications to run after every code change is made. This means that developers can work exclusively with Git, and everything that helps them get their code into production will be automated.

Why GitOps?

Previously, DevOps and CI/CD methods were a set of proprietary scripts and tools that performed everyday tasks: running tests, provisioning infrastructure, or deploying an application. However, the availability of new infrastructure tools such as Kubernetes, coupled with the rise of microservice architectures, requires developers to become more involved in CI/CD processes. This change created problems related to user scenarios, resulting in confusing and inconsistent workflows, duplication of effort, and a sharp decrease in development speed. To take advantage of cloud tools and architectures, teams need a consistent, automated approach to CI/CD. This will allow developers to:

• Stop creating and maintaining proprietary scripts and instead use a universal process.

• Build apps and services faster with a specified, universal deployment process.

• Deploy faster after making code changes.

• Enable automated deployment for faster, more frequent, and more reliable releases.

• Perform rollbacks and audits for compliance with declarative design patterns.

Developers love GitOps

For all the reasons stated above (and many more), companies need managed and automated approaches to CI/CD and DevOps to succeed in building and maintaining cloud applications. But if automation is all there is to it, then why is GitOps better than other strategies (like SlackOps, scheduled deployments, or simple scripts)? The answer is simple: developers love GitOps.

Git - one tool to manage it all

In recent years, it has become clear that GitOps is one of the most highly rated DevOps automation strategies among developers, and it's not hard to see why. Developers live in Git. They store temporary changes in git, collaborate using git, review code using git, and keep a history and audit trail of every change anyone has ever made, also in git. Because developers have come to rely so heavily on git, there are special tools available to work with it. In modern continuous integration systems that are most often used to support GitOps, such as CircleCI , Github Actions , Gitlab CI and others, the configurations that support pipelines are located directly in the Git repository. Like the application's source code, these configurations are version controlled and visible to every developer working on the project. Not only can they see what the pipeline process is, but they can also quickly and easily make changes to it as needed. This ease of access for developers is critical as they write tests for their applications and ensure their security and stability.

Full self-service

New features or bug fixes are not considered complete until they are released into production. This means that anything that prevents code changes from being made in production wastes developer time and energy. Suppose a developer has to wait some time for another team or person to complete some task before he can close his work step. This can create friction and conflict in the organization. Facilitating collaboration between teams is one of the main benefits of GitOps. Developers not only get the opportunity to work in a familiar tool, but they can also release their code into production without manual intervention. This means they don't wait for someone else to complete their tasks.

Continuous work in everything

Another big benefit of GitOps is that all processes are always running! Every change we make triggers test builds and deployments without any manual steps. Since developers will be using git with or without GitOps, connecting to their existing workflow to run DevOps processes is an ideal option for automation.

GitOps in practice

Naturally, the involvement of developers in the process has led to teams making widespread use of user-friendly tools such as Git. This also creates a natural consistency for the integration/deployment phases of CI/CD. After all, there are only so many things that are available in a Git repository (e.g. commits, open/close pull requests, merges, etc.), so the look and feel of most GitOps implementations involves a set of typical steps:

1. Pull requests, tests, and preview environments

After developers have spent time writing code for their new feature, they typically commit that code to a new Git branch and submit a Pull request or Merge request back to the repository's main branch. Developers do this every day. The prompt requires technical managers to review code changes and approve them to be merged into the main application code. This is a great opportunity for DevOps to add additional tasks. By connecting to the open/close events generated by this pull request process using a continuous integration (CI) tool, DevOps teams can trigger execution of unit tests, creation of preview environments, and execution of integration tests against those environments. This tooling allows engineers to quickly establish trust in code changes and allows product managers to see code changes through a pre-merge preview environment. Closer trust means faster fusion. The less and more often the data is entered, the fewer complex and confusing rollbacks. This GitOps technique is key to faster, healthier development and production teams.

2. Merge with master and deploy to staging

Once all parties have reviewed the changes, the code can be merged into the repository's master branch along with the changes made by the rest of the development team. This master branch is often used as a staging area for code that is almost ready for production. There is still time to complete some operational tasks such as tests and deployment. While we typically test the code for each pull request before merging it, it's a good idea to re-run the tests to make sure the code works with other changes made by the rest of the team. It's also worth deploying all of these changes to a common environment (called a “staging”) that the entire team can use to review and test the latest changes before they're released to customers.

3. Reduce releases and deploy to production

Finally, after managers and engineers have had time to review and test the latest changes to the upstream branch, the teams are ready to release the release and deploy it to production! This task is often performed by a release manager, a dedicated (or rotating) team member tasked with executing deployment scripts and monitoring the release. Without using GitOps, this team member must check where the correct scripts are, what order to run them in, and whether all the correct libraries and packages needed to run the scripts are installed on their machine. With GitOps, we can link this deployment to another Git-based event—the creation of a release or tag. All a release manager needs to do is create a new “release,” often using semver for the name. Tasks to build and deploy code changes will run automatically. Like most tasks performed by a CI tool, they will be configured with the location of the scripts and the order of the libraries and packages needed to run them.

GitOps Tools

A robust and intuitive continuous integration tool isn't the only thing needed to instrument GitOps processes like the ones described in this article. A CI system can trigger scripts based on git events, but you still need powerful tools to run those scripts and make them easy and safe to run and maintain. Deploying code changes (also known as continuous delivery, CD) is one of the most difficult steps to automate. That's why we've selected several categories of tools that can help you on your GitOps journey:

Containerization with Docker

Docker brought cloud development into an entirely new distributed environment and helped developers begin to realistically consider microservice architectures as a viable option. One of the things that makes Docker so powerful is how convenient it is for developers compared to previous generation virtualization solutions. As with the declarative CI configurations found in our repositories, developers simply need to write and maintain a Dockerfile in their repository to enable automated builds of deployed virtual machines in containers. Containerization is an extremely powerful tactic for cloud teams and should be a core tool in your repertoire.

Infrastructure as Code (IaC)

A lot goes into preparing infrastructure and deploying applications that are not stored in a Dockerfile. For everything else, there are infrastructure-as-code (IaC) solutions such as Terraform , Cloudformation and others. These solutions allow developers to describe other parts of the application, such as Kubernetes resources, load balancers, networking, security, and more, in a declarative way. Just like the CI configurations and Dockerfiles described earlier, IaC templates can be version controlled and shared across all developers on your team.