Strategie łączenia 1 roku rozwoju w Visual Studio

Mam klienta, który nalegał, aby cały 2016 rok trzymać się z dala od głównych oddziałów. Miały 3-4 inne zespoły pracujące nad aplikacją na różnych stanowiskach. Wprowadzono wiele dużych zmian (zmiana sposobu wstrzykiwania zależności, czyszczenie kodu za pomocą ReSharper itp.). Teraz padło na mnie, aby połączyć main z naszą nową gałęzią deweloperów, aby przygotować się do przyspieszenia naszych zmian w łańcuchu.

Podczas mojego początkowego łączenia, TFS zgłosił ~ 6500 plików z rozwiązaniem konfliktu. Niektóre z nich będą łatwe, ale niektóre będą znacznie trudniejsze (szczególnie niektóre javascript, kontrolery interfejsu API i usługi obsługujące te kontrolery).

Czy mogę zastosować takie podejście, które ułatwi mi to?

Aby to wyjaśnić, wielokrotnie wyrażałem wiele obaw związanych z tym podejściem. Klient był i jest świadomy trudności z tym związanych. Ponieważ wybrali brak personelu QA (1 tester na 4 programistów, brak testów automatycznych, małe testy regresji), nalegali, abyśmy utrzymywali naszą gałąź odizolowaną od zmian w głównej gałęzi pod pretekstem, że zmniejszy to potrzebę naszego tester, aby wiedzieć o zmianach wprowadzanych gdzie indziej.

Jednym z większych problemów tutaj jest aktualizacja do wersji kątowej i niektórych programów innych firm - niestety nie znaleźliśmy dobrego sposobu na zbudowanie tego rozwiązania, dopóki wszystkie elementy nie zostaną przywrócone na miejsce.

Byłby prosty sposób, który oddzieliłby twój nowy rozwój od głównej gałęzi, nie wprowadzając cię w tę niefortunną sytuację: każda zmiana z pnia powinna być codziennie łączona z gałęzią programistów . (Czy twój klient był tak krótkowzroczny, że nie mógł przewidzieć, że pewnego dnia twój oddział będzie musiał zostać ponownie przeniesiony do głównej linii?)

W każdym razie najlepszym podejściem jest IMHO, próbujące powtórzyć to, co powinno się wydarzyć z pierwszej ręki:

• zidentyfikować semantykę zmian w linii głównej dla dnia 1 po utworzeniu gałęzi. Zastosuj je do bieżącej bazy kodu tak dobrze, jak to możliwe. Jeśli była to „zmiana lokalna”, powinna być prosta, jeśli była to „refaktoryzacja przekrojowa”, taka jak zmiana nazwy powszechnie używanej klasy, zastosuj ją w semantycznie równoważny sposób do bieżącej bazy kodu. Mam nadzieję, że w tym roku nie wprowadzono sprzecznych przekrojowych zmian w bazie kodu w „twojej” gałęzi, w przeciwnym razie może to stać się prawdziwą łamigłówką
• przetestować wynik (czy wspominałem, że do tego zadania potrzebujesz dobrego zestawu testów)? Napraw wszystkie błędy wykryte podczas testu
• teraz powtórz ten proces dla zmian w linii głównej dla dnia 2, następnie dnia 3 i tak dalej.

Może to działać, gdy zespoły ściśle przestrzegają klasycznych zasad kontroli wersji („zatwierdzaj tylko możliwe do kompilacji, przetestowane stany” i „melduj się wcześnie i często”).

Po 365 powtórzeniach (lub 250, jeśli masz szczęście i możesz powiązać pracę na weekendowe zmiany), będziesz prawie gotowy (prawie, ponieważ musisz dodać liczbę zmian, które będą miały miejsce w głównej linii podczas okresu integracji ). Ostatnim krokiem będzie ponowne scalenie zaktualizowanej gałęzi programisty w pień (abyś nie stracił historii pnia). To powinno być łatwe, ponieważ technicznie powinno to być jedynie zastąpienie dotkniętych plików.

I tak, mówię poważnie, prawdopodobnie nie ma na to skrótu. Może się okazać, że „porcje dzienne” mogą być czasami zbyt małe, ale nie spodziewałbym się tego, chyba bardziej prawdopodobne, że porcje dzienne mogą okazać się zbyt duże. Mam nadzieję, że twój klient naprawdę dobrze za to płaci i że jest to dla niego tak drogie, że wyciągnie wnioski z porażki.

