Jeśli wasz zespół pracuje w Make, budujemy w Make.
Make świetnie radzi sobie z wizualnymi scenariuszami o wielu rozgałęzieniach, a narzędzie, które wasz zespół rozumie, bije lepsze narzędzie, którego nie rozumie. Budujemy w tym ograniczeniu, zamiast wam je wyperswadować.
Obstajemy natomiast przy tym samym standardzie realizacji: obsługa błędów, wskazana osoba odpowiedzialna, opisane scenariusze i budżet operacji uzgodniony z góry.
Schemat jest czytelny do pewnego momentu.
Jeden scenariusz w pięciu rolach
Routery zagnieżdżone w routerach. Działa, tylko nikt nie potrafi bezpiecznie zmienić jednej gałęzi bez przetestowania wszystkich pozostałych.
Operacje mnożą się niepostrzeżenie
Każdy moduł w każdej gałęzi zużywa jedną operację. Scenariusz, który był tani przy 500 uruchomieniach miesięcznie, przestaje taki być przy 50 000.
Brak skonfigurowanej obsługi błędów
Make udostępnia ścieżki błędu z instrukcjami wznowienia i wycofania zmian. W większości instancji nie ma żadnej, więc nieudane uruchomienie po prostu się zatrzymuje.
Brak dyscypliny wersji
Schematy można eksportować, ale prawie nikt nie robi tego regularnie. Nie ma żadnego porównania zmian z zeszłego piątku.
Trzy rodzaje współpracy przy Make
Każdy z nich kończy się eksportem schematu do waszego repozytorium i osobą, która potrafi go zmienić.
Scenariusze pisane tak, żeby dawały się czytać
Jedno zadanie na scenariusz, nazwane moduły, ścieżka błędu na każdej gałęzi i prognoza zużycia operacji przygotowana przed budową, a nie po niej.
Rozplątywanie molocha
Jeden przeciążony scenariusz dzielimy na kilka, które można zmieniać niezależnie — zwykle przy okazji zbijając liczbę operacji.
Make plus cięższa warstwa
Wasz zespół zatrzymuje scenariusze, które prowadzi. Części o dużym wolumenie albo wymagające kodu przenosimy do n8n lub Pythona, za czytelnym interfejsem. Automatyzacja GTM.
Make, n8n czy Zapier — osobno dla każdego procesu
Przenosimy scenariusz z Make wtedy, gdy przy danym wolumenie operacje robią się drogie, gdy potrzebny jest prawdziwy kod albo gdy cicha awaria jest nie do przyjęcia. Sam fakt, że scenariusz działa poprawnie od roku, nie jest powodem do migracji.
Make bez niedomówień.
Make czy n8n?
Jeśli wasz zespół już pracuje w Make i czyta jego scenariusze, zwykle warto zostać. Proces przenosimy do n8n wtedy, gdy potrzebuje kroków z kodem, wersjonowania w git albo gdy koszt liczony za operację przestaje się przy waszej skali składać.
Dlaczego rachunek za Make rośnie szybciej niż nasz wolumen?
Bo operacje liczy się od modułu i od uruchomienia, a router z kilkoma gałęziami je zwielokrotnia. Podział jednego scenariusza na kilka mniejszych i wcześniejsze filtrowanie zwykle zauważalnie obniżają tę liczbę.
Czy Make radzi sobie z porządną obsługą błędów?
Tak. Obsługuje ścieżki błędu z instrukcjami wznowienia, wycofania zmian i zatwierdzenia. Problemem prawie nigdy nie są możliwości narzędzia, tylko to, że nikt tego nie ustawił.
Czy będziecie namawiać na zmianę narzędzi?
Nie. Wybieramy osobno dla każdego procesu, a narzędzie, które wasz zespół utrzyma, jest warte więcej niż odrobinę lepsze, którego nie utrzyma. Jeśli konkretny proces naprawdę potrzebuje cięższej warstwy, powiemy to wprost i wyjaśnimy dlaczego. Jak dobieramy narzędzia.
Prześlijcie nam swój największy scenariusz i zużycie operacji z ostatniego miesiąca.
Pokażemy, gdzie uciekają operacje, którym gałęziom brakuje ścieżki błędu i ile dałoby podzielenie scenariusza na mniejsze.