Як Lockheed Martin скоротила DevOps-maintenance на 90%

Git-репозиторії, CI/CD, security scanning, issue tracking, container registry, compliance — у великих engineering-командах ці задачі часто закриваються різними інструментами, які з'являлися в різний час і під різні потреби.

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

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

Саме з такою ситуацією зіткнулася Lockheed Martin — одна з найбільших у світі aerospace and defense компаній із понад 10 000 software engineers. Її досвід добре показує, що може дати перехід від великої кількості окремих toolchains до більш стандартизованої DevSecOps-платформи.

Коли DevOps toolchain стає окремою системою, яку потрібно підтримувати

Різні підрозділи Lockheed Martin історично використовували власні набори DevOps-інструментів. Серед них були ClearCase, Jenkins, Dimensions, Redmine, Bitbucket та інші рішення. Окремі програми й продуктові команди формували свої toolchains незалежно одна від одної.

У результаті рівень автоматизації суттєво відрізнявся між командами. Одні мали зрілі процеси тестування та continuous deployment, інші — лише базову автоматизацію, а частина операцій залишалася ручною.

Це створювало одразу кілька типових проблем:

• кожне середовище потрібно було окремо підтримувати та оновлювати;
• підходи до CI/CD і security відрізнялися між командами;
• було складніше повторно використовувати код та готові компоненти;
• зміни в pipelines доводилося підтримувати в багатьох різних середовищах;
• частина engineering-ресурсу витрачалася не на продукт, а на підтримку самого toolchain.

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

Що змінив перехід на GitLab

Lockheed Martin почала поступово стандартизувати середовище розробки програмного забезпечення на базі GitLab.

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

GitLab став спільною платформою для source code management, CI/CD та низки DevSecOps-процесів. Це дозволило стандартизувати pipelines і водночас залишити командам достатньо гнучкості для різних типів проєктів.

Зокрема, Lockheed Martin створила каталог reusable pipelines для популярних мов програмування з готовими модулями для security scanning, container image builds та versioning. Одна й та сама pipeline-конфігурація може використовуватися в різних середовищах, включно з ізольованими мережами.

Сьогодні через спільний pipeline catalog компанія обробляє до 2 500 pipelines за хвилину.

Результат у цифрах

Після консолідації значної частини DevOps-процесів на GitLab Lockheed Martin отримала вимірюваний ефект:

• до 80 разів швидші CI pipeline builds;
• тисячі Jenkins-серверів були виведені з експлуатації;
• час на підтримку окремих development environments скоротився приблизно на 90%;
• створення repository та повного CI pipeline у self-service сценарії скоротилося з мінімум 40 годин до приблизно 30 хвилин;
• у GitLab працює близько 64 000 проєктів компанії.

Зміни вплинули й на швидкість delivery. Команди, які раніше випускали оновлення щомісяця або щотижня, у багатьох випадках перейшли до щоденних або кількох delivery на день.

Для legacy-проєктів середня частота передачі змін на testing також суттєво зросла: замість приблизно одного разу на місяць — орієнтовно раз на шість днів.

Чому справа не лише у швидшому CI/CD

80-кратне прискорення pipeline builds привертає увагу, але для CTO важливіший системний результат.

Інженерний ресурс, який раніше витрачався на підтримку Jenkins instances, локальних environments та інтеграцій, повернувся до задач, безпосередньо пов'язаних із розробкою.

За оцінкою Lockheed Martin, команди, які раніше витрачали близько 20 годин на тиждень на maintenance, після переходу потребують лише кілька годин. У масштабі організації з понад 10 000 software engineers це означає сотні й тисячі вивільнених людино-годин.

Саме тому під час оцінки DevOps-платформи варто дивитися не лише на license cost. Значну частину Total Cost of Ownership можуть формувати інфраструктура, адміністрування, оновлення, підтримка інтеграцій та engineering time.

Стандартизація без втрати гнучкості

