Как 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 запросов в ожидании до нуля — и сократилось время развертывания кода в масштабе всей организации.

Этот этап хорошо показывает еще одну особенность платформенного подхода: после стандартизации 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.