Konflikty wersji w Contentful powinny być bezpiecznie ponawiane

Contentful chroni wpisy za pomocą optymistycznego blokowania. Każda aktualizacja zawiera wersję, którą klient uważa za edytowaną. Jeśli najpierw pojawi się inna zmiana, Contentful odrzuca nieaktualną aktualizację, zamiast pozwolić jej nadpisać nowszą pracę.

Ten konflikt jest mechanizmem bezpieczeństwa. Nie powinien stawać się ślepą uliczką dla lokalizacji.

Dlaczego konflikty zdarzają się w dobrze działających zespołach

Żądanie tłumaczenia może zająć trochę czasu. Podczas gdy jest generowane lub sprawdzane, redaktor może poprawić wpis źródłowy, inna lokalizacja może zostać zaktualizowana albo automatyzacja może zmienić metadane.

Zanim zlokalizowana wartość będzie gotowa do wysłania, wersja wpisu zapisana wcześniej jest już nieaktualna.

Nie oznacza to, że ktoś popełnił błąd. Oznacza to, że wiele części systemu publikacji działa w tym samym czasie.

Nigdy nie ponawiaj ślepo tego samego nieaktualnego ładunku

Najprostsze ponowienie powtarza odrzucone żądanie. To nie może się udać, ponieważ zawiera tę samą nieaktualną wersję.

Niebezpieczna alternatywa polega na pobraniu najnowszego numeru wersji i ponownym wysłaniu całego starego ładunku wpisu. To może przejść kontrolę wersji, jednocześnie nadpisując pola zmienione od czasu rozpoczęcia tłumaczenia.

Bezpieczne ponowienie wymaga świeżego stanu i wąskiej poprawki.

Odczytaj ponownie, scal i zaktualizuj

Gdy Contentful zgłasza konflikt wersji, przepływ pracy powinien:

1. pobrać bieżący wpis z tej samej przestrzeni i środowiska
2. sprawdzić najnowsze pola i wersję
3. scalić wyłącznie zatwierdzone wartości dla docelowej lokalizacji z żądania tłumaczenia
4. zachować niezwiązane pola i wartości lokalizacji
5. przesłać aktualizację z bieżącą wersją

Dzięki temu ponowienie pozostaje zgodne z rzeczywistą intencją użytkownika. Żądanie tłumaczenia miało zmienić konkretne zlokalizowane pola, a nie przywracać starą migawkę całego wpisu.

Zdecyduj, kiedy nie ponawiać

Automatyczne odzyskiwanie po konflikcie wymaga ograniczeń.

Jeśli dokładnie to samo pole docelowej lokalizacji zmieniło się po rozpoczęciu przeglądu, system wykrył rzeczywisty konflikt redakcyjny. Automatyczne ponowienie mogłoby zastąpić nowszą pracę człowieka. W takim przypadku należy się zatrzymać i poprosić o przegląd.

Podobnie powtarzające się konflikty mogą wskazywać na intensywną pętlę automatyzacji lub integrację, która nieustannie zapisuje wpis. Ograniczona liczba ponowień zapobiega temu, by lokalizacja dołączyła do tej pętli bez końca.

Błąd powinien pozostać możliwy do podjęcia działań: należy zidentyfikować wpis, lokalizację i pola, których dotyczy, oraz etap, na którym doszło do kolizji.

Zachowaj jasny podział odpowiedzialności za źródło i cel

Obsługa konfliktów jest łatwiejsza, gdy przepływ pracy ma ścisłą granicę zapisu. Wysyłki tłumaczeń powinny zmieniać tylko zatwierdzone lokalizacje docelowe. Nie powinny zapisywać pól źródłowych, metadanych typu treści, tagów ani niezwiązanych wartości lokalizacji.

Ta granica zmniejsza złożoność scalania i sprawia, że dzienniki audytu mają sens. Gdy ponowienie się powiedzie, zespół może dokładnie zobaczyć, które zlokalizowane pola się zmieniły i dlaczego.

Najważniejszy wniosek

Konflikty wersji są normalne w środowisku współpracy w CMS. Traktowanie każdego konfliktu jako nieudanego tłumaczenia sprawia, że przepływ pracy wydaje się kruchy; ignorowanie konfliktu czyni go niebezpiecznym.

Pobierz najnowszy wpis, scal najmniejszą zatwierdzoną zmianę i ponów w jasno określonych granicach. Gdy to samo pole zmieniło się po obu stronach, zatrzymaj proces do przeglądu przez człowieka. Niezawodność wynika z poszanowania współbieżnej pracy, a nie z udawania, że do niej nie dochodzi.