Для великої організації консолідація не може означати однаковий процес для всіх.

Lockheed Martin працює як із командами, яким потрібен швидкий development cycle, так і з mission-critical системами, де зміни повинні проходити значно жорсткішу перевірку.

Тому компанія побудувала підхід навколо спільних reusable pipeline templates, які можна використовувати в різних середовищах і адаптувати до вимог конкретного проєкту.

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

Security і compliance стають частиною pipeline

Для Lockheed Martin питання security має особливе значення: компанія працює з оборонними та державними системами, де вимоги до безпеки й compliance є частиною самого процесу delivery software.

У фрагментованому toolchain security-практики можуть відрізнятися між командами, а оновлення окремих компонентів — вимагати додаткового контролю.

Стандартизовані GitLab pipelines дозволили вбудувати security scanning та інші перевірки безпосередньо у спільні процеси. У результаті команди отримали однаковий базовий рівень автоматизованих security-практик без необхідності щоразу конфігурувати окремий набір інструментів.

GitLab + AWS: як масштабувати CI/CD для тисяч розробників

Швидке поширення GitLab усередині Lockheed Martin створило наступне завдання — масштабувати платформу для великої кількості користувачів і pipeline runs.

Для цього Lockheed Martin, GitLab та AWS спільно оптимізували екосистему CI/CD. Інфраструктуру почали розгортати за допомогою Infrastructure as Code, автоматизували Disaster Recovery та налаштували автоматичне масштабування відповідно до навантаження.

Після оптимізації кількість build requests, які очікували на виконання, скоротилася з 200 до 0.

Цей етап добре показує ще одну особливість платформенного підходу: після стандартизації software delivery процесів їх значно простіше масштабувати та автоматизувати на рівні всієї організації.

Що цей кейс означає для CTO

Досвід Lockheed Martin не означає, що кожній компанії потрібно відмовитися від Jenkins, GitHub, Jira або будь-якого іншого інструмента.

Більш корисне питання — скільки коштує підтримка поточного DevOps-стека і яку частину цієї складності дійсно потрібно зберігати?

При оцінці поточної архітектури варто подивитися на три речі:

• Engineering time. Скільки часу DevOps та development-команди витрачають на підтримку pipelines, plugins, integrations та environments?
• Повторюваність. Скільки різних способів виконати одну й ту саму операцію існує в різних командах?
• Залежності. Наскільки стабільність процесу залежить від окремих людей, локальних конфігурацій або застарілих компонентів?

Якщо ці витрати зростають разом із кількістю команд і проєктів, проблема може бути вже не в конкретному інструменті, а в самій архітектурі toolchain.

Чи означає консолідація повну міграцію?

Ні. І сам кейс Lockheed Martin це підтверджує.

Компанія не відмовилася від усіх інших toolchains. Частина Jenkins instances та спеціалізованих середовищ залишилася там, де цього вимагали конкретні програми або замовники.

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

Тому практичний підхід до GitLab може починатися не з питання «чим замінити весь наш стек?», а з визначення процесів, де консолідація дасть найбільший ефект: CI/CD, source code management, security, compliance або стандартизація development environments.

Як Softprom може допомогти

Перехід до єдиної DevSecOps-платформи варто починати не з переліку функцій GitLab, а з аналізу поточного процесу delivery software.

Команда Softprom допомагає оцінити наявний DevOps toolchain, визначити точки найбільших операційних витрат і зрозуміти, які процеси доцільно консолідувати на базі GitLab, а які поки варто залишити без змін.

Softprom є авторизованим партнером GitLab у Центральній та Східній Європі, на Кавказі та в Центральній Азії та підтримує замовників на етапах оцінки рішення, ліцензування, планування міграції та розвитку DevSecOps-процесів.

Матеріал підготовлено Softprom на основі публічного customer story GitLab про досвід Lockheed Martin. Оригінальний кейс GitLab.