Obrazek:
Cześć wszystkim! Jesteśmy inżynierami automatykami z firmy oraz wspieramy rozwój produktów firmy: wspieramy cały proces montażu od zatwierdzenia linii kodu przez programistów po publikację gotowych produktów i licencji na serwerach aktualizacji. Nieformalnie nazywamy się inżynierami DevOps. W tym artykule chcemy porozmawiać o etapach technologicznych procesu produkcji oprogramowania, jak je postrzegamy i jak je klasyfikujemy.
Z materiału dowiesz się, jak złożoność koordynowania rozwoju wielu produktów, czym jest mapa technologiczna i jak pomaga usprawniać i powielać rozwiązania, jakie są główne etapy i etapy procesu rozwoju, jakie są obszary odpowiedzialności pomiędzy DevOps a zespołami w naszej firmie.
O chaosie i DevOpsie
W skrócie koncepcja DevOps obejmuje narzędzia i usługi programistyczne, a także metodologie i najlepsze praktyki ich wykorzystania. Wyróżnijmy globalne cel z wdrożenia pomysłów DevOps w naszej firmie: to konsekwentna redukcja kosztów produkcji i utrzymania produktów w ujęciu ilościowym (roboczogodziny lub godziny pracy maszyny, CPU, RAM, Dysk itp.). Najłatwiejszym i najbardziej oczywistym sposobem na obniżenie całkowitego kosztu rozwoju na poziomie całej firmy jest minimalizacja kosztów realizacji typowych zadań seryjnych na wszystkich etapach produkcji. Ale jakie są te etapy, jak je oddzielić od ogólnego procesu, z jakich etapów się składają?
Kiedy firma opracowuje jeden produkt, wszystko jest mniej więcej jasne: zazwyczaj istnieje wspólny plan działania i schemat rozwoju. Co jednak zrobić, gdy asortyment się poszerza i produktów jest więcej? Na pierwszy rzut oka mają podobne procesy i linie montażowe i rozpoczyna się gra „znajdź X różnic” w logach i skryptach. Ale co, jeśli w fazie aktywnego rozwoju jest już ponad 5 projektów i wymagane jest wsparcie dla kilku wersji rozwijanych przez kilka lat? Czy chcemy ponownie wykorzystać maksymalną możliwą liczbę rozwiązań w rurociągach produktowych, czy też jesteśmy gotowi wydać pieniądze na unikalny rozwój każdego z nich?
Jak znaleźć równowagę pomiędzy unikatowością a seryjnymi rozwiązaniami?
Pytania te zaczęły pojawiać się przed nami coraz częściej od 2015 roku. Wzrosła liczba produktów, a my staraliśmy się rozbudować do minimum nasz dział automatyzacji (DevOps), który wspierał linie montażowe tych produktów. Jednocześnie chcieliśmy powielić jak najwięcej rozwiązań pomiędzy produktami. W końcu po co robić to samo w dziesięciu produktach na różne sposoby?
Dyrektor do spraw rozwoju: „Chłopaki, czy możemy w jakiś sposób ocenić, co DevOps robi dla produktów?”
My: „Nie wiemy, nie zadawaliśmy takiego pytania, ale jakie wskaźniki należy wziąć pod uwagę?”
Dyrektor do spraw rozwoju: "Kto wie! Myśleć…"
Jak w tym słynnym filmie: „Jestem w hotelu!..” – „Uh… Czy możesz mi wskazać drogę?” Po namyśle doszliśmy do wniosku, że najpierw trzeba określić końcowy stan produktów; to stało się naszym pierwszym celem.
Jak zatem przeanalizować kilkanaście produktów przy dość dużych zespołach liczących od 10 do 200 osób i określić mierzalne metryki podczas replikacji rozwiązań?
1:0 na korzyść Chaosu, czyli DevOps na łopatkach
Zaczęliśmy od próby zastosowania diagramów IDEF0 i różnych diagramów procesów biznesowych z serii BPwin. Zamieszanie zaczęło się po piątym kwadracie kolejnego etapu kolejnego projektu, a te kwadraty dla każdego projektu można narysować w ogonie długiego pytona poniżej 50 kroków. Zrobiło mi się smutno i chciałam wyć do księżyca – w ogóle to nie pasowało.
Typowe zadania produkcyjne
Modelowanie procesów produkcyjnych to bardzo złożona i żmudna praca: trzeba zebrać, przetworzyć i przeanalizować wiele danych z różnych działów i łańcuchów produkcyjnych. Więcej na ten temat przeczytasz w artykule”".
Kiedy zaczynaliśmy modelować nasz proces produkcyjny, mieliśmy konkretny cel - przekazać każdemu pracownikowi zaangażowanemu w rozwój produktów naszej firmy, a także kierownikom projektów:
- w jaki sposób produkty i ich komponenty, począwszy od zatwierdzenia linii kodu, docierają do klienta w postaci instalatorów i aktualizacji,
- jakie zasoby są zapewnione na każdym etapie wytwarzania produktów,
- jakie usługi są zaangażowane na każdym etapie,
- w jaki sposób wyznaczone są obszary odpowiedzialności na każdym etapie,
- jakie kontrakty istnieją na wejściu i wyjściu z każdego etapu.
Kliknięcie na obrazek otworzy go w pełnym rozmiarze
Nasza praca w firmie jest podzielona na kilka obszarów funkcjonalnych. Kierownictwo infrastruktury zajmuje się optymalizacją działania wszystkich „żelaznych” zasobów działu, a także automatyzacją wdrażania maszyn wirtualnych i środowiska na nich. Kierunek monitorowania zapewnia całodobową kontrolę realizacji usług; monitorujemy również jako usługę dla deweloperów. Kierunek przepływu pracy zapewnia zespołom narzędzia do zarządzania procesami programowania i testowania, analizowania stanu kodu i uzyskiwania analiz dotyczących projektów. I wreszcie kierunek webdev zapewnia publikację wydań na serwerach aktualizacji GUS i FLUS, a także licencjonowanie produktów za pomocą usługi LicenseLab. Aby wesprzeć ciąg produkcyjny, stworzyliśmy i utrzymujemy wiele różnych usług wsparcia dla programistów (o niektórych z nich możesz posłuchać historii na starych spotkaniach: и). Rozwijamy także narzędzia automatyzacji wewnętrznej m.in .
W ciągu ostatnich pięciu lat naszej pracy zgromadziło się wiele tego samego typu i rutynowych operacji, a nasi programiści z innych działów wywodzą się głównie z tzw. typowe zadania, którego rozwiązanie jest w pełni lub częściowo zautomatyzowane, nie sprawia wykonawcom trudności i nie wymaga znacznych nakładów pracy. Wspólnie z wiodącymi obszarami przeanalizowaliśmy takie zadania i udało nam się zidentyfikować poszczególne kategorie prac, czyli etapy produkcjietapy zostały podzielone na niepodzielne etapy, a kilka etapów sumuje się łańcuch procesu produkcyjnego.
Najprostszym przykładem łańcucha technologicznego są etapy montażu, wdrożenia i testowania każdego z naszych produktów w firmie. Z kolei np. etap kompilacji składa się z wielu oddzielnych, typowych kroków: pobrania źródeł z GitLab, przygotowania zależności i bibliotek zewnętrznych, testów jednostkowych i analizy kodu statycznego, wykonania skryptu budującego na GitLab CI, opublikowania artefaktów w repozytorium na Artefakt i generowanie informacji o wydaniu za pomocą naszego wewnętrznego narzędzia ChangelogBuilder.
O typowych zadaniach DevOps możesz przeczytać w innych naszych artykułach na temat Habré: „"A"".
Tworzy się wiele typowych łańcuchów produkcyjnych proces produkcji. Standardowe podejście do opisu procesów polega na wykorzystaniu modeli funkcjonalnych IDEF0.
Przykład modelowania procesu produkcyjnego CI
Szczególną uwagę zwróciliśmy na opracowanie standardowych projektów systemu ciągłej integracji. Umożliwiło to osiągnięcie ujednolicenia projektów, podkreślając tzw wypuść schemat kompilacji z promocjami.
Oto jak to działa. Wszystkie projekty wyglądają typowo: obejmują konfigurację zestawów, które wpadają do repozytorium migawek w Artifactory, po czym są wdrażane i testowane na stanowiskach testowych, a następnie promowane do repozytorium wersji. Usługa Artifactory to pojedynczy punkt dystrybucji wszystkich artefaktów kompilacji pomiędzy zespołami i innymi usługami.
Jeśli znacznie uprościmy i uogólnimy nasz schemat wydawania, będzie on obejmował następujące kroki:
- wieloplatformowy montaż produktów,
- wdrożenie na stanowiska badawcze,
- przeprowadzanie testów funkcjonalnych i innych,
- promowanie przetestowanych kompilacji w celu udostępnienia repozytoriów w Artifactory,
- publikacja kompilacji wydań na serwerach aktualizacji,
- dostawa podzespołów i aktualizacji do produkcji,
- uruchomienie instalacji i aktualizacji produktu.
Rozważmy na przykład model technologiczny tego typowego schematu wydania (zwany dalej po prostu Modelem) w postaci funkcjonalnego modelu IDEF0. Odzwierciedla główne etapy naszego procesu CI. Modele IDEF0 wykorzystują tzw Notacja ICOM (Input-Control-Output-Mechanism) opisujący, jakie zasoby są wykorzystywane na każdym etapie, w oparciu o jakie zasady i wymagania jest wykonywana praca, jaki jest wynik oraz jakie mechanizmy, usługi lub ludzie wdrażają dany etap.
Kliknięcie na obrazek otworzy go w pełnym rozmiarze
Z reguły łatwiej jest rozłożyć i uszczegółowić opis procesów w modelach funkcjonalnych. Jednak w miarę wzrostu liczby elementów coraz trudniej jest coś w nich zrozumieć. Ale w prawdziwym rozwoju istnieją również etapy pomocnicze: monitorowanie, certyfikacja produktów, automatyzacja procesów pracy i inne. To właśnie ze względu na problem skalowania porzuciliśmy ten opis.
Narodziny nadziei
W jednej z książek natknęliśmy się na stare radzieckie mapy opisujące procesy technologiczne (które, notabene, są nadal stosowane w wielu państwowych przedsiębiorstwach i uniwersytetach). Czekaj, czekaj, bo mamy również przepływ pracy!.. Istnieją etapy, wyniki, metryki, wymagania, wskaźniki i tak dalej, i tak dalej… Dlaczego nie spróbować zastosować arkuszy blokowych również do naszych rurociągów produktowych? Pojawiło się uczucie: „To jest to! Znaleźliśmy odpowiedni wątek, czas go dobrze wyciągnąć!
W prostej tabeli postanowiliśmy zapisywać produkty kolumnami, a etapy technologiczne i etapy rurociągu produktów wierszami. Kamienie milowe to coś dużego, na przykład etap tworzenia produktu. Kroki to coś mniejszego i bardziej szczegółowego, na przykład etap pobierania kodu źródłowego na serwer kompilacji lub etap kompilacji kodu.
Na przecięciach rzędów i kolumn mapy wypisujemy statusy dla konkretnego etapu i produktu. Dla statusów zdefiniowano zbiór stanów:
- Brak informacji - lub niewłaściwe. Konieczne jest przeanalizowanie zapotrzebowania na etap w produkcie. Albo analiza została już przeprowadzona, ale etap ten nie jest obecnie potrzebny lub nie jest uzasadniony ekonomicznie.
- Odłożony - lub nieistotne w tej chwili. Potrzebny jest etap w przygotowaniu, ale w tym roku nie ma sił do realizacji.
- Zaplanowany. Realizacja etapu planowana jest w tym roku.
- Realizowany. Etap w rurociągu jest realizowany w wymaganej objętości.
Wypełnianie tabeli rozpoczynano projekt po projekcie. W pierwszej kolejności sklasyfikowano etapy i etapy jednego projektu oraz zarejestrowano ich statusy. Następnie wzięli się za kolejny projekt, poprawili w nim statusy i dodali etapy i kroki, których brakowało w poprzednich projektach. W rezultacie otrzymaliśmy etapy i etapy całego naszego rurociągu produkcyjnego oraz ich statusy w konkretnym projekcie. Okazało się, że jest to coś podobnego do macierzy kompetencji rurociągu produktu. Taką macierz nazwaliśmy mapą technologiczną.
Za pomocą mapy technologicznej rozsądnie metrologicznie koordynujemy z zespołami plany pracy na rok i cele, które chcemy wspólnie osiągnąć: które etapy dodajemy do projektu w tym roku, a które zostawiamy na później. Ponadto w trakcie prac możemy mieć ulepszenia w etapach, które wykonaliśmy tylko dla jednego produktu. Następnie rozszerzamy naszą mapę i wprowadzamy to ulepszenie jako etap lub nowy krok, następnie analizujemy każdy produkt i sprawdzamy wykonalność powtórzenia ulepszenia.
Mogą nam się sprzeciwić: „To wszystko oczywiście dobrze, tylko z czasem liczba kroków i etapów stanie się zaporowo duża. Jak być?
Wprowadziliśmy standardowe i w miarę kompletne opisy wymagań dla każdego etapu i kroku, tak aby były one rozumiane przez wszystkich w firmie w ten sam sposób. Z biegiem czasu, w miarę wprowadzania ulepszeń, dany etap może zostać wchłonięty przez inny etap lub etapy, a następnie „zapadną się”. Jednocześnie wszystkie wymagania i niuanse technologiczne pasują do wymagań etapu lub etapu uogólniania.
Jak ocenić efekt replikacji rozwiązań? Stosujemy niezwykle proste podejście: początkowe koszty kapitałowe wdrożenia nowego etapu przypisujemy do rocznych ogólnych kosztów produktu, a następnie dzielimy przez wszystkie podczas replikacji.
Części inwestycji są już pokazane na mapie jako kamienie milowe i etapy. Możemy wpłynąć na obniżenie kosztu produktu poprzez wprowadzenie automatyzacji typowych etapów. Następnie rozważamy zmiany w cechach jakościowych, metrykach ilościowych i zysku uzyskanym przez zespoły (w roboczogodzinach lub maszynogodzinach oszczędności).
Mapa technologiczna procesu produkcyjnego
Jeśli weźmiemy wszystkie nasze etapy i kroki, zakodujemy je tagami i rozwiniemy w jeden łańcuch, to okaże się to bardzo długie i niezrozumiałe (tylko ten sam „ogon Pythona”, o którym mówiliśmy na początku artykułu) :
[Production] — [InfMonitoring] — [SourceCodeControl] — [Prepare] — [PrepareLinuxDocker] — [PrepareWinDocker] — [Build] — [PullSourceCode] — [PrepareDep] — [UnitTest] — [CodeCoverage] — [StaticAnalyze] — [BuildScenario] — [PushToSnapshot] — [ChangelogBuilder] — [Deploy] — [PrepareTestStand] — [PullTestCode] — [PrepareTestEnv] — [PullArtifact] — [DeployArtifact] — [Test] — [BVTTest] — [SmokeTest] — [FuncTest] — [LoadTest] — [IntegrityTest] — [DeliveryTest] — [MonitoringStands] — [TestManagement] — [Promote] — [QualityTag] — [MoveToRelease] — [License] — [Publish] — [PublishGUSFLUS] — [ControlVisibility] — [Install] — [LicenseActivation] — [RequestUpdates] — [PullUpdates] — [InitUpdates] — [PrepareEnv] — [InstallUpdates] — [Telemetry] — [Workflow] — [Communication] — [Certification] — [CISelfSufficiency]Są to etapy budowania produktów [Buduj], wdrażania ich na serwery testowe [Wdrażaj], testowania [Testuj], promowania kompilacji w celu wydania repozytoriów w oparciu o wyniki testów [Promuj], generowania i publikowania licencji [Licencja], publikowania [ Publish] na serwerze aktualizacji GUS i dostarczanie na serwery aktualizacji FLUS, instalacja i aktualizacja komponentów produktu na infrastrukturze klienta z wykorzystaniem Zarządzania Konfiguracją Produktu [Install], a także zbieranie telemetrii [Telemetry] z zainstalowanych produktów.
Oprócz nich można wyróżnić odrębne etapy: monitorowanie stanu infrastruktury [InfMonitoring], wersjonowanie kodu źródłowego [SourceCodeControl], przygotowanie środowiska kompilacji [Prepare], zarządzanie projektem [Workflow], zapewnienie zespołom narzędzi komunikacyjnych [Komunikacja], certyfikacja produktu [ Certyfikacja] i zapewnienie samowystarczalności procesów IK [CISelfSuffiency] (np. niezależność zgromadzeń od Internetu). Dziesiątki kroków w naszych procesach nawet nie będą brane pod uwagę, ponieważ są one bardzo specyficzne.
Dużo łatwiej będzie zrozumieć i przyjrzeć się całemu procesowi produkcyjnemu, jeśli przedstawimy go w formie mapę technologiczną; jest to tabela, w której w wierszach zapisane są poszczególne etapy produkcji i rozłożone etapy Modelu, a w kolumnach opis czynności wykonywanych na każdym etapie lub etapie. Główny nacisk położony jest na zasoby, które zapewniają każdy etap oraz rozgraniczenie obszarów odpowiedzialności.
Mapa jest dla nas rodzajem klasyfikatora. Odzwierciedla duże technologiczne części produkcji produktów. Dzięki niemu naszemu zespołowi automatyzacji łatwiej było współpracować z programistami i wspólnie planować realizację etapów automatyzacji, a także rozumieć, jakie koszty pracy i zasoby (ludzkie i sprzętowe) będą do tego potrzebne.
Wewnątrz naszej firmy mapa jest automatycznie generowana z szablonu jinja jako zwykły plik HTML, a następnie przesyłana na serwer GitLab Pages. Można wyświetlić zrzut ekranu z przykładem w pełni wygenerowanej mapy .
Kliknięcie na obrazek otworzy go w pełnym rozmiarze
W skrócie mapa technologiczna to uogólniony obraz procesu produkcyjnego, który odzwierciedla jasno sklasyfikowane bloki o typowej funkcjonalności.
Struktura naszej mapy drogowej
Mapa składa się z kilku części:
- Obszar tytułowy - tutaj znajduje się ogólny opis mapy, wprowadzone są podstawowe pojęcia, zdefiniowano główne zasoby i wyniki procesu produkcyjnego.
- Dashboard – tutaj możesz kontrolować sposób wyświetlania danych dla poszczególnych produktów, dostępne jest podsumowanie zrealizowanych etapów oraz ogólnie kroków dla wszystkich produktów.
- Mapa technologiczna - tabelaryczny opis procesu technologicznego. Na mapie:
- podane są wszystkie etapy, kroki i ich kody;
- podano krótkie i pełne opisy etapów;
- wskazane są zasoby wejściowe i usługi wykorzystywane na każdym etapie;
- wskazane są wyniki każdego etapu i oddzielnego etapu;
- wskazany jest obszar odpowiedzialności za każdy etap i krok;
- określono zasoby techniczne takie jak HDD (SSD), RAM, vCPU oraz roboczogodziny niezbędne do obsługi pracy na tym etapie, zarówno w chwili obecnej – fakt, jak i w przyszłości – plan;
- przy każdym produkcie wskazane jest, które etapy lub kroki technologiczne dla niego zostały wdrożone, planowane do wdrożenia, nieistotne lub niezrealizowane.
Podejmowanie decyzji w oparciu o mapę technologiczną
Po zapoznaniu się z mapą możliwe jest podjęcie pewnych działań – w zależności od roli pracownika w firmie (menedżer ds. rozwoju, menadżer produktu, programista lub tester):
- zrozumieć, jakich etapów brakuje w rzeczywistym produkcie lub projekcie i ocenić potrzebę ich wdrożenia;
- wyznaczyć obszary odpowiedzialności pomiędzy kilkoma działami, jeżeli pracują one na różnych etapach;
- uzgadnianie umów przy wejściach i wyjściach ze scen;
- zintegruj swój etap pracy z ogólnym procesem rozwoju;
- dokładniej ocenić zapotrzebowanie na zasoby, które zapewniają każdy z etapów.
Podsumowując wszystkie powyższe
Trasa jest wszechstronna, rozszerzalna i łatwa w utrzymaniu. Dużo łatwiej jest opracować i utrzymać opis procesów w takiej formie, niż w ścisłym akademickim modelu IDEF0. Ponadto opis tabelaryczny jest prostszy, bardziej znajomy i lepiej zorganizowany niż model funkcjonalny.
Do technicznej realizacji etapów posiadamy specjalne narzędzie wewnętrzne CrossBuilder – narzędzie warstwowe pomiędzy systemami CI, usługami i infrastrukturą. Deweloper nie musi przycinać swojego roweru: w naszym systemie CI wystarczy uruchomić jeden ze skryptów (tzw. zadanie) narzędzia CrossBuilder, który wykona je poprawnie, biorąc pod uwagę cechy naszej infrastruktury .
Wyniki
Artykuł okazał się dość długi, ale jest to nieuniknione przy opisywaniu modelowania złożonych procesów. Na koniec chciałbym krótko wyjaśnić nasze główne idee:
- Celem wdrażania pomysłów DevOps w naszej firmie jest konsekwentne obniżanie kosztów produkcji i utrzymania produktów firmy w ujęciu ilościowym (roboczogodziny lub godziny pracy maszyny, vCPU, RAM, Dysk).
- Sposobem na obniżenie całkowitego kosztu rozwoju jest minimalizacja kosztów wykonania typowych zadań seryjnych: etapów i etapów procesu technologicznego.
- Zadanie typowe to zadanie, którego rozwiązanie jest w pełni lub częściowo zautomatyzowane, nie sprawia wykonawcom trudności i nie wymaga znacznych kosztów pracy.
- Proces produkcyjny składa się z etapów, etapy podzielone są na niepodzielne etapy, będące typowymi zadaniami o różnej skali i zakresie.
- Od różnorodnych typowych zadań doszliśmy do złożonych łańcuchów technologicznych i wielopoziomowych modeli procesu produkcyjnego, które można opisać funkcjonalnym modelem IDEF0 lub prostszą mapą technologiczną.
- Mapa technologiczna jest tabelarycznym przedstawieniem etapów i etapów procesu produkcyjnego. Najważniejsze: mapa pozwala zobaczyć cały proces w całości, w dużych fragmentach z możliwością ich uszczegółowienia.
- Na podstawie mapy technologicznej można ocenić potrzebę wprowadzenia etapów w konkretnym produkcie, wyznaczyć obszary odpowiedzialności, uzgodnić kontrakty na wejściach i wyjściach etapów, a także dokładniej ocenić zapotrzebowanie na zasoby.
W kolejnych artykułach opiszemy bardziej szczegółowo, jakie narzędzia techniczne służą do realizacji poszczególnych etapów technologicznych na naszej mapie.
Autorzy artykułu:
- — Szef Automatyzacji (DevOps) w Positive Technologies
- - Zastępca Kierownik Działu Automatyzacji (DevOps) w Positive Technologies
Źródło: www.habr.com