Jak Lockheed Martin ograniczył koszty utrzymania DevOps o 90%

Repozytoria Git, CI/CD, security scanning, issue tracking, container registry, compliance — w dużych zespołach inżynierskich zadania te są często obsługiwane przez różne narzędzia, wdrażane w różnym czasie i z myślą o różnych potrzebach.

Samo w sobie nie musi to stanowić problemu. Każde rozwiązanie może dobrze spełniać swoją funkcję. Złożoność pojawia się później — gdy zespół musi utrzymywać nie tylko proces rozwoju oprogramowania, ale także dziesiątki integracji, pluginów, konfiguracji i osobnych środowisk.

W tym momencie koszt stosu DevOps nie jest już określany wyłącznie przez licencje. Dochodzą do niego infrastruktura, aktualizacje, utrzymanie integracji oraz — co często jest jeszcze ważniejsze — czas pracy inżynierów.

Właśnie z taką sytuacją mierzył się Lockheed Martin — jeden z największych na świecie koncernów aerospace and defense, zatrudniający ponad 10 000 software engineers. Jego doświadczenie dobrze pokazuje, jakie korzyści może przynieść przejście od wielu niezależnych toolchainów do bardziej ustandaryzowanej platformy DevSecOps.

Kiedy DevOps toolchain staje się osobnym systemem, który trzeba utrzymywać

Poszczególne jednostki Lockheed Martin historycznie korzystały z własnych zestawów narzędzi DevOps. Wśród nich były ClearCase, Jenkins, Dimensions, Redmine, Bitbucket oraz inne rozwiązania. Poszczególne programy i zespoły produktowe budowały własne toolchainy niezależnie od siebie.

W efekcie poziom automatyzacji znacząco różnił się między zespołami. Niektóre miały dojrzałe procesy testowania i continuous deployment, inne korzystały jedynie z podstawowej automatyzacji, a część operacji nadal wykonywano ręcznie.

Powodowało to kilka typowych problemów:

• każde środowisko trzeba było osobno utrzymywać i aktualizować;
• podejścia do CI/CD i security różniły się między zespołami;
• ponowne wykorzystanie kodu i gotowych komponentów było trudniejsze;
• zmiany w pipelines trzeba było utrzymywać w wielu różnych środowiskach;
• część zasobów inżynierskich była przeznaczana nie na rozwój produktu, lecz na utrzymanie samego toolchainu.

W przypadku niektórych zespołów utrzymanie własnego development environment zajmowało około 20 godzin tygodniowo. W 12-osobowym zespole oznaczało to w praktyce stałe zaangażowanie znacznej części jednego zasobu inżynierskiego tylko po to, aby środowisko nadal działało.

Co zmieniło przejście na GitLab

Lockheed Martin rozpoczął stopniową standaryzację środowiska rozwoju oprogramowania w oparciu o GitLab.

Co ważne, celem nie było mechaniczne zastąpienie wszystkich istniejących narzędzi. Firma ograniczała liczbę niezależnych toolchainów tam, gdzie ich utrzymanie powodowało zbędną złożoność, koszty oraz zależność od lokalnych konfiguracji.

GitLab stał się wspólną platformą dla source code management, CI/CD oraz szeregu procesów DevSecOps. Pozwoliło to ustandaryzować pipelines, a jednocześnie zachować wystarczającą elastyczność dla różnych typów projektów.

Między innymi Lockheed Martin stworzył katalog reusable pipelines dla popularnych języków programowania, z gotowymi modułami do security scanning, container image builds oraz versioning. Ta sama konfiguracja pipeline może być wykorzystywana w różnych środowiskach, w tym w sieciach odizolowanych.

Obecnie za pośrednictwem wspólnego pipeline catalog firma obsługuje do 2 500 pipelines na minutę.

Rezultaty w liczbach

Po konsolidacji znacznej części procesów DevOps na GitLab Lockheed Martin uzyskał mierzalne efekty:

• do 80 razy szybsze CI pipeline builds;
• tysiące serwerów Jenkins zostały wycofane z eksploatacji;
• czas utrzymania poszczególnych development environments skrócił się o około 90%;
• utworzenie repository oraz pełnego CI pipeline w scenariuszu self-service skróciło się z co najmniej 40 godzin do około 30 minut;
• w GitLab działa około 64 000 projektów firmy.

Zmiany wpłynęły również na szybkość delivery. Zespoły, które wcześniej publikowały aktualizacje miesięcznie lub tygodniowo, w wielu przypadkach przeszły do codziennych lub kilku wdrożeń dziennie.

W przypadku projektów legacy średnia częstotliwość przekazywania zmian do testing również znacząco wzrosła: z około jednego razu w miesiącu do mniej więcej jednego razu na sześć dni.

Dlaczego chodzi o coś więcej niż szybsze CI/CD

80-krotne przyspieszenie pipeline builds przyciąga uwagę, ale z perspektywy CTO ważniejszy jest efekt systemowy.

Zasoby inżynierskie, które wcześniej były wykorzystywane do utrzymania Jenkins instances, lokalnych environments i integracji, mogły zostać skierowane z powrotem do zadań bezpośrednio związanych z rozwojem oprogramowania.

Według Lockheed Martin zespoły, które wcześniej przeznaczały około 20 godzin tygodniowo na maintenance, po przejściu potrzebują na to jedynie kilku godzin. W skali organizacji zatrudniającej ponad 10 000 software engineers oznacza to setki i tysiące uwolnionych roboczogodzin.

