Як ПриватБанк побудував безпечне середовище для тисячі розробників разом з GitLab і Cloudfresh

ПриватБанк — один із найбільших банків Східної Європи. А з точки зору технологій це ще й одна з найбільших IT-організацій в Україні.

Більше 80% програмного забезпечення, яке використовується всередині банку та клієнтами, створюється власними командами. І водночас банк має відповідати дуже високим вимогам безпеки, комплаєнсу, стабільності та контролю змін. Тому команда шукала платформу, яка дозволить стандартизувати розробку в усій організації.

Раніше інструменти були розрізнені: Jenkins використовувався для CI, код зберігався в інших системах, а процеси були розподілені між різними платформами.

Це створювало проблеми:

• Відсутність єдиного середовища
• Різні стандарти розробки
• Низька прозорість процесів

Тому банк почав поступово переходити до єдиної DevSecOps-платформи.

Чому GitLab

Приблизно за останні 1,5–2 роки GitLab був затверджений як стандарт платформи розробки в банку. І не тільки для зберігання коду. GitLab став основою для управління проєктами, CI/CD, безпеки коду, контролю змін, аудиту та комплаєнсу.

У ПриватБанку GitLab став ядром DevSecOps-процесу.

Dev: Стандартизована розробка і єдиний воркфлоу

Для ПриватБанку ключовим викликом було не просто зберігати код, а побудувати єдиний підхід до розробки для всієї організації.

Коли в компанії працюють сотні інженерів і десятки команд, навіть невеликі відмінності у процесах можуть створювати хаос: різні інструменти, різні правила роботи з кодом і різні підходи до рев’ю. Саме тому банк почав використовувати GitLab як єдину платформу розробки, що об’єднує всі ключові етапи роботи з кодом:

У результаті розробник бачить увесь процес в одному середовищі — від першого коміту до доставки змін у систему.

Code review як стандарт інженерної культури

Однією з ключових змін стало те, що GitLab ліг в основу внутрішнього стандарту розробки в банку.

Будь-яка зміна у коді проходить через merge request workflow. Коли розробник створює мердж-реквест, інші інженери перевіряють зміни. Під час review команда може:

• Перевірити відповідність стандартам коду
• Звернути увагу на потенційні проблеми
• Запропонувати кращі архітектурні рішення
• Переконатися, що код відповідає вимогам безпеки

Уся історія змін зберігається в системі, тому в будь-який момент можна зрозуміти, як розвивався код і чому були ухвалені ті чи інші рішення.

Для великої організації це особливо важливо: GitLab робить процес review прозорим і автоматизованим навіть для розподілених команд. У результаті code review стає механізмом підвищення якості коду.

Гнучкість розробки в масштабах банку

Іще один важливий аспект для ПриватБанку — можливість працювати над різними задачами паралельно.

У банківських системах поряд із довгостроковими проєктами часто потрібно швидко реалізувати термінові зміни — наприклад, нові регуляторні вимоги. Саме тому команди активно використовують у GitLab гнучку модель роботи з гілками.

Це дозволяє одночасно працювати над різними типами задач:

• Довготривалими функціональними розробками
• Критичними терміновими змінами
• Експериментальними або дослідницькими проєктами

У практичному сенсі це означає, що команда може створити окрему гілку для термінової зміни, реалізувати її і доставити в production, не зупиняючи роботу над великим проєктом.

Infrastructure-as-Code та зрозуміла архітектура

Не менш важливий принцип інженерної практики банку — опис інфраструктури разом із кодом. Такий підхід дозволяє командам працювати з системою як із цілісним середовищем, а не лише з окремими фрагментами коду.

Коли новий інженер приєднується до команди, він отримує повний контекст системи:

• Документований код
• Описану архітектуру
• Зрозумілу структуру компонентів

Це суттєво спрощує онбординг і дозволяє швидше почати роботу з проєктом.

Крім того, GitLab дозволяє запускати окремі гілки для тестування змін. Розробник може внести зміни, розгорнути їх у власному середовищі та одразу побачити результат — без очікування загальної збірки системи.

Для організації масштабу ПриватБанку це помітно скорочує час між створенням і перевіркою нових функцій.

Sec: Безпека як частина процесу розробки

Для фінансової установи безпека не може бути окремим етапом після написання коду, тому в ПриватБанку її інтегрували безпосередньо в процес розробки.

Коли розробник створює нову функцію або додає бібліотеку, під час pipeline запускаються інструменти аналізу безпеки ще до того, як зміни потрапляють у загальний репозиторій.

Зокрема банк використовує у GitLab такі механізми перевірки:

• SAST — аналіз вихідного коду на потенційні вразливості
• Dependency scanning — перевірку сторонніх бібліотек
• Vulnerability scanning — виявлення відомих ризиків у залежностях

Ці перевірки працюють прямо у CI/CD pipeline. Тому команда бачить проблеми ще до того, як код потрапляє навіть у тестове середовище.

