Jak uniknąć rozgałęzień w dużych organizacjach?

10

Jak uniknąć sytuacji rozgałęzień podczas pracy z dużymi organizacjami?

Współpracujemy z wieloma dużymi organizacjami finansowymi, których podejście polega na tym, aby nie wprowadzać aktualizacji oprogramowania, a jedynie wysokie / krytyczne łatki bezpieczeństwa i niestandardowe funkcje. Organizacje te będą pobierać łatki i wersje niestandardowe tylko między głównymi aktualizacjami. Poważne aktualizacje mogą obejmować lata i pociągać za sobą wysokie koszty. Takie podejście powoduje, że my (software house) mamy oddział naszego kodu na jednego dużego klienta, który niesie ze sobą wszystkie koszty i nieefektywności długoterminowego rozgałęziania.

Moje pytania do społeczności to:

Czy doświadczyłeś podobnych podejść do akceptacji aktualizacji od swoich klientów?
Jakie masz sugestie, aby pomóc w pracy z tym podejściem?
Jakie masz sugestie, aby zmienić podejście organizacji do pobierania aktualizacji oprogramowania?

release process branch

— Mark Wheeler
źródło

Hej Mark, brzmi to tak, jakbyś miał ciekawy dylemat. Jak zarządzasz opracowywaniem tych aktualizacji dla poszczególnych klientów? Czy opracowujesz je jednorazowo dla każdego klienta, czy też opracowujesz je i stosujesz do wszystkich klientów?

— PrestonM,

Osobiście mogę szukać innej pracy w tej sytuacji. To brzmi jak incydent bezpieczeństwa, który ma się wydarzyć ... Mogę powiedzieć, że dla dostawcy urządzenia, dla którego pracowałem, mieli poważny błąd, który został naprawiony w aktualizacji, do której podobno nie mogli się udać. Chcieli niestandardowej poprawki. Odmówiliśmy zbudowania jednego z nich i powiedzieliśmy, że muszą naprawić swoje zasady biznesowe - nie zamierzamy tworzyć niestandardowej poprawki dla błędu, który już załataliśmy, aby uniknąć wewnętrznych problemów politycznych.

— James Shewey

Zarządzamy niestandardowymi aktualizacjami specyficznymi dla klienta za pomocą wielu gałęzi kodu i krzyżowych poprawek zabezpieczeń do wszystkich gałęzi, a także krzyżowym kodem gałęzi z powrotem do magistrali. Często klient A nie przyjmuje aktualizacji klienta B w swoim oddziale, tylko własne aktualizacje i poprawki bezpieczeństwa. Wynika to z chęci zapewnienia stabilności w swojej branży, dlatego muszą oni jedynie testować odpowiednie dla nich aktualizacje. Aktualizacje magistrali są pobierane rzadziej (tj. Od miesięcy do lat), gdy są gotowe do przeprowadzenia pełnego ponownego uruchomienia testu, co może potrwać miesiące. Zautomatyzowane testowanie może być odpowiedzią!

— Mark Wheeler

3

Jak wspomniał Michael, zaoferuj standardowe rozwiązanie oparte na wersjach / numerach wydań, z rozsądnie długim okresem użytkowania dla Twojej branży (może być przeplatane z jedną lub kilkoma krótszymi wersjami pośrednimi, jeśli ma to sens dla typowych klientów).

Daj swoim klientom opcję rozpoczęcia tej standardowej ścieżki wydania, być może z odpowiednim terminem migracji.

Jeśli nalegają na w pełni niestandardową strategię wsparcia oddziału, po prostu odpowiednio je obciążaj, aby właściwie pokryć wszystkie dodatkowe koszty związane z oferowaniem takiego w pełni niestandardowego wsparcia - ma to tylko sens biznesowy. Niektórzy klienci przeprowadzą migrację, aby zmniejszyć koszty (co pomoże ci zmniejszyć liczbę niestandardowych oddziałów), inni nie.

Zmienne naliczanie opłat za obsługę, rosnące stopniowo wraz z wiekiem wersji wydań, z których pochodzą niestandardowe oddziały, może również zachęcać klientów do szybszej migracji do nowszych oddziałów, pomagając w szybszym zamykaniu starszych niestandardowych oddziałów. Pomoże to zmniejszyć liczbę niestandardowych oddziałów na klienta - jeśli masz klientów, którzy jednocześnie obsługują wiele wersji oprogramowania.

Upewnij się, że nie wpadniesz w pułapkę wykonywania pełnych połączeń gałęzi z / do którejkolwiek gałęzi wydania (zarówno standardowej, jak i niestandardowej), wszystkie zmiany w nich powinny być albo indywidualnie opracowane, albo wybrane połączone poprawki.

Ponieważ każda z tych gałęzi będzie stopniowo się od siebie różnić, liczba poprawek wymagających dostosowywania / indywidualnego rozwoju będzie rosła wykładniczo (zwykłe łączenie metodą „wybijanie wiśni” zakończy się niepowodzeniem). Musisz wziąć pod uwagę koszty rozwoju tych programów.

Bez (znaczących) połączeń gałęzi na zdjęciu możesz (i powinienem, nie mogę podkreślić jego znaczenia) zbudować w pełni zautomatyzowane rurociągi CI / CD dla tych gałęzi, w połączeniu z dobrym systemem śledzenia / zarządzania poprawkami, który zapewnia dostarczanie poprawek po prostu rutyna (lub prawie).

— Dan Cornilescu
źródło

Dan - takie oczywiste i proste, ale ma doskonały sens. Pieniądze sprawiają, że świat się kręci, a to z kolei powinno albo zrekompensować nam koszty długowiecznych oddziałów, albo zachęcić klientów do modernizacji i pozostania blisko bagażnika. Dziękuję za dobrą radę.

— Mark Wheeler

1

Może gdybyś utrzymywał oddziały na wersje zamiast na klientów, mogłoby to pomóc zmniejszyć ich liczbę?

W przeciwnym razie jedynym sposobem, aby naprawdę się od tego uwolnić, jest możliwość samodzielnego hostowania oprogramowania i przejścia na model SaaS, w którym można utrzymywać tylko jedną jego wersję.

— Michael Pereira
źródło

Niestety, nasi klienci często działają w bardzo zamkniętych środowiskach ze względu na dane finansowe, z którymi pracują, więc model SaaS byłby nie do przyjęcia.

— Mark Wheeler