Udostępnij za pośrednictwem

Zwiększanie możliwości wdrażania za pomocą wynalazków cyfrowych

  • Artykuł

Ostatecznym testem innowacji jest reakcja klientów na wynalazek. Czy hipoteza okazała się prawdziwa? Czy klienci korzystają z rozwiązania? Czy jest skalowana w celu zaspokojenia potrzeb żądanego procentu użytkowników? Co najważniejsze, czy wracają? Żadne z tych pytań nie może być zadawane, dopóki nie wdrożono rozwiązania MVP (minimum realable product).

W tym artykule skupimy się na wspieraniu wdrażania za pomocą narzędzi potoku ciągłej integracji i ciągłego wdrażania (CI/CD). Ciągła integracja to automatyzowanie kodu wiele razy dziennie w celu zaktualizowania pojedynczego projektu. Ciągłe wdrażanie to automatyczne dostarczanie tych funkcji przez cały dzień.

Zmniejsz tarcie ciągłej integracji/ciągłego wdrażania, które wpływa na wdrożenie

Niektóre przeszkody w wdrożeniu można zminimalizować za pomocą kombinacji technologii i procesów. W przypadku czytelników z wiedzą na temat procesów ciągłej integracji/ciągłego wdrażania lub metodyki DevOps następujące procesy potoku ciągłej integracji/ciągłego wdrażania będą znane. W tym artykule opisano punkt wyjścia dla zespołów ds. wdrażania chmury, które napędzają innowacje i pętle opinii. Ten punkt wyjścia może sprzyjać bardziej niezawodnej integracji/ciągłego wdrażania lub metodyki DevOps, ponieważ produkty i zespoły dojrzały.

Zgodnie z opisem w sekcji Miara wpływu na klienta pozytywna walidacja każdej hipotezy wymaga iteracji i determinacji. Ten artykuł dotyczący ciągłej integracji/ciągłego wdrażania ma na celu zminimalizowanie skoków technicznych , które spowalniają innowacje, jednocześnie upewniając się, że najlepsze rozwiązania są spełnione. Pomoże to zespołowi w projektowaniu przyszłych sukcesów przy jednoczesnym dostarczaniu bieżących potrzeb klientów.

Zwiększanie możliwości wdrażania i wynalazków cyfrowych: model dojrzałości

Głównym celem metodologii innowacji jest budowanie partnerstwa klientów i przyspieszanie pętli opinii, co prowadzi do innowacji rynkowych. Na poniższej ilustracji i sekcjach opisano początkowe implementacje, które obsługują tę metodologię.

Diagram przedstawiający model dojrzałości wdrożenia.

Aby zminimalizować wzrosty techniczne, załóżmy, że dojrzałość początkowo będzie niska w ramach tych zasad. Zaplanuj z wyprzedzeniem, dostosowując się do narzędzi i procesów, które mogą być skalowane, ponieważ hipotezy stają się bardziej szczegółowe. Na platformie Azure usługi GitHub i Azure DevOps umożliwiają małym zespołom rozpoczęcie pracy z niewielkimi tarciami. Te zespoły mogą rosnąć, aby obejmować tysiące deweloperów, którzy współpracują nad rozwiązaniami skalowania i testować setki hipotez klientów. W pozostałej części tego artykułu przedstawiono podejście "plan big, start small" w celu umożliwienia wdrażania w ramach tych zasad.

Rozwiązanie udostępnione

Zgodnie z opisem w sekcji Miara wpływu na klienta pozytywna walidacja każdej hipotezy wymaga iteracji i determinacji. Będziesz doświadczać znacznie większej liczby niepowodzeń niż zwycięstwa w każdym cyklu innowacji. Jest to oczekiwane zachowanie. Jednak gdy klient potrzebuje, hipoteza i rozwiązanie są dopasowane na dużą skalę, świat szybko się zmienia.

Podczas skalowania wynalazków cyfrowych i innowacji nie ma bardziej cennego narzędzia niż wspólna baza kodu dla rozwiązania. Niestety, nie ma wiarygodnego sposobu przewidywania, która iteracja lub który MVP przyniesie zwycięską kombinację. Dlatego nigdy nie jest zbyt wcześnie, aby ustanowić udostępnioną bazę kodu lub repozytorium. Jest to jeden skok techniczny , który nie powinien być opóźniony. Ponieważ zespół iteruje różne rozwiązania MVP, wspólne repozytorium umożliwia łatwą współpracę i przyspieszony rozwój. Gdy zmiany w rozwiązaniu przeciągnią metryki uczenia w dół, kontrola wersji umożliwia powrót do wcześniejszej, bardziej efektywnej wersji rozwiązania.

