Continuous Integration – безперервний процес інтеграції коду, який пишуть різні розробники, до загального репозиторію. Це супроводжується виконанням модульних, інтеграційних та інших тестів. Завдяки цим діям до програмного забезпечення додається нова функціональність. На цьому CI завершується. За нею йде стадія Continuous Delivery або Continuous Deployment. Це два абсолютно різні процеси.
Continuous Deployment – процес ручного транспортування зібраного архіву на потрібний сервер: QA, Staging чи Production. На відміну від Continuous Deployment, Continuous Delivery відбувається повністю автоматично.
За кожен з цих процесів відповідальність несуть різні спеціалісти. Continuous Integration в межах компетенції розробників, а Continuous Deployment чи Delivery – DevOps-інженерів.
CI/CD Pipeline
Розглянемо, як CI/CD працює у реальному житті. Існують утиліти, які допомагають автоматизувати всі дії. Мова про Gitlab, CircleCI, Jenkins та інші. Це необхідно, адже такі процеси при ручному виконанні займають дуже багато часу, а також виникає ймовірність помилки через вплив людського фактора.
Усі CI/CD утиліти працюють з пайплайнами (з англ. pipeline – конвеєр). Це послідовна заданість певних дій, які повинні бути реалізовані. Якщо якась із них не була виконана, потрібно перезапустити весь пайплайн.
Наприклад:
- Розробник вносить певні зміни та записує новий код у репозиторій.
- CI/CD утиліта, яку він використовує – припустимо, Jenkins, – розпізнає цю інформацію та запускає білд (від англ. build – збірка).
- Що це означає? Як відомо, програмісти пишуть код зрозумілою їм мовою, наприклад, Java, PHP, C#, Ruby і т.д. Потім відбувається компіляція – процес перетворення коду у формат, доступний для середовища, де він буде запускатися. Іншими словами – у машинний код.
- Під час білду необхідно виконувати модульне чи інтеграційне тестування. Якщо тести пройдені успішно, можна переходити до наступного кроку. Якщо ні – потрібно повідомити про проблему розробнику, який вніс останні зміни.
- Розробник виправляє помилку, після чого тести мають бути запущені повторно.
- Програма готова до трансферу на будь-який з вказаних серверів: QA, Staging чи Production.
- Пайплайн не обов’язково повинен мати такий вигляд. В ньому може не бути обов’язкових кроків, їх дозволено пропускати на свій розсуд або додавати інші, в залежності від потреб проєкту.
Blue/Green Deployment
Щоб виправдовувати очікування вимогливої аудиторії, сучасні команди намагаються робити безшовні релізи програмного забезпечення. Вони полягають у тому, що цифрове рішення має стару версію, а потім користувачі отримують змогу без жодних затримок працювати з новою. Існує безліч стратегій, за допомогою яких цього можна досягти.
Одна з них – Blue/Green Deployment. Вона передбачає наявність старої версії, яка відмічається як зелена. В такому ж середовищі розгортається нова версія програми, яка позначається синім кольором. В певний момент здійснюється переключення користувачів між ними. Перевага такого підходу в тому, що, якщо перехід відбувся з дефектами, завжди залишається змога повернутися до попередньої версії.
Попри таку можливість, баги будуть помічені аудиторією, що може негативно позначитися на її лояльності. Для запобігання цій проблемі іноді використовується альтернативна стратегія – Canary Deployment. Її сутність полягає в тому, що на нову версію ПЗ переключаються не всі користувачі, а лише їх певний відсоток. Від них потрібно зібрати зворотний зв’язок: якщо все працює коректно, інші користувачі також переводяться на нову версію програми. Якщо ні, незадоволеною буде лише невелика частина споживачів.
Зверніть увагу: Щоб ви мали змогу скористатися стратегією Blue/Green Deployment, у програмного забезпечення має бути відповідна архітектура – не кожен застосунок можна розгорнути за таким принципом.
Cloud Platforms
Якщо команда працює над масштабними проєктами, наприклад, розробкою enterprise-системи, дуже доречним буде використання хмарних платформ. Це сервери, які надають змогу орендувати їхні ресурси в певній кількості, а за потреби – масштабуватися. Вони пропонують такі послуги:
- Computer Services – клієнти мають можливість придбати сервери, за масштабування та обслуговування яких буде відповідати хмарна платформа.
- Object Storage – користувачі можуть зберігати на платформі бінарні (не текстові) файли.
- Networking – розробники, які працюють з мікросервісною архітектурою, повинні мати змогу поєднати всі компоненти ПЗ між собою. Це також можна зробити за допомогою інструментів Cloud Platform.
Можна сказати, що хмарна платформа – це своєрідний супермаркет готових рішень, але ви там нічого не купуєте, а берете в оренду. Серед платформ, які особливо популярні у великих компаній, – AWS, Microsoft Azure та Google Cloud.
Переваги хмарних платформ:
- Простота використання. У кожної платформи є зручний вебінтерфейс, який можна використовувати для вивчення можливостей віртуального сервера та налаштування його сервісів відповідно до власних потреб.
- Гнучкість. Кожен розробник з високою часткою ймовірності знайде тут все, що йому потрібно для роботи, та не буде витрачати час на налаштування локальних серверів.
- Економічність. Користувачі платять лише за той об’єм послуг, який їм необхідний саме зараз.
- Надійність. Платформи гарантують, що їхні сервіси доступні клієнтам у 99,999 % часу, і вони дійсно над цим працюють.
- Масштабованість. Хмарні сервери надають можливість горизонтально та вертикально масштабуватися.
- Безпека. Такі платформи мають всі необхідні сертифікати, тому хостити на них програми безпечно.
Контейнеризація як спосіб трансферу між Cloud платформами
Іноді у команди може виникнути необхідність перенесення застосунку, розгорнутого на одній хмарній платформі, в іншу. Для того, щоб зробити це швидко і просто, були розроблені контейнери. Якщо ваша програма написана з використанням кросплатформової мови (наприклад, Java), все, що вам залишиться зробити, «запакувати» її в контейнер та запустити в будь-якому середовищі.
Розглянемо сутність контейнеризації на прикладі Docker Container – системи управління контейнерами, яка дозволяє легко виконувати різні маніпуляції з ПЗ: переносити його на інший сервер, оновлювати та масштабувати. Робота з нею складається з кількох етапів:
- Щоб запустити систему, необхідно встановити клієнт-серверний додаток Docker Engine, або Docker Host.
- Далі потрібно сформувати незмінний образ (Image) – інструкцію, яка визначає послідовність дій системи. Зручно те, що в разі відсутності певного образа можна скористатися віддаленим сховищем готових рішень Docker Registry або реєстром Docker Hub.
- Вручну запустити роботу контейнера на основі Image. Якщо їх багато, керувати ними можна за допомогою ПЗ для оркестрування контейнерами типу Kubernetes.
Зверніть увагу: ви можете запустити стільки контейнерів, скільки дозволяють ваші ресурси. Наприклад, якщо для запуску недостатньо оперативної пам’яті, процес просто не розпочнеться. Програми в кожному контейнері працюють ізольовано, а комунікують за допомогою налаштування мережі.
Віртуальні машини (ВМ) VS контейнери
Зазвичай як альтернативу контейнеризації розглядають віртуальні машини. Та чи є між ними різниця?
- Для того, щоб запустити контейнер, потрібен сервер, серверна операційна система і Docker Engine, який власне здійснює запуск кожного застосунку.
- Для роботи з віртуальною машиною окрім сервера та серверної операційної системи потрібен гіпервізор – програма, яка дозволяє запускати декілька ОС одночасно, та безпосередньо ці операційні системи. Тільки після встановлення всього переліченого вище з’являється можливість сконфігурувати застосунок.
Таким чином, контейнери займають менше ресурсів і запускаються швидше.
Радимо вам наш технічний словник бізнес-аналітика, для того, щоб найголовніша інформація завжди була під рукою.
Сформуйте мінімальний набір технічних знань та процесів із розробки ПЗ на курсі Online Technical Skills for PMs and BAs. На курсі ціле заняття присвячено темі CI/CD і Тестуванню.