Środowisko wdrożeniowe - Deployment environment

W rozmieszczania oprogramowania , w środowisku , lub kondygnacja to system komputerowy lub zestaw układów, w których program komputerowy lub składnik oprogramowania jest wdrożonych i realizowanych. W prostych przypadkach, takich jak tworzenie i natychmiastowe wykonanie programu na tej samej maszynie, może istnieć jedno środowisko, ale w zastosowaniach przemysłowych środowisko programistyczne (w którym wprowadzane są pierwotnie zmiany) i środowisko produkcyjne (z jakiego korzystają użytkownicy końcowi) są oddzielone , często z kilkoma etapami pomiędzy. Ten ustrukturyzowany proces zarządzania wersjami umożliwia stopniowe wdrażanie (wdrażanie), testowanie i wycofywanie w przypadku problemów.

Środowiska mogą znacznie różnić się rozmiarem: środowisko programistyczne to zwykle stacja robocza indywidualnego programisty, podczas gdy środowisko produkcyjne może być siecią wielu rozproszonych geograficznie maszyn w centrach danych lub maszynami wirtualnymi w chmurze obliczeniowej . Kod, dane i konfiguracja mogą być wdrażane równolegle i nie muszą łączyć się z odpowiednią warstwą - na przykład kod przedprodukcyjny może łączyć się z produkcyjną bazą danych.

Architektury

Architektury wdrożeniowe znacznie się różnią, ale ogólnie warstwy są zaksięgowane, zaczynając od rozwoju (DEV), a kończąc na produkcji (PROD). Typowa 4-warstwowa architektura to programowanie, testowanie, modelowanie, produkcja (DEV, TEST, MODL, PROD), przy czym oprogramowanie jest wdrażane po kolei. Inne typowe środowiska obejmują kontrolę jakości (QC) do testów akceptacyjnych ; piaskownica lub eksperymentalna (EXP), do eksperymentów, które nie są przeznaczone do produkcji; i Disaster Recovery, aby zapewnić natychmiastową pomoc w przypadku problemów z produkcją. Inną popularną architekturą jest programowanie, testowanie, akceptacja i produkcja (DTAP).

Ten język jest szczególnie odpowiedni dla programów serwerowych, gdzie serwery działają w zdalnym centrum danych; w przypadku kodu działającego na urządzeniu użytkownika końcowego, takim jak aplikacje (aplikacje) lub klienci, można zamiast tego odwołać się do środowiska użytkownika (USER) lub środowiska lokalnego (LOCAL).

Dokładne definicje i granice między środowiskami są różne - test można uznać za część deweloperską, akceptację można uznać za część testu, część etapu lub być oddzielnym itd. Główne poziomy są przechodzące w kolejności, a nowe wersje są wdrażane ( rolowane się lub popchnął ) do każdego po kolei. Warstwy eksperymentalna i odzyskiwania, jeśli istnieją, znajdują się poza tym przepływem - wersje eksperymentalne są terminalowe, podczas gdy odzyskiwanie jest zwykle starą lub zduplikowaną wersją produkcji, wdrażaną po produkcji. W przypadku problemów można wrócić do starej wersji, najprościej przez wypchnięcie starej wersji tak, jakby była nową wersją. Ostatni krok, czyli wdrożenie do produkcji („push to prod”), jest najbardziej wrażliwy, ponieważ wszelkie problemy powodują natychmiastowy wpływ na użytkowników. Z tego powodu jest to często obsługiwane w inny sposób, przynajmniej uważniej monitorowane, aw niektórych przypadkach z etapowym wdrażaniem lub wymagającym jedynie przestawienia przełącznika, co umożliwia szybkie wycofanie. Najlepiej unikać takich nazw jak Quality Assurance (QA); Kontrola jakości nie oznacza testowania oprogramowania. Testowanie jest ważne, ale różni się od kontroli jakości.

Czasami wdrażanie odbywa się poza tym zwykłym procesem, głównie w celu zapewnienia pilnych lub stosunkowo niewielkich zmian, bez konieczności pełnego wydania. Może się składać z pojedynczej poprawki , dużego dodatku Service Pack lub małej poprawki .

Środowiska mogą mieć bardzo różne rozmiary: programowanie jest zwykle stacją roboczą indywidualnego programisty (chociaż mogą być tysiące programistów), podczas gdy produkcja może obejmować wiele maszyn rozproszonych geograficznie; test i QC mogą być małe lub duże, w zależności od poświęconych im zasobów, a etapy mogą obejmować od pojedynczej maszyny (podobnej do kanarka) do dokładnego duplikatu produkcji.