Najbardziej powszechnie przyjęte narzędzie ciągłej integracji/ciągłego wdrażania do zarządzania repozytoriami kodu to GitHub, które umożliwia utworzenie udostępnionego repozytorium kodu w zaledwie kilku krokach. Ponadto funkcja Azure Repos usługi Azure DevOps może służyć do tworzenia repozytorium Git lub TFVC.

Cykle wymiany opinii

Tworzenie części rozwiązania przez klienta jest kluczem do budowania partnerstwa klientów podczas cykli innowacji. Jest to realizowane częściowo przez pomiar wpływu klienta. Wymaga to konwersacji i bezpośredniego testowania z klientem. Obie generują opinie, które muszą być skutecznie zarządzane.

Każdy punkt opinii jest potencjalnym rozwiązaniem dla potrzeb klienta. Co ważniejsze, każda część bezpośrednich opinii klientów stanowi okazję do poprawy partnerstwa. Jeśli opinie sprawiają, że jest to rozwiązanie MVP, świętuj to z klientem. Nawet jeśli niektóre opinie nie są możliwe do działania, po prostu jest przezroczyste z decyzją o deprioritize opinii demonstruje nastawienie na rozwój i skupienie się na ciągłym uczeniu się.

Usługa Azure DevOps obejmuje sposoby żądania, przekazywania opinii i zarządzania nimi. Te narzędzia scentralizuje opinie, aby zespół mógł podjąć działania i zapewnić kontynuację pętli przezroczystej opinii.

Ciągła integracja

Ciągła integracja to automatyzowanie kodu wiele razy dziennie w celu zaktualizowania pojedynczego projektu. W miarę zwiększania skali wdrażania i hipotezy zbliża się do prawdziwych innowacji na dużą skalę, liczba mniejszych hipotez, które mają być testowane, ma tendencję do szybkiego wzrostu. W przypadku dokładnych pętli opinii i płynnych procesów wdrażania ważne jest, aby te hipotezy były zintegrowane i wspierały podstawową hipotezę za innowacjami. Wymaga to szybkiego przejścia do innowacji i rozwoju, co wymaga wielu deweloperów do testowania odmian hipotezy podstawowej. W przypadku późniejszych prac programistycznych może być nawet potrzebnych wielu zespołom deweloperów, z których każdy tworzy się w kierunku udostępnionego rozwiązania. Ciągła integracja to pierwszy krok w kierunku zarządzania wszystkimi ruchomymi częściami.

W ciągłej integracji zmiany kodu są często scalane z gałęzią główną. Zautomatyzowane procesy kompilacji i testowania zapewniają, że kod w gałęzi głównej jest zawsze jakością produkcyjną. Dzięki temu deweloperzy współpracują ze sobą w celu opracowania udostępnionych rozwiązań zapewniających dokładne i niezawodne pętle opinii.

Usługi Azure DevOps i Azure Pipelines zapewniają możliwości ciągłej integracji, wykonując kilka kroków w usłudze GitHub lub innych repozytoriach. Aby uzyskać więcej informacji, zobacz Co to jest ciągła integracja? lub wypróbuj praktyczne laboratorium ciągłej integracji. Dostępne są architektury rozwiązań, które mogą przyspieszyć tworzenie potoków ciągłej integracji/ciągłego wdrażania za pośrednictwem usługi Azure DevOps.

Niezawodne testowanie

Wady w dowolnym rozwiązaniu mogą tworzyć fałszywie dodatnie lub fałszywie ujemne. Nieoczekiwane błędy mogą łatwo prowadzić do błędnej interpretacji metryk wdrażania użytkowników. Mogą również generować negatywne opinie od klientów, którzy nie dokładnie reprezentują testu hipotezy.

Podczas wczesnych iteracji rozwiązania MVP oczekiwane są wady. Wczesni adopcy mogą nawet znaleźć ich ujmujące. We wczesnych wersjach testowanie akceptacyjne zwykle nie istnieje. Jednak jeden aspekt budowania z empatią dotyczy weryfikacji potrzeby i hipotezy. Oba te testy można wykonać przy użyciu testów jednostkowych na poziomie kodu i ręcznych testów akceptacyjnych przed wdrożeniem. Razem zapewniają one pewne środki niezawodności podczas testowania. Należy spróbować zautomatyzować dobrze zdefiniowaną serię testów kompilacji, jednostki i akceptacji. Zapewnią one niezawodne metryki związane z bardziej precyzyjnymi ulepszeniami hipotezy i wynikowego rozwiązania.

Funkcja Azure Test Plans zapewnia narzędzia do tworzenia i obsługi planów testów podczas ręcznego lub zautomatyzowanego wykonywania testów.