Як пояснюють у банку, ключова зміна полягає в тому, що розробник отримує зворотний зв’язок одразу. Якщо бібліотека містить вразливість або не відповідає політикам організації, система повідомляє про це ще на етапі роботи з кодом.

Це кардинально змінює сам цикл розробки.

Раніше він виглядав приблизно так:

• Розробник пише код
• Робить commit
• Запускається збірка
• Відбувається перевірка
• Виявляється проблема
• Код потрібно переробляти і запускати цикл заново

Тепер частина цих повторюваних кроків просто зникає. Інженер бачить проблему відразу і виправляє її в момент роботи з кодом.

За оцінкою команди, це дозволило прибрати кілька повторюваних ітерацій перевірки і зекономити приблизно 15–25% часу, який раніше витрачався саме на такі цикли.

Але для ПриватБанку найважливішим результатом стала не швидкість. Найважливішим стала якість коду.

Коли перевірки інтегровані у процес розробки, інженери починають писати код інакше. Вони відразу враховують вимоги безпеки, стандарти організації та архітектурні правила. У результаті код, який проходить у систему, з першого разу відповідає внутрішнім політикам.

Це призводить до кількох важливих змін:

Контроль open source та ліцензій

Іще один важливий аспект для банку — контроль open-source-компонентів.

Різні ліцензії можуть накладати серйозні обмеження:

• Вимагати відкриття власного коду
• Створювати юридичні конфлікти
• Призводити до штрафів або репутаційних проблем

Для організації масштабу ПриватБанку контроль таких ризиків вручну практично неможливий, тому банк автоматизував цей процес за допомогою GitLab.

Під час CI/CD pipeline система формує Software Bill of Materials (SBOM) — повний список компонентів, які входять до складу програмного продукту. Для цього використовуються індустріальні стандарти CycloneDX та SPDX.

На основі цієї інформації команда банку налаштовує власні політики використання open source.

Це означає, що система автоматично:

• Визначає ліцензії залежностей
• Перевіряє їх на відповідність внутрішнім правилам
• Повідомляє розробника про можливі порушення

Якщо нова бібліотека не відповідає політикам організації, розробник отримує сигнал прямо під час merge request. Він може або отримати необхідне погодження, або відразу обрати іншу залежність.

Таким чином контроль ліцензій перестає бути окремим процесом, який відбувається після розробки. Він стає природною частиною workflow інженера.

Повна прозорість змін і аудит

Для фінансової установи не менш важливим є контроль змін у коді. Будь-яка зміна повинна бути відстежуваною і зрозумілою.

Саме тому у GitLab ПриватБанк використовує механізми політик і контролю доступу, які дозволяють регулювати процес внесення змін.

Зокрема команда налаштувала:

• Політики схвалення для критичних змін
• Обов’язкове рецензування запитів на злиття
• Обмеження на commit для певних ролей
• Повний аудиторський слід усіх змін

Це означає, що у будь-який момент банк може відповісти на три ключові запитання: хто вніс зміну в код, хто її перевірив і затвердив та чому вона потрапила в реліз.

Для великої фінансової організації така прозорість є критичною. Вона дозволяє швидко проводити внутрішні аудити, аналізувати інциденти та забезпечувати відповідність регуляторним вимогам.

У результаті безпека перестає бути окремою функцією або процесом, який контролює лише окрема команда. Вона стає невід’ємною частиною повсякденної роботи інженерів, інтегрованою у саму платформу розробки.

Ops: Контрольована доставка змін

У середовищі, де десятки команд щодня змінюють сотні систем, написати код — лише половина задачі. Не менш важливо як цей код доставляється у систему. Будь-яка зміна повинна проходити чітко контрольований шлях — від коміту до продакшену.

Після того як GitLab був затверджений як стандарт платформи розробки, команда створила внутрішні правила роботи з CI/CD. У банку навіть з’явилися окремі положення, які визначають, як мають будуватися пайплайни і як команди повинні працювати з доставкою коду.

Більшість проєктів сьогодні використовує GitLab CI/СD як основний механізм автоматизації. Це дозволило стандартизувати процеси збірки, тестування і доставки змін у різних командах.

При цьому пайплайни залишаються достатньо гнучкими, щоб враховувати специфіку різних систем. У CI/CD-процеси банк інтегрує не лише стандартні можливості GitLab, а й власні інструменти контролю якості та безпеки.

Зокрема у pipeline можуть підключатися:

• Внутрішні інструменти безпеки
• Власні SAST-сканери
• Перевірки відповідності технологічним стандартам банку

Такий підхід дозволяє об’єднати автоматизацію GitLab із внутрішніми механізмами контролю, які банк розробляв роками.

Робота з legacy-системами

Окремий виклик для великої фінансової організації — це наявність значної кількості legacy-систем.

Багато з них створювалися ще до появи сучасних DevOps-практик і не завжди легко інтегруються у стандартні процеси автоматизації. Повністю перебудувати такі системи за короткий час практично неможливо.

