JavaRush /Java блог /Random /Кофе-брейк #120. Java операторы &, && (AND) |...

Кофе-брейк #120. Java операторы &, && (AND) || (OR). Введение в GitOps и DevOps для разработчиков

Статья из группы Random

Java операторы &, && (AND) || (OR)

Источник: freeCodeCamp В языке программирования Java мы используем операторы для выполнения операций над переменными. Операторы делятся на разные категории: арифметические, операторы присваивания, операторы сравнения, логические операторы и так далее. Кофе-брейк #120. Java операторы – &, && (AND) || (OR). Введение в GitOps и DevOps для разработчиков - 1В этой статье мы поговорим о побитовом операторе AND (&), а также о логических операторах 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. Переходим ко вторым символам — 0 для 10 и 1 для 12: 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 только в том случае, если оба утверждения/условия верны. Вот как выглядит его синтаксис:

statment1/condition1 && statemnt2/condition2
Как вы можете видеть выше, есть два оператора/условия, разделенные оператором. Оператор оценивает значение обоих утверждений/условий и выдает нам результат — true или false. Вот пример:

System.out.println((10 > 2) && (8 > 4));
//true
Операция вернет true, потому что оба условия верны: 10 больше 2 и 8 больше 4. Если бы хотя бы одно из условий имело неверную логику, мы получили бы false. Чтобы лучше понять оператор &&, вы должны знать, что оба условия должны быть истинными, чтобы получить значение true. Вот еще один пример, который возвращает false:

System.out.println((2 > 10) && (8 > 4));
// false
Здесь 2 не больше 10, а 8 больше 4 — так что мы получаем false. Это потому что одно из условий неверно.
  • Если оба условия верны => true

  • Если одно из двух условий ложно => false

  • Если оба условия ложны => false

Как использовать логический оператор OR

Для обозначения оператора OR мы используем символ ||. Этот оператор возвращает значение false, только если оба условия ложны. То есть если оба условия истинны, мы получим true, и если одно из обоих условий истинно, то мы также получим true. Вот синтаксис:

statment1/condition1 || statemnt2/condition2
Давайте рассмотрим несколько примеров.

System.out.println((6 < 1) || (4 > 2));  
// true
Нам возвращается true, потому что одно из условий истинно.
  • Если оба условия верны => true

  • Если одно из условий верно => true

  • Если оба условия ложны => false

Заключение

В этой статье мы узнали, как использовать в Java побитовый оператор & и логические операторы && и ||. Мы также узнали, какое значение возвращает каждая операция в зависимости от ее условий.

Введение в GitOps и DevOps для разработчиков

Источник: Hackernoon Одна из основных целей DevOps — помощь разработчикам в максимально быстром и безопасном развертывании функции в рабочей среде. Это означает создание инструментов и процессов, которые делают все: от предоставления частных сред разработки до развертывания и защиты производственных рабочих нагрузок. При этом поспешность не должна привести к критическим сбоям. Кофе-брейк #120. Java операторы – &, && (AND) || (OR). Введение в GitOps и DevOps для разработчиков - 2GitOps — это способ автоматизации 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 заключается в том, что все процессы постоянно выполняются! Каждое вносимое нами изменение запускает тестовые сборки и развертывания без каких-либо действий, выполняемых вручную. Поскольку разработчики будут использовать git с GitOps или без него, подключение к их существующему рабочему процессу для запуска процессов DevOps — идеальный вариант для автоматизации.

GitOps на практике

Естественно, вовлечение разработчиков в процесс привело к тому, что команды стали широко использовать удобные инструменты, такие как Git. Это также создает естественную согласованность для этапов интеграции/развертывания CI/CD. В конце концов, в репозитории Git доступно ограниченное количество приемов работы (например, коммиты, открытие/закрытие запросов на включение, слияние и т. д.), поэтому внешний вид большинства реализаций GitOps включает набор типичных этапов:

1. Запросы на включение (Pull requests), тесты и среды предварительного просмотра

После того, как разработчики потратили время на написание кода для своей новой функции, они обычно фиксируют этот код в новой ветке Git и отправляют запрос на извлечение (Pull request) или запрос на слияние (Merge request) обратно в основную ветку репозитория. Разработчики делают это ежедневно. Появление запроса требует от технических менеджеров просмотреть изменения кода и утвердить их для объединения с основным кодом приложения. Это прекрасная возможность для DevOps подключить дополнительные задачи. Подключаясь к событиям открытия/закрытия, созданным этим процессом запроса на включение, с помощью инструмента непрерывной интеграции (CI), команды DevOps могут инициировать выполнение модульных тестов, создание сред предварительного просмотра и выполнение интеграционных тестов для этих сред. Такой инструментарий позволяет инженерам быстро установить доверие к изменениям кода, а менеджерам по продуктам — видеть изменения кода через среду предварительного просмотра перед слиянием. Более тесное доверие означает более быстрое слияние. Чем меньше и чаще вводятся данные — тем меньше сложных и запутанных откатов. Этот прием GitOps является ключевым фактором для более быстрой и здоровой работы команд разработчиков и продакшн-групп.