Środowiska

Poniższa tabela przedstawia szczegółowo podzieloną listę poziomów.

Nazwa środowiska / poziomu Opis
Lokalny Pulpit / stacja robocza programisty
Rozwój / Trunk Serwer deweloperski pełniący rolę piaskownicy, na której deweloper może przeprowadzać testy jednostkowe
Integracja Cel kompilacji CI lub testowanie przez deweloperów skutków ubocznych
Testowanie / Test / QC / Akceptacja wewnętrzna Środowisko, w którym przeprowadzane są testy interfejsu. Zespół kontroli jakości zapewnia, że ​​nowy kod nie będzie miał żadnego wpływu na istniejącą funkcjonalność i testuje główne funkcjonalności systemu po wdrożeniu nowego kodu w środowisku testowym.
Inscenizacja / Etap / Model / Przedprodukcja / Akceptacja klienta zewnętrznego / Demo Lustro środowiska produkcyjnego
Produkcja / na żywo Obsługuje użytkowników końcowych / klientów

Rozwój

Środowisko programistyczne (dev) to środowisko, w którym opracowywane są zmiany w oprogramowaniu, a najprościej jest to indywidualna stacja robocza programisty. Różni się to od ostatecznego środowiska docelowego na różne sposoby - celem może nie być komputer stacjonarny (może to być smartfon, system wbudowany, maszyna bezgłowa w centrum danych itp.), A nawet jeśli w inny sposób będzie podobne, środowisko programisty będzie obejmują narzędzia programistyczne, takie jak kompilator, zintegrowane środowisko programistyczne, różne lub dodatkowe wersje bibliotek i oprogramowania pomocniczego itp., których nie ma w środowisku użytkownika.

W kontekście kontroli wersji , szczególnie w przypadku wielu programistów, rysuje się drobniejsze rozróżnienia: programista ma działającą kopię kodu źródłowego na swoim komputerze, a zmiany są przesyłane do repozytorium, zatwierdzane do linii głównej lub oddziału, w zależności od metodologia rozwoju. Środowisko na pojedynczej stacji roboczej, w którym zmiany są opracowywane i wypróbowywane, można nazwać środowiskiem lokalnym lub piaskownicą . Budowanie kopii kodu źródłowego repozytorium w czystym środowisku to osobny krok, część integracji (integrująca odmienne zmiany), a to środowisko można nazwać środowiskiem integracyjnym lub środowiskiem programistycznym ; w ciągłej integracji robi się to często, tak często, jak przy każdej rewizji. Koncepcja na poziomie kodu źródłowego polegająca na „zatwierdzeniu zmiany w repozytorium”, po której następuje zbudowanie linii głównej lub gałęzi, odpowiada wypychaniu do wydania z lokalnego (środowisko programisty) do integracji (czysta kompilacja); zła wersja na tym etapie oznacza, że ​​zmiana zepsuła kompilację, a wycofanie wersji odpowiada albo wycofaniu wszystkich zmian od tego momentu, albo cofnięciu tylko zmiany, która jest krytyczna, jeśli to możliwe.

Testowanie

Celem środowiska testowego jest umożliwienie testerom testowym wykonywania nowego i zmienionego kodu za pomocą automatycznych kontroli lub technik niezautomatyzowanych. Po zaakceptowaniu przez programistę nowego kodu i konfiguracji za pomocą testów jednostkowych w środowisku programistycznym elementy są przenoszone do co najmniej jednego środowiska testowego. W przypadku niepowodzenia testu środowisko testowe może usunąć wadliwy kod z platform testowych, skontaktować się z odpowiedzialnym programistą i dostarczyć szczegółowe dzienniki testów i wyników. Jeśli wszystkie testy przejdą pomyślnie, środowisko testowe lub platforma ciągłej integracji kontrolująca testy mogą automatycznie promować kod do następnego środowiska wdrażania.

Różne typy testów sugerują różne typy środowisk testowych, z których część lub wszystkie mogą być zwirtualizowane, aby umożliwić szybkie, równoległe testowanie. Na przykład zautomatyzowane testy interfejsu użytkownika mogą wystąpić w kilku wirtualnych systemach operacyjnych i wyświetlaczach (rzeczywistych lub wirtualnych). Testy wydajności mogą wymagać znormalizowanej fizycznej podstawowej konfiguracji sprzętowej, aby wyniki testów wydajności można było porównywać w czasie. Testowanie dostępności lub trwałości może zależeć od symulatorów awarii w sprzęcie wirtualnym i sieciach wirtualnych.

