Jako inżynier DevOps pochodzący ze środowiska Operations, przeszedłeś od ręcznego budowania i wdrażania serwerów i oprogramowania do skryptowania instalacji oprogramowania na swoich serwerach, takich jak BASH, PowerShell, Python itp. Po chwili zdasz sobie sprawę, jak fajne skrypty są i zacznij odkrywać bardziej wyrafinowane sposoby automatyzacji wdrażania .
Ostatecznie zdecydowałbyś się na Chef, Puppet, Ansible lub inne narzędzie do zarządzania konfiguracją , aby pomóc zarządzać stanem swojej floty systemów. W miarę dojrzewania twoich umiejętności w zakresie automatyzacji wdrażania aplikacji i zarządzania systemem, wraz z narzędziami, niedawno przeniosłeś się do dziedziny „ Infrastruktura jako kod ” i używasz jej nie tylko do automatyzacji wdrażania oprogramowania, ale także wymaganej infrastruktury i środowisk do kierowania oprogramowaniem podczas przejścia firmy na chmurę.
Teraz gotujesz na gazie. Z czasem poznałeś zalety korzystania z narzędzi programistycznych, takich jak kontrola źródła, do zarządzania modułami, przepisami i szablonami, które tworzą arsenał narzędzi do wdrażania i zarządzania.
Kiedy przeszedłeś do zespołu DevOps , byłeś narażony na cykl życia oprogramowania i koncepcję ciągłej integracji . Chłopcy, ci programiści szybko wprowadzali zmiany i aby nadążyć, znalazłeś się bliżej z twórcami! Doświadczyłeś pilnej potrzeby zespołu programistów, by zmieniać rzeczy przez cały czas, co jest sprzeczne ze starym paradygmatem operacyjnym: „ jeśli to nie jest zepsute, nie naprawiaj go ”. Nigdy więcej chwalenia się przestojem systemu, jesteś w infrastrukturze jednorazowego użytku .
Zauważyłeś, że przejście na DevOps było czymś więcej niż pracą z deweloperami lub użyciem nowych narzędzi i technik , ale w zespole nastąpiła wyraźna zmiana kulturowa , która przeniknęła całą organizację. Pracowałeś jako zgrany zespół o wspólnych obowiązkach , wspólnym oprzyrządowaniu i wspólnych celach .
Wykorzystałeś swoje umiejętności w zakresie automatycznego wdrażania i wmasowałeś je w potok „ CICD ” koordynowany przez „ serwer ciągłej integracji ”, taki jak Jenkins , Bamboo lub Code Pipeline . Teraz, gdy programiści wprowadzają nowy kod, twoje skrypty, narzędzia i szablony stawiają nowe środowiska na żądanie, uruchamiają ramy testowe, aby wykonać swoje zadania i niszczą środowiska przedprodukcyjne po zapaleniu zielonych świateł w wydaniu, zgodnie z pomysły „ ciągłej dostawy ”.
Gdy nowy kod przechodzi przez etapy CICD, Ty, programiści i biznes zyskujesz pewność, że aktualizacja nie ulegnie awarii po wydaniu do produkcji. Jest jeszcze jedna droga, zanim zespół przejdzie do „ ciągłego wdrażania ”, nadal musisz zadecydować o drobniejszych punktach automatyzacji możliwości niebieskiego / zielonego wdrażania, a decyzja jest w większości biznesowa. Na razie jesteś zadowolony, że liczba połączeń o 3 nad ranem zmniejszyła się, a liczba sev-1 i sev-2 maleje.
Nawet jeśli dostaniesz sev-1, nie będziesz już ciągnął przez całą noc, a menedżerowie oddychają ci plecami - możesz łatwo wydać poprzednią wersję za pośrednictwem rurociągu CICD i ponownie uruchomić system w krótkim czasie. Firma zauważyła, że stabilność systemów informatycznych poprawiła się pomimo szybkości zmian .
Dziwisz się sposobem zarządzania zasobami potrzebnymi do napędzania oprogramowania w Twojej firmie, zwłaszcza gdy myślisz o tym, jak to było kiedyś i ile krwi pozostawiłeś na szynach w centrum danych ...