Wdrażanie rozwiązania

Być może najbardziej znaczącym aspektem zwiększania możliwości wdrażania jest możliwość kontrolowania wydania rozwiązania dla klientów. Udostępniając samoobsługowy lub zautomatyzowany potok do wydawania rozwiązania klientom, przyspieszysz pętlę opinii. Dzięki umożliwieniu klientom szybkiej interakcji ze zmianami w rozwiązaniu należy zaprosić ich do tego procesu. Takie podejście powoduje również szybsze testowanie hipotez, zmniejszenie założeń i potencjalnej pracy.

Istnieje kilka metod wdrażania rozwiązań. Trzy najczęściej spotykane są następujące elementy:

  • Ciągłe wdrażanie jest najbardziej zaawansowaną metodą, ponieważ automatycznie wdraża zmiany kodu w środowisku produkcyjnym. W przypadku dojrzałych zespołów, które testują dojrzałe hipotezy, ciągłe wdrażanie może być niezwykle cenne.
  • We wczesnych etapach rozwoju ciągłe dostarczanie może być bardziej odpowiednie. W ciągłym dostarczaniu wszystkie zmiany kodu są automatycznie wdrażane w środowisku przypominającym środowisko produkcyjne. Deweloperzy, osoby podejmujące decyzje biznesowe i inni członkowie zespołu mogą używać tego środowiska do sprawdzania, czy ich praca jest gotowa do produkcji. Możesz również użyć tej metody do przetestowania hipotezy z klientami bez wpływu na bieżące działania biznesowe.
  • Wdrażanie ręczne to najmniej zaawansowane podejście do zarządzania wydaniami. Jak sugeruje nazwa, ktoś w zespole ręcznie wdraża najnowsze zmiany kodu. Takie podejście jest podatne na błędy, zawodne i uważane za antywzorzec przez większości doświadczonych inżynierów.

Podczas pierwszej iteracji rozwiązania MVP wdrożenie ręczne jest powszechne, pomimo poprzedniej oceny. Gdy rozwiązanie jest bardzo płynne, a opinie klientów są nieznane, istnieje znaczne ryzyko zresetowania całego rozwiązania (a nawet podstawowej hipotezy). Oto ogólna reguła wdrażania ręcznego: brak weryfikacji klienta, brak automatyzacji wdrażania.

Inwestowanie wcześnie może prowadzić do straconego czasu. Co ważniejsze, może tworzyć zależności od potoku wydania, dzięki czemu zespół będzie bardziej odporny na wczesny element przestawny. Po kilku pierwszych iteracji lub gdy opinie klientów sugerują potencjalny sukces, należy szybko przyjąć bardziej zaawansowany model wdrażania.

Na dowolnym etapie weryfikacji hipotez usługi Azure DevOps i Azure Pipelines zapewniają ciągłe dostarczanie i ciągłe wdrażanie. Dowiedz się więcej na temat ciągłego dostarczania lub zapoznaj się z laboratorium praktycznym. Architektura rozwiązania może również przyspieszyć tworzenie potoków ciągłej integracji/ciągłego wdrażania za pośrednictwem usługi Azure DevOps.

Pomiary zintegrowane

Podczas mierzenia wpływu na klienta ważne jest, aby zrozumieć, jak klienci reagują na zmiany w rozwiązaniu. Te dane, znane jako dane telemetryczne, zapewniają wgląd w akcje podejmowane przez użytkownika (lub kohortę użytkowników) podczas pracy z rozwiązaniem. Z tych danych łatwo jest uzyskać weryfikację ilościową hipotezy. Te metryki mogą następnie służyć do dostosowywania rozwiązania i generowania bardziej precyzyjnych hipotez. Te subtelniejsze zmiany pomagają w dojrzałym początkowym rozwiązaniu w kolejnych iteracjach, ostatecznie prowadząc do powtarzania wdrażania na dużą skalę.

Na platformie Azure usługa Azure Monitor udostępnia narzędzia i interfejs do zbierania i przeglądania danych ze środowisk klientów. Te obserwacje i szczegółowe informacje można zastosować, aby uściślić listę prac przy użyciu Azure Boards.

Następne kroki

Po zapoznaniu się z narzędziami potoku ciągłej integracji/ciągłego wdrażania i procesami potrzebnymi do zwiększenia możliwości wdrażania nadszedł czas, aby przeanalizować bardziej zaawansowaną dyscyplinę innowacji: interakcję z urządzeniami. Ta dyscyplina może pomóc zmniejszyć bariery między środowiskami fizycznymi i cyfrowymi, co jeszcze ułatwi wdrożenie rozwiązania.

Interakcja z urządzeniami