Testy mogą być seryjne (jeden po drugim) lub równoległe (niektóre lub wszystkie naraz), w zależności od stopnia zaawansowania środowiska testowego. Istotnym celem zwinnych i innych wysokowydajnych praktyk tworzenia oprogramowania jest skrócenie czasu od zaprojektowania lub specyfikacji oprogramowania do dostarczenia go do produkcji. Wysoce zautomatyzowane i zrównoleglone środowiska testowe są ważnymi czynnikami przyczyniającymi się do szybkiego tworzenia oprogramowania.

Inscenizacja

Środowisko etapowe, pomostowe lub przedprodukcyjne to środowisko do testowania, które dokładnie przypomina środowisko produkcyjne. Stara się jak najdokładniej odzwierciedlać rzeczywiste środowisko produkcyjne i może łączyć się z innymi usługami produkcyjnymi i danymi, takimi jak bazy danych. Na przykład serwery będą uruchamiane na zdalnych maszynach, a nie lokalnie (jak na stacji roboczej programisty podczas tworzenia lub na pojedynczej maszynie testowej podczas testu), co testuje wpływ sieci na system.

Podstawowym zastosowaniem środowiska pomostowego jest przetestowanie wszystkich skryptów i procedur instalacji / konfiguracji / migracji, zanim zostaną one zastosowane w środowisku produkcyjnym. Dzięki temu wszystkie większe i mniejsze aktualizacje środowiska produkcyjnego są wykonywane niezawodnie, bez błędów i w jak najkrótszym czasie.

Innym ważnym zastosowaniem przemieszczania jest testowanie wydajności , zwłaszcza testowanie obciążenia , ponieważ jest to często wrażliwe na środowisko.

Niektóre organizacje używają również etapów w celu zapoznania się z nowymi funkcjami w celu wybrania klientów lub sprawdzenia poprawności integracji z aktywnymi wersjami zależności zewnętrznych.

Produkcja

Środowisko produkcyjne jest również znane jako środowisko na żywo , szczególnie w przypadku serwerów, ponieważ jest to środowisko, z którym użytkownicy bezpośrednio wchodzą w interakcje.

Wdrażanie do produkcji jest najbardziej wrażliwym krokiem; można to zrobić, wdrażając nowy kod bezpośrednio (nadpisując stary kod, tak aby w danym momencie była tylko jedna kopia) lub wdrażając zmianę konfiguracji. Może to przybierać różne formy: wdrażanie równoległej instalacji nowej wersji kodu i przełączanie się między nimi przy zmianie konfiguracji; wdrażanie nowej wersji kodu ze starym zachowaniem i flagą funkcji oraz przełączanie się na nowe zachowanie ze zmianą konfiguracji, która powoduje odwrócenie flagi; lub wdrażając oddzielne serwery (jeden ze starym kodem, drugi nowy) i przekierowując ruch ze starego na nowy ze zmianą konfiguracji na poziomie routingu ruchu. Te z kolei mogą być wykonywane od razu lub stopniowo, w fazach.

Wdrażanie nowej wersji zwykle wymaga ponownego uruchomienia, chyba że wymiana na gorąco jest możliwa, a zatem wymaga przerwy w działaniu usługi (zwykle w przypadku oprogramowania użytkownika, w którym aplikacje są ponownie uruchamiane) lub nadmiarowości - albo powolne ponowne uruchamianie wystąpień za modułem równoważenia obciążenia, albo uruchomienie nowe serwery z wyprzedzeniem, a następnie po prostu przekierowując ruch na nowe serwery.

Podczas wdrażania nowej wersji do produkcji, zamiast natychmiastowego wdrażania we wszystkich instancjach lub użytkownikach, można ją najpierw wdrożyć na pojedynczej instancji lub ułamku użytkowników, a następnie wdrożyć u wszystkich lub stopniowo wdrażać etapami, aby złapać ostatnie -minute problemy. Jest to podobne do postoju, z wyjątkiem faktycznego wykonania w produkcji, i jest określane jako uwolnienie kanarkowe , przez analogię z wydobyciem węgla. Zwiększa to złożoność ze względu na jednoczesne uruchamianie wielu wersji i dlatego zwykle kończy się szybko, aby uniknąć problemów ze zgodnością.

Integracja ram

Programowanie, przemieszczanie i produkcja to znane i udokumentowane zmienne środowiskowe w ASP.NET Core . W zależności od zdefiniowanej zmiennej wykonywany jest inny kod i renderowana zawartość, a także stosowane są różne ustawienia zabezpieczeń i debugowania.

Zobacz też

Bibliografia