Rozwój, szybko i powoli

Dostosowywanie praktyk rozwojowych do zdecentralizowanego świata

W 2001 roku Philip, jeden z naszych programistów, był u klienta, aby zainstalować oprogramowanie swojej firmy, gdy baza danych Oracle uległa awarii. Kilka odwołanych lotów później spędził dodatkowe 2 dni pracując jako DBA, aby odzyskać ich bazę produkcyjną dla nich. Przez 14 godzin był na jednym wezwaniu do Indii, Anglii i Kalifornii — non-stop. Dopiero potem mógł rozpocząć instalację. Gdy już skończył, dowiedział się tylko o jego użyciu i wszelkich problemach, jakie mogą mieć Użytkownicy, gdyby jego klient zadzwonił do niego, aby dać mu znać.

Kilka lat później, w 2010 roku, byłem gotowy do wydania kilku nowych funkcji na stronie, nad którą pracowałem. Włączyłem baner strony, aby wskazać, że wprowadzamy nowe zmiany. 5 minut później wszedłem na serwer i uruchomiłem scripts/deploy.sh. 30 sekund później, nowe funkcje były uruchomione i nasi użytkownicy dali nam swoje przemyślenia. Złapali też pluskwę … godzinę później zrobiłem ten sam taniec, i to zostało naprawione.

Przyspieszenie

Inżynieria oprogramowania jako dyscyplina zmieniła się drastycznie w ciągu ostatnich 20 lat. Najnowsza era rozwoju charakteryzuje się ciągłym wdrażaniem, z którego korzystają firmy takie jak Facebook i GitHub, aby wdrażać zmiany w swoich witrynach dziesiątki razy dziennie. Procesy te sprawiają, że wdrażanie jest szybkie i umożliwiają przenoszenie podzbiorów funkcjonalności do różnych grup użytkowników. Efekt końcowy: pojawiające się błędy są zazwyczaj ograniczone do kilku osób i są stosunkowo małe, ponieważ rozwój może nastąpić bardzo stopniowo. Są łatwe do naprawienia, niewielu ludzi je widzi i zostają złapani wcześniej.

Jednym z częstych skutków ubocznych tych łatwych poprawek jest to, co można nazwać niechlujnym procesem rozwoju. W miarę jak narzędzia w chmurze stały się bardziej powszechne, a ciągła integracja i wdrażanie stały się bardziej dostępne, sztywne Schematy testowania jakości stały się znacznie mniej powszechne, szczególnie w mniejszych, wcześniejszych zespołach etapowych. Zamiast rozważać funkcję gotową do wdrożenia, gdy zostanie ona w pełni zweryfikowana, te małe zespoły przestawiły się na akceptację błędów, ponieważ ich poprawki można szybko wdrożyć. Pozwoliło to na nieprzerwaną produktywność, a w połączeniu z odpowiednim ustalaniem priorytetów nowych błędów, było świetnym sposobem na utrzymanie tempa rozwoju i nadal mieć produkt, który działa dobrze.

Wiele ciągłego rozwoju istnieje ze względu na ścisłą, zautomatyzowaną kontrolę nad pełnym stosem narzędzi i infrastruktury organizacji: narzędzie czatu może rozmawiać z serwerem CI, który może uruchomić kompilację, a następnie wdrożyć na kilku serwerach w infrastrukturze organizacji. Ruch przychodzący przechodzi przez skonfigurowane reguły, które kierują niektórych użytkowników do określonych serwerów. Wdrożony kod przekazuje dane telemetryczne, które można wykorzystać do szybkiego wykrycia nieprawidłowego wdrożenia i wycofania go, automatycznie lub ręcznie. Wszystkie te rzeczy są proste, ponieważ organizacje te uruchamiają własne systemy, kontrolują kod i konfigurację, które istnieją w każdym systemie, i otrzymują pełną telemetrię ze wszystkich działających maszyn lub maszyn wirtualnych w swojej infrastrukturze.

Decentralizacja

Wejdź do zdecentralizowanych sieci. Sieci zdecentralizowane charakteryzują się przeciwieństwem kontroli: organizacja deweloperska, która wdraża odpowiednio zdecentralizowaną sieć, kontroluje co najwyżej ułamek węzłów w całej sieci. Władza wraca do ludzi, ale to oznacza, że infrastruktura jest również w rękach ludzi. Gdy wszystkie osoby obsługujące wiele węzłów sieci są niezależnymi podmiotami, znacznie trudniej jest skoordynować wdrożenie. Odpowiednio zaprojektowana zdecentralizowana sieć szanuje prywatność osób korzystających z węzłów w sieci, więc telemetria jest dobrowolna, co oznacza, że duża część sieci może w ogóle nie dostarczać telemetrii programistom.

