#10 o micro deployment, design system i breaking changes w Angularze
Cześć!
Wydawanie zmian na produkcję stresuje każdego, a refaktor działających aplikacji jest odraczany w czasie jak tylko się da.
Micro deployment w Uberze
Na początku 2014 roku Uber działał w 60 miastach, a jesienią w 200, zatrudnili nowe osoby, a w pewnym momencie zapanował chaos w procesie wydawania - każdy robił po swojemu 🧨.
Co zrobili? Opracowali system dziennych wydań aplikacji - micro deploy.
W ciągu kilku minut mogą wydać nową wersję na produkcję, a w razie awarii 🐛 - wycofać.
Mimo, że jesteśmy tylko frontowcami lub backendowcami to powinniśmy dążyć do tego, żeby wydawać kod na produkcję jak najszybciej. Zacznij od dwóch skrótów: CI i CD 😎 a później - niech się dzieje samo 🔥.
PS. Monzo (startup fintech) wydawał swoje usługi nawet 100 razy dziennie.
Design system w Booking.com
Zastanawiałeś się kiedyś jak wygląda tworzenie produktu spójnego graficznie dla wielu platform rozwijanego przez ponad 150 zespołów produktowych? Już nie musisz, bo ktoś z booking.com opisał jak stworzyli multi platform design system.
Bardzo ciekawy jest proces, który wypracowali:
Design assessment 💡
Handoff 📙
Tech assessment 🔎
Kickoff 🤝
Implement 💻🤖📱
Design & accessibility review ✅
Release & share 📣
Przeważnie flow jest inne: design → handoff → implementacja i lecimy na produkcję ✈️.
W temacie bookingu - 2 lata temu zaczęli się zastanawiać w jaki sposób ułatwić pracę zespołów, żeby mogli szybciej dostarczać funkcjonalności.
Jak pewnie się domyślasz - aplikacja rozwijana przez ponad 10 lat, napisana w różnych językach, w której pełno zależności pomiędzy komponentami i bibliotekami nie jest zachęcająca dla nas 🥶
Co począć? Można tak:
In 2021, we began to modernize the app, primarily focusing on making it easier to ship features faster, making our app more stable and giving our customers a reliable, modern, on-brand, consistent experience.
Całą historie przeczytasz we wpisie: How we managed to modernize the Booking.com app from the inside and out.
Breaking change w Angularze 🍾
Nareszcie, po 7 latach od wydania Angulara doczekaliśmy się self-closing component tags! A w react było od początku 🙀.
Ale bez żartów - zapowiada się prawdziwa (r)ewolucja w systemie detekcji zmian.
Największym problemem Angulara jest wydajność zone.js (wiesz co to 😈?), dlatego niedawno zespół odpowiedzialny za Angulara opublikował RFC opisujące Signals.
Czym jest signals? W skrócie - mechanizm, w którym tworzysz konsumery dla "reaktywnych" zmiennych. Gdy wartość “sygnału” się zmieni to wszystkie konsumery zostaną o tym powiadomione. I change detection odpali się tylko w komponencie, w którym zaszła zmiana.
Więcej przeczytasz we wpisie Angular Signals in a Nutshell, znajdziesz tam też przykład aplikacji 🙂.