Powinienem dodać, że możesz tego spróbować także z przełączonymi stronami - reintegrując zmiany z gałęzi w małych porcjach do linii głównej. Może to być prostsze, gdy w gałęzi dewelopera wprowadzono znacznie mniej zmian niż w linii głównej lub większość zmian nastąpiła w nowych plikach źródłowych, które obecnie nie są częścią linii głównej. Można to postrzegać jako „przenoszenie” funkcji z produktu A (gałąź programistów) do nieco innego produktu B (aktualny stan pnia). Ale jeśli większość przekrojowych refaktoryzacji została przeprowadzona w linii głównej i mają one wpływ na twój nowy kod (kolizje scalania 6500 wydają się być na to dowodem), może być łatwiej, tak jak to opisałem na początku.

Na tym etapie scalania powiedziałbym, że automatyczne łączenie może tylko skomplikować proces. Miałem podobne problemy z oddziałami, które były rozbieżne przez ponad rok, a najbardziej skuteczną metodą, jaką mam, jest:

• Zrób kopię oryginalnego stanu nie połączonego
• Różnica między nie połączonymi a najnowszymi
• Rozbij wszelkie wspólne elementy
  • Na przykład wykonaj wszystkie zmiany nazw funkcji, a następnie zmiany parametrów itp.
  • Zignoruj ​​białe spacje na diff, jeśli standardy się zmieniły, w przeciwnym razie zmarnujesz dużo czasu na zliczanie spacji
• Najpierw skoncentruj się na podstawowej funkcjonalności

W końcu ostrzeżenia kompilatora i różnice będą twoimi najlepszymi przyjaciółmi, używaj niezmergowanego różnicowania, aby zobaczyć dokładnie, co się różni i po prostu kontynuuj. Mogą istnieć różne narzędzia, których możesz użyć, ale to od ciebie zależy, które z nich będzie najlepsze.

Kluczem do sukcesu jest kontynuacja.

Edytować:

Słowo ostrzeżenia, takie podejście będzie oznaczać, że historia kontroli wersji stanie się „zepsuta”, ponieważ stracisz dowody scalenia między gałęziami, a także historię nie połączonej gałęzi.

Dzięki komentarzom „Jacka Aidleya” i „17 z 26”

Kilka lat temu mieliśmy klienta o takich samych wymaganiach dotyczących oddzielenia oddziałów. Tak zrobiliśmy.

Nigdy nie połączyliśmy ich oddziału. Mieli tam swoją unikalną wersję. Pobraliśmy je dodatkowo za zmiany, ponieważ w zasadzie mieliśmy dwa główne pnie zamiast 1 głównego pnia i gałęzi.

Próbowaliśmy połączyć się z powrotem do bagażnika, ale po 2 tygodniach postanowiliśmy porzucić ten wysiłek, ponieważ płonęło wiele godzin bez żadnych wymiernych korzyści.

Więc nie łącz go z powrotem. W przyszłości scalanie krytycznych poprawek do tego oddziału klienta w razie potrzeby, a wszelkie ulepszenia byłyby jednorazowo naliczane specjalnie dla tego klienta.

To nie będzie zabawne, ale to, jak bolesne będzie, zależy od charakteru zmian i ich izolacji.

Sugeruję, abyś spróbował zjednoczyć gałęzie poprzez refaktoryzację w jak największym stopniu, zanim wykonasz scalenie.

Narzędzie scalania jest głupie, ponieważ patrzy tylko na różnice tekstowe i nie rozumie kodu w żaden sposób. Jeśli główna gałąź zmieniła nazwę klasy używanej w aplikacji, a gałąź funkcji używa starej nazwy w nowym kodzie, narzędzie do scalania nie zrozumie, że nazwa klasy powinna również zostać zmieniona w nowym kodzie. Ale jeśli zrobisz refaktoryzację w gałęzi B, aby zmienić nazwę klasy jak w gałęzi A, będzie działać zarówno w starym, jak i nowym kodzie, a scalanie przebiegnie bezproblemowo.

Po drugie, powinieneś sprawdzić, jak zlokalizowane są zmiany w gałęzi programistycznej. Jeśli zmiany w gałęzi funkcji są zlokalizowane w kilku obszarach, nie musisz konwertować niezmienionego kodu, możesz po prostu skopiować i zastąpić z gałęzi głównej.

W obszarach kodu, w których nastąpiły nietrywialne zmiany w obu gałęziach, musisz dokładnie sprawdzić kod i zdecydować, jak przepisać.