Dlatego przy ocenie platformy DevOps warto patrzeć nie tylko na license cost. Istotną część Total Cost of Ownership mogą stanowić infrastruktura, administracja, aktualizacje, utrzymanie integracji oraz engineering time.

Standaryzacja bez utraty elastyczności

W dużej organizacji konsolidacja nie może oznaczać identycznego procesu dla wszystkich.

Lockheed Martin pracuje zarówno z zespołami wymagającymi szybkiego development cycle, jak i z systemami mission-critical, w których zmiany muszą przechodzić znacznie bardziej rygorystyczne kontrole.

Dlatego firma zbudowała swoje podejście wokół wspólnych reusable pipeline templates, które można wykorzystywać w różnych środowiskach i dostosowywać do wymagań konkretnego projektu.

To istotna różnica między prostą wymianą narzędzia a standaryzacją platformową: zespół otrzymuje wspólny, bazowy proces, ale nie traci możliwości jego dostosowania tam, gdzie wymagają tego architektura, bezpieczeństwo lub biznes.

Security i compliance stają się częścią pipeline

Dla Lockheed Martin kwestia security ma szczególne znaczenie: firma pracuje z systemami obronnymi i rządowymi, gdzie wymagania dotyczące bezpieczeństwa i compliance są integralną częścią procesu software delivery.

W rozproszonym toolchainie praktyki security mogą różnić się między zespołami, a aktualizacje poszczególnych komponentów mogą wymagać dodatkowej kontroli.

Ustandaryzowane GitLab pipelines umożliwiły wbudowanie security scanning oraz innych kontroli bezpośrednio we wspólne procesy. Dzięki temu zespoły uzyskały spójny, bazowy poziom zautomatyzowanych praktyk security bez konieczności każdorazowego konfigurowania osobnego zestawu narzędzi.

GitLab + AWS: jak skalować CI/CD dla tysięcy programistów

Szybkie upowszechnienie GitLab wewnątrz Lockheed Martin stworzyło kolejne wyzwanie — skalowanie platformy dla dużej liczby użytkowników i pipeline runs.

W tym celu Lockheed Martin, GitLab i AWS wspólnie zoptymalizowały ekosystem CI/CD. Infrastrukturę zaczęto wdrażać z wykorzystaniem Infrastructure as Code, zautomatyzowano Disaster Recovery oraz skonfigurowano automatyczne skalowanie zależne od obciążenia.

Efekt: kolejka build requests przestała się kumulować — z 200 oczekujących żądań do zera — a czas wdrażania kodu skrócił się w skali całej organizacji.

Ten etap dobrze pokazuje jeszcze jedną zaletę podejścia platformowego: po standaryzacji procesów software delivery znacznie łatwiej je skalować i automatyzować na poziomie całej organizacji.

Co ten case oznacza dla CTO

Doświadczenie Lockheed Martin nie oznacza, że każda firma powinna zrezygnować z Jenkins, GitHub, Jira lub dowolnego innego narzędzia.

Bardziej użyteczne pytanie brzmi: ile naprawdę kosztuje utrzymanie obecnego stosu DevOps i jaką część tej złożoności rzeczywiście warto zachować?

Przy ocenie obecnej architektury warto przyjrzeć się trzem obszarom:

• Engineering time. Ile czasu zespoły DevOps i development poświęcają na utrzymanie pipelines, plugins, integrations i environments?
• Powtarzalność. Ile różnych sposobów wykonania tej samej operacji funkcjonuje w różnych zespołach?
• Zależności. W jakim stopniu stabilność buildów zależy od ręcznych ustawień i wiedzy konkretnych osób, a nie od jednego, odtwarzalnego procesu?

Jeśli koszty te rosną wraz z liczbą zespołów i projektów, problem może już nie dotyczyć pojedynczego narzędzia, lecz samej architektury toolchainu.

Czy konsolidacja oznacza pełną migrację?

Nie. I sam case Lockheed Martin również to potwierdza.

Firma nie zrezygnowała ze wszystkich pozostałych toolchainów. Część Jenkins instances i specjalistycznych środowisk pozostała tam, gdzie wymagały tego konkretne programy lub klienci.

Ich udział stał się jednak na tyle mały, że przestały generować systemową złożoność dla całej organizacji.

Dlatego praktyczne podejście do GitLab nie musi zaczynać się od pytania „czym zastąpić cały nasz stack?”. Lepiej najpierw określić procesy, w których konsolidacja może przynieść największy efekt: CI/CD, source code management, security, compliance lub standaryzacja development environments.

Jak Softprom może pomóc

Przejście do jednej platformy DevSecOps warto rozpocząć nie od listy funkcji GitLab, lecz od analizy obecnego procesu software delivery.

Zespół Softprom pomaga ocenić istniejący DevOps toolchain, zidentyfikować obszary generujące największe koszty operacyjne i określić, które procesy warto skonsolidować w oparciu o GitLab, a które na razie pozostawić bez zmian.

Softprom jest autoryzowanym partnerem GitLab w Europie Środkowo-Wschodniej, na Kaukazie i w Azji Centralnej oraz wspiera klientów na etapach oceny rozwiązania, licencjonowania, planowania migracji i rozwoju procesów DevSecOps.

Materiał został przygotowany przez Softprom na podstawie publicznego customer story GitLab dotyczącego doświadczeń Lockheed Martin. Oryginalne case study GitLab.