Jaki jest realistyczny sposób obsługi poprawek do oprogramowania specyficznych dla klienta?

Próbuję znaleźć skuteczne sposoby, w jakie inni rozwiązali następujący problem. W pracy zostaliśmy zmuszeni do wydania poprawki oprogramowania (do zainstalowania w systemach użytkowników końcowych), która jest widoczna tylko dla konkretnego klienta. Kod niestandardowy znajduje się we własnej gałęzi kontroli źródła. Problem polega na tym, że mamy dwie równoległe linie kodu (i budujemy skrypty) do synchronizacji, i za każdym razem kiedy łatamy oryginalny kod, musimy łatać i testować kod specyficzny dla klienta.

Jestem ciekawy, jak inne organizacje radzą sobie z tym scenariuszem? Jesteśmy otwarci na rozwiązania biznesowe, a nie tylko techniczne (związane z kontrolą źródła). Na przykład mówiliśmy o poinformowaniu klienta, że ​​nie może otrzymywać aktualizacji w tym oddziale.

Nasza strategia rozgałęziania jest taka (na podstawie Visual Studio TFS Branching Guide , chociaż używamy do tego Subversion)

Kiedy zaczynasz rozdawać łaty dla konkretnych klientów, natychmiast stworzyłeś nową wersję swojego produktu, którą należy zachować obok niej. Oznacza to, że zmiany muszą być propagowane między dwiema wersjami. Zwykle łaty specyficzne dla klienta to dostosowania, które powinny być własnością klienta, w tym kod źródłowy.

Wydaje się mało prawdopodobne, aby łatka naprawiająca coś nie trafiła do gałęzi głównej, chyba że jest to mniej niż optymalna tymczasowa poprawka dla bezpośredniego problemu. W takim przypadku łatka będzie musiała być utrzymywana, dopóki oczekiwana poprawka nie znajdzie się w linii głównej.

Wydaje mi się, że klucz jest „widoczny” - co powiesz na to, że w ogóle nie ma oddzielnej gałęzi kodu, a raczej opcję konfiguracji, która zmienia zachowanie?

Czy postrzegasz to jako krótkoterminowe czy długoterminowe? Faktem jest, że firma zdecydowała się już na przyjęcie tego klienta tak krótko, że JEST to już decyzja biznesowa, którą należy rozwiązać przede wszystkim poprzez praktyki biznesowe (zaakceptowanie dodatkowego kosztu / obciążenie klienta kosztami).

W perspektywie długoterminowej prawdopodobnie zobaczysz oszczędności, jeśli ponownie uwzględnisz oprogramowanie, aby łatwo dostosować się do potrzeb klientów poprzez konfigurację (lub konfigurację itp.).

Jeśli jest to względnie krótkoterminowe, co oznacza, że ​​wkrótce połączysz te zmiany z powrotem z gałęzią główną / programistyczną, a wszyscy użytkownicy również je zobaczą, prawdopodobnie praca w granicach obecnej sytuacji będzie prawdopodobnie akceptowalna. Tak jak powiedziałem, decyzja o tym, co należy zrobić, powinna zostać podjęta, gdy podjęta została decyzja o przyjęciu klienta.

Krótko mówiąc. Długoterminowo napraw to technicznie, krótkoterminowo z tym poradzić.

Oczywiście jest punkt, w którym jest to rzut monetą. Jeśli jesteś w tym momencie, zrobiłbym wszystko, co wolą programiści.

Używamy również subversion - i natrafiamy na dokładnie taki scenariusz.

Oto kilka kluczowych punktów do zapamiętania:

1. O ile jest to konieczne, należy unikać określonych oddziałów dla klientów, należy jednak zminimalizować tę potrzebę; zawsze pytaj, czy można uogólnić rozwiązanie, które może po prostu działać dla wszystkich.

2. Oddziały specyficzne dla klienta muszą pochodzić z nowej wersji. Załóżmy, że masz wersję 1.2, a nie pochodną od wersji 1.2.1 do 1.2.11 - gałęzie klienta powinny być dozwolone wszystkie łatki, dlatego gałąź klienta musi pozostać kompatybilna w odniesieniu do wersji głównej.

3. Specjalny oddział klienta musi zostać utworzony na nowo, gdy uruchomisz nową niekompatybilną wersję. Niefortunne jest to, że w jakiś sposób możesz wymagać ponownego wykonania pracy. Jednym z rozwiązań może być utworzenie wszystkich łatek z oddziałów klientów, które należy wyodrębnić, a wszystko, co stanie się nadal kompatybilne, można zastosować w nowym oddziale klienta.

4. Zawsze, pod żadnym pozorem, nie należy przesuwać zmian specyficznych dla klienta z powrotem, aby zwolnić oddział lub pień. Idealnie jednak należy starać się uogólnić pracę w taki sposób, aby ograniczyć pracę specyficzną dla klienta.

Próbowałem zebrać te pomysły, aby pokazać :

Co powiesz na wprowadzenie mechanizmu rozszerzenia do swojego kodu?

Twój główny kod ma:

class Foo
{
}

Po uruchomieniu program sprawdza DLL / ekwiwalent moralny w swoim folderze startowym pod kątem lokalnych dostosowań. Jeśli go znajdzie, ładuje się i może zawierać specyficzną dla firmy wersję Foo

class FooForABC : Foo
{
}

FooForABC implementuje to samo zachowanie, co Foo, ale zastępuje funkcje w razie potrzeby, aby zapewnić określone zachowanie, którego potrzebuje ABC. Technika powinna być wystarczająco elastyczna, aby poradzić sobie z każdym scenariuszem, który musisz wesprzeć.