Nagle zauważenie błędu, który wpływa na podzbiór użytkowników jest znacznie trudniejsze. Nawet jeśli błąd zostanie zauważony, wypchnięcie poprawki do wszystkich jest skomplikowane. W pewnym sensie powróciliśmy do pierwszego wątku w naszym poście: instalowanie kodu w cudzym systemie, a następnie pozostawienie go bez możliwości zdalnej aktualizacji. Wiemy, jakie są skutki tych ograniczeń: błędy, które pozwalają złemu aktorowi ukraść miliony dolarów w ETH; błędy, które sprawiają, że miliony są bardziej niedostępne; próby obejścia wymagań decentralizacji poprzez centralizację podstawowych usług. W rzadkich przypadkach duża społeczność może zebrać się, aby naprawić szkody, ale zarówno ze względów koordynacyjnych, jak i ideologicznych, może to być dość trudne do wykonania.

Przeszłość, Teraźniejszość, Poznaj Przyszłość

Jak więc zdecentralizowani deweloperzy powinni radzić sobie z tą dostosowaną rzeczywistością? Czy odrzucamy wszystkie korzyści wynikające z wprowadzenia ciągłego wdrażania, czy też istnieje kompromis? Wierzymy, że istnieje wiele skutecznych praktyk z przeszłości, które można ponieść na trudności zdecentralizowanego rozwoju. W połączeniu z konkretnymi lekcjami płynącymi z ciągłego dostarczania, możemy zrealizować wiele naszych celów jako programiści nawet w zdecentralizowanym świecie, zachowując bezpieczeństwo i bezpieczeństwo potrzebne użytkownikom zdecentralizowanych systemów.

Wewnętrzne sieci testowe mogą pozwolić na ograniczoną formę eksperymentów na nowych iteracjach. Te sieci testowe mogą symulować awarie węzłów, wspólne transakcje i wiele innych aspektów rzeczywistych sytuacji, aby zapewnić wysoki poziom bezpieczeństwa dla wydajności i odporności sieci. Niestety, nie da się całkowicie symulować realnego świata, więc sieci testowe mogą nas przenieść tylko do tej pory — w końcu trzeba wysłać.

Projekty, które polegają na ciągłej dostawie, mogą dostarczyć niedoskonały i niekompletny minimalny opłacalny produkt i iterację na nim bardzo szybko po opublikowaniu; zdecentralizowany projekt, z drugiej strony, musi bardziej uważać, że jego początkowa wersja jest dopracowana, szczególnie z punktu widzenia bezpieczeństwa. Nie wyklucza to minimalnego zestawu funkcji — w rzeczywistości podejście MVP polegające na wyborze kilku funkcji do uruchomienia jest prawdopodobnie ważniejsze! Gdy koszty początkowe są wyższe, uruchomienie z mniejszą ilością, aby uzyskać możliwość przetestowania podstawowych filozofii w środowisku naturalnym, jest jeszcze ważniejsze.

Entuzjastyczna społeczność to również świetny sposób na uzyskanie wielu korzyści płynących z scentralizowanej infrastruktury: podekscytowani operatorzy węzłów chętnie wypróbują nowe wersje i aktywnie udzielą opinii. Wraz z rozwojem społeczności, większe zaangażowanie przekłada się na większą łatwość wdrażania. Zarządzanie społecznościami staje się tym bardziej ważne, że społeczność, która ufa deweloperom, będzie chętniej współpracować z nimi w celu wdrożenia nowych zmian i zmniejszenia różnicy między infrastrukturą samoobsługową a infrastrukturą obsługiwaną przez społeczność. Silne praktyki rozwojowe i wysokiej jakości Kod również budzą zaufanie społeczności, co z kolei prowadzi do zmniejszenia ryzyka i większej gotowości do wprowadzania nowych zmian.

W zdecentralizowanym świecie istnieje o wiele więcej sposobów na pożyczanie i modyfikowanie istniejących lekcji, ostatnich i nie tak ostatnich. Mamy nadzieję, że w najbliższych tygodniach będziemy nadal dzielić się naszymi przemyśleniami na ten temat, omawiając, jak zbliżamy się do pierwszych wydań Keep Network.

Podziękowania dla Jamesa Prestwicha i Braytona Williamsa za przegląd wczesnych szkiców tej historii.

Dowiedz Się Więcej

Więcej informacji o Keep Network:

• Dołącz do nas na Reddicie.
• Zapoznaj się z naszym dokumentem.
• Przeczytaj nasz podkład biznesowy.
• Subskrybuj wiadomości e-mail.
• Śledź nas na Twitterze.
• Dołącz Slack.
• Dołącz do naszego telegramu.