2. Слияние с мастером и развертывание на промежуточной стадии

После того, как все стороны рассмотрят изменения, код может быть объединен с основной веткой репозитория вместе с изменениями, внесенными остальной командой разработчиков. Эта основная ветвь часто используется в качестве промежуточной площадки для кода, который почти готов к запуску в производство. Здесь еще есть время для выполнения некоторых операционных задач, таких как тесты и развертывание. Хотя мы обычно тестируем код для каждого запроса на включение перед его слиянием, рекомендуется повторно запустить тесты, чтобы убедиться, что код работает с другими изменениями, внесенными остальными участниками команды. Также стоит развернуть все эти изменения в общей среде (так называемой “промежуточной”), которую вся команда может использовать для просмотра и тестирования последних изменений, прежде чем они будут выпущены для клиентов.

3. Сокращение релизов и развертывание в рабочей среде

Наконец, после того, как у менеджеров и инженеров было время просмотреть и протестировать последние изменения в основной ветке, команды готовы выпустить релиз и развернуть его в рабочей среде! Часто эту задачу выполняет менеджер релиза — выделенный (или меняющийся) член команды, которому поручено выполнение сценариев развертывания и мониторинг релиза. Без использования GitOps этот член команды должен проверить, где находятся правильные сценарии, в каком порядке их выполнять, установлены ли на его компьютере все правильные библиотеки и пакеты, необходимые для запуска сценариев. Благодаря GitOps мы можем связать это развертывание с другим событием на основе Git — созданием релиза или тега. Все, что нужно сделать менеджеру релиза, — это создать новый “релиз”, часто используя semver для наименования. Задачи по сборке и развертыванию изменений кода будут запущены автоматически. Как и большинство задач, выполняемых инструментом CI, они будут настроены с расположением сценариев и порядком библиотек и пакетов, необходимых для их выполнения.

Инструменты GitOps

Надежный и интуитивно понятный инструмент непрерывной интеграции — не единственное, что необходимо для инструментирования процессов GitOps, подобных описанным в этой статье. Система CI может активировать сценарии на основе событий git, но вам все равно нужны мощные инструменты для запуска этих сценариев и обеспечения их простого и безопасного запуска и обслуживания. Развертывание изменений кода (также известное как непрерывная поставка, CD) — один из самых сложных шагов для автоматизации. Поэтому мы выбрали несколько категорий инструментов, которые могут помочь вам на пути к GitOps:

Контейнеризация с помощью Docker

Docker запустил облачную разработку в совершенно новую распределенную среду и помог разработчикам начать реалистично рассматривать микросервисные архитектуры как жизнеспособный вариант. Один из факторов, который делает Docker таким мощным, — это удобство для разработчиков по сравнению с решениями виртуализации предыдущего поколения. Как и в случае с декларативными конфигурациями CI, которые находятся в наших репозиториях, разработчикам просто нужно написать и поддерживать файл Dockerfile в своем репозитории, чтобы обеспечить автоматическую сборку развертываемых виртуальных машин в контейнерах. Контейнеризация — чрезвычайно мощная тактика для облачных команд, и она должна стать основным инструментом в вашем репертуаре.

Инфраструктура как код (IaC)

Многое уходит на подготовку инфраструктуры и развертывание приложений, которые не сохраняются в Dockerfile. Для всего остального есть решения “инфраструктура как код” (IaC), такие как Terraform, Cloudformation и другие. Эти решения позволяют разработчикам описывать другие части приложения, такие как ресурсы Kubernetes, балансировщики нагрузки, сеть, безопасность и многое другое, декларативным способом. Так же, как конфигурации CI и Dockerfiles, описанные ранее, шаблоны IaC могут контролироваться версиями и совместно работать над всеми разработчиками в вашей команде.
Комментарии
ЧТОБЫ ПОСМОТРЕТЬ ВСЕ КОММЕНТАРИИ ИЛИ ОСТАВИТЬ КОММЕНТАРИЙ,
ПЕРЕЙДИТЕ В ПОЛНУЮ ВЕРСИЮ