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

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

Джерело: freeCodeCamp У мові програмування Java ми використовуємо оператори для операцій над змінними. Оператори поділяються на різні категорії: арифметичні, оператори присвоювання, оператори порівняння, логічні оператори тощо. У цій статті ми поговоримо про бітовий оператор AND ( & ), а також про логічні оператори AND ( && ) and OR ( || ).

Як використовувати бітовий оператор AND

Символ & позначає побітовий оператор AND. Він оцінює двійкове значення заданих чисел. Двійковий результат цих чисел буде повернуто нам у базі 10. Коли оператор & почне свою роботу, він оцінить значення символів в обох числах, починаючи зліва. Давайте розглянемо приклад, який допоможе краще це зрозуміти:

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

Як це пояснити? Двійкове значення 10 дорівнює 1010. Ось що потрібно врахувати, перш ніж ми почнемо операцію: 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 – допомога розробникам у максимально швидкому та безпечному розгортанні функції у робочому середовищі. Це означає створення інструментів та процесів, які роблять все: від надання приватних середовищ розробки до розгортання та захисту виробничих робочих навантажень. При цьому поспіх не повинен призвести до критичних збоїв. 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 полягає в тому, що всі процеси постійно виконуються! Кожна зміна запускає тестові зборки і розгортання без будь-яких дій, що виконуються вручну. Оскільки розробники будуть використовувати 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 можуть контролюватись версіями та спільно працювати над усіма розробниками у вашій команді.