Тому команда банку використала гнучкість GitLab, щоб поступово інтегрувати і ці системи у CI/CD-процес.

Навіть якщо окремі етапи для legacy-проєктів залишаються частково ручними, GitLab дозволяє побудувати навколо них контрольований pipeline. Це означає, що:

• Усі зміни проходять через єдиний процес збірки
• Результати перевірок зберігаються у системі
• Історія релізів залишається прозорою

Врешті решт навіть старі системи стають частиною єдиного інженерного процесу банку.

Менше ручної роботи — більше контролю

Для команди ПриватБанку головна цінність CI/CD полягає не лише у швидкості релізів. Важливішим є те, що доставка коду стає передбачуваним і контрольованим процесом.

Коли pipeline автоматизує перевірки та збірку системи, команди можуть бути впевнені, що кожна зміна проходить однакові етапи. Це зменшує ризик помилок і робить процес релізів стабільнішим.

У поєднанні з механізмами Dev і Sec це створює єдину модель роботи:

• Код проходить стандартизований рев’ю
• Автоматично перевіряється на вразливості
• Доставляється через контрольований pipeline

Таким чином GitLab допоміг ПриватБанку побудувати повноцінний DevSecOps-процес, де розробка, безпека і операційні процеси працюють як єдина система.

Якість коду як головна метрика успіху

У ПриватБанку результати впровадження GitLab оцінюють не окремими показниками швидкості, а тим, який код у результаті отримує організація.

Це змінює не лише технічний процес, а й роботу команд. Інженери витрачають менше часу на пошук проблем у production і більше — на розвиток продуктів.

Іще один важливий ефект — швидший онбординг нових розробників. Коли код структурований, задокументований і проходить стандартизовані перевірки, новим інженерам значно легше занурюватися у проєкти.

Масштаб інженерної організації

Щоб зрозуміти, чому стандартизація процесів настільки важлива, достатньо подивитися на масштаб розробки у ПриватБанку. Сьогодні GitLab використовується для роботи над сотнями систем і тисячами компонентів. Зокрема:

• 700+ внутрішніх та зовнішніх платформ
• 1 000 розробників, які працюють одночасно
• Десятки команд, що працюють у режимі 24/7

І цей масштаб добре видно не лише на рівні організації, а й у щоденній роботі з платформою. Лише за останні два місяці в GitLab-середовищі ПриватБанку:

На такому масштабі будь-яка відсутність стандартів швидко перетворюється на серйозну проблему. Саме тому централізація процесів розробки стала одним із ключових факторів успіху.

Стабільність платформи

GitLab у ПриватБанку працює у self-hosted середовищі, що дозволяє повністю контролювати інфраструктуру і відповідати вимогам безпеки фінансової установи.

За словами команди банку, платформа демонструє дуже високий рівень стабільності.

Для організації, де тисячі інженерів працюють із кодом щодня, це критично важливий фактор. Надійність платформи означає, що команди можуть зосередитися на розвитку продуктів, не витрачаючи час на вирішення інфраструктурних проблем.

Партнерство з Cloudfresh

Перехід ПриватБанку на комерційну версію GitLab відбувався у співпраці з Cloudfresh — офіційним партнером GitLab в Україні.

Команда Cloudfresh супроводжує банк у кількох ключових напрямах: від ліцензування платформи до підтримки інженерних команд під час масштабування DevSecOps-процесів.

Зокрема співпраця включає:

• Консультації щодо ліцензування та оптимальної моделі використання GitLab
• Технічну експертизу під час впровадження нових можливостей платформи, як-от Duo Agent Platform
• Підтримку інженерних команд під час роботи з GitLab
• Допомогу у вирішенні технічних питань

Для великої організації, де тисячі інженерів працюють із платформою щодня, важливо мати доступ до експертизи і швидкої підтримки.

Такий формат співпраці дозволяє ПриватБанку не лише підтримувати стабільну роботу платформи, а й поступово розширювати її використання. Разом із Cloudfresh команда банку тестує нові можливості GitLab і впроваджує їх у свої інженерні процеси.

AI-підхід до розробки

Наступний етап розвитку платформи — інтеграція AI-інструментів у процес розробки. Команда вже тестує нові IDE та AI-агентів, а також експериментує з можливостями GitLab Duo Agent Platform. 

Серед потенційних напрямків використання:

• Автоматична перевірка якості коду
• Аналіз дотримання стандартів технологічного стеку
• Оптимізація CI/CD-процесів
• Додаткова підтримка інженерів під час написання коду

Поки що ці можливості використовуються у пілотних сценаріях, але команда банку активно досліджує, як інтегрувати ШІ у повсякденний workflow розробників.

У результаті GitLab став для ПриватБанку не просто системою для зберігання коду. Платформа об’єднала розробку, безпеку та операційні процеси в єдину інженерну систему, яка дозволяє надалі масштабуватися одній із найбільших фінансових організацій країни.