jak zachować wydajność, gdy kompilacja prawie zawsze jest zepsuta

Pracuję w średnim zespole, który dzieli ten sam kod źródłowy i chociaż nadal mam integrację, ale ponieważ wszyscy musimy pracować w tej samej gałęzi, kompilacja prawie zawsze jest zepsuta.

Ponieważ mamy również zasadę, która została niedawno wprowadzona w celu złagodzenia uszkodzonych kompilacji, która mówi, że nikt nie może się zameldować, podczas gdy kompilacja jest czerwona.

Powiedziawszy to, w ciągu dnia wszyscy mają garść 10-15 minutowych okien, w których pozwoliliśmy się zameldować.

W miarę powiększania się zespołu, możliwości odprawy jeszcze bardziej się zmniejszają. Zmusza to programistów do gromadzenia zmian lokalnie, co prowadzi do większych zestawów zmian, co jeszcze trudniej zapewnić, że zmiany niczego nie psują. Możesz zobaczyć błędne koło.

Co możesz polecić, abym mógł pozostać efektywnym w pracy w takim środowisku? Pamiętaj też, że jestem programistą, a nie menedżerem i nie mogę zbytnio zmienić procesu ani zachowań innych osób.

Na początek ten komentarz:

... posiadanie oddziału oznacza dodatkową złożoność, a tym samym dodatkową pracę ...

jest całkowicie fałszywe. Często słyszę to od ludzi, którzy nie są przyzwyczajeni do rozgałęziania się, ale nadal jest źle.

Jeśli wielu programistów gromadzi zmiany lokalnie, ich zmiany lokalne stanowią de facto gałąź głównego repozytorium.

Kiedy w końcu pchają, jest to de facto połączenie .

Fakt, że twoje rozgałęzienia i scalenia są niejawne, nie usuwa dodatkowej złożoności, o którą się martwisz, tylko ją ukrywa. Prawda jest taka, że ​​wyjaśnienie tego procesu może ci pomóc (liczba mnoga = cały zespół) nauczyć się nim zarządzać.

Teraz mówisz

nikt nie może się zameldować, dopóki kompilacja nie jest czerwona

ale w tym przypadku kompilacji nigdy nie można naprawić, więc nie może być całkiem dokładna.

Ogólnie rzecz biorąc, jeśli rozsądnie jest budować lokalnie (tj. Kompilacja nie jest zbyt duża lub wolna), programiści powinni to zrobić przed wypuszczeniem.

Zakładam, że tak nie jest, ponieważ wtedy nie będą w stanie popchnąć zepsutych kompilacji, ale byłoby świetnie, gdybyś mógł wyjaśnić ten punkt.

Ogólnie odpowiedź na

jak zachować wydajność, gdy kompilacja prawie zawsze jest zepsuta

to: przestań łamać kompilację .

programiści ... gromadzą zmiany lokalnie ... Widać błędne koło.

To jest naprawdę błędne. Lokalne kumulowanie się zmian jest dużą czerwoną flagą wskazującą, że coś jest poważnie zepsute w procesie tworzenia. To w pewnym sensie niszczy cały cel posiadania systemu kontroli wersji .

Tak długo, jak chcesz trzymać się z daleka od zmiany procesu lub zachowania innych ludzi, najbardziej naturalnym rozwiązaniem byłoby utworzenie własnego oddziału i wykorzystanie go do „akumulacji” zmian (w celu uzyskania dalszej integracji z oddziałem zespołu, gdy otrzymasz szansa).

W rzeczywistości, jeśli jest więcej facetów takich jak Ty, możesz nawet współpracować i utworzyć wspólny dział programistyczny, aby swobodnie wymieniać aktualizacje bez ingerencji w niekompetentne pomysły na zarządzanie. Rozgałęzianie pozwala na wiele różnych sposobów uproszczenia pracy zespołowej.

• ^{Na marginesie, za każdym razem, gdy menedżer robi lub mówi coś, co zmusza cię do unikania zatwierdzeń, do trzymania kodu lokalnie, tłumacz ich słowa na pogrubione i jasne „Jestem niekompetentny” .}

pamiętaj, że jestem programistą, a nie menedżerem i nie mogę zbytnio zmienić procesu ani zachowań innych osób ...

W trosce o precyzję, faktycznie możesz , są to kwestie wpływu i umiejętności komunikacyjnych, a tak naprawdę nie trzeba być w stanie zmienić rzeczy zgodnie z ich upodobaniami (wyszukaj w Internecie coś takiego jak „zarządzaj”, jeśli są zainteresowani bardziej szczegółowymi informacjami).

Jednak to dość uciążliwe i pracochłonne i mogę doskonale zrozumieć, jeśli ktoś po prostu woli skupić się na kodowanie, przy niewielkim udziale w polityce - więc jeśli nie chcą (choć teoretycznie wy can ), to zrozumiałe. :)

Jestem wrażliwy na myśl, że czujesz się bezsilny, aby zmienić środowisko, ale myślę, że ta sytuacja stanowi poważne wyzwanie dla Twojego profesjonalizmu jako programisty.

Co by się stało, gdyby chirurg przechowywał brudne skalpele z czystymi? Co by się stało, gdyby hydraulik nie przetestował zainstalowanych rur? Co by się stało, gdyby skrzypek zawsze nie grał w orkiestrze?

Dlaczego programiści powinni być zwolnieni z pracy zespołowej i uprzejmości? Jako członek tego zespołu ponosisz odpowiedzialność za wynik. Ignorowanie zespołu jest nieodpowiedzialne, ponieważ sabotuje własne wysiłki.

Jestem ciekawy, skąd bierze się zasada, że ​​„nikt nie może się zameldować, dopóki nie jest czerwony”? Jest to dobra zasada, jeśli to skupia wszystkich na naprawianiu kompilacji. Starałbym się dawać przykład i pomagać naprawić kompilację, gdy jest zepsuta. Spójrzmy prawdzie w oczy, i tak nie robisz nic więcej. Jeśli cię to denerwuje, proponuję wyrazić te obawy. Głos kogoś, kto aktywnie próbuje poprawić sytuację, ma większy wpływ niż facet, który narzeka w kącie.

Myślę, że tak długo, jak myślisz, że jesteś „tylko programistą” i dlatego nie możesz zmieniać rzeczy, na które będziesz cierpieć z powodu tego problemu.

Musisz tylko przywrócić każde zatwierdzenie z repozytorium za każdym razem, gdy ktoś przerywa kompilację, a następnie powiedzieć temu facetowi, że właśnie złamał kompilację i że musi się zatrzymać. Musisz także wyjaśnić kierownikowi tę sytuację i powiedzieć mu, że wydajność tego zespołu spada z powodu tego problemu.

Musisz zrobić wszystko, aby lepiej zmienić proces i raczej powiedzieć później, że jest ci przykro, zamiast prosić o pozwolenie.

Myślę, że ty i twój zespół znajdujecie się w sytuacji, w której proces musi zostać zmieniony i nie możecie efektywnie pracować z tym zepsutym modelem. Myślę też, że Twoim obowiązkiem jest zrobienie czegoś z tym problemem, gdy go rozpoznasz. Jeśli nikt nie zamierza nic zrobić z tym problemem, to ty musisz!

Mogę odnieść się do twojej trudnej sytuacji, spotkałem podobną sytuację z moim ostatnim projektem w pracy. W końcu wdrożyliśmy system „gorących ziemniaków”, w którym programista, który ostatnio złamał kompilację, musiał opiekować się dzieckiem / opiekować się nim / monitorować, dopóki nie zostanie naprawiony ORAZ przejść wszystkie nasze testy weryfikacyjne.

Udało się to, ponieważ testy kompilacji i weryfikacji rutynowo zajmowały ~ 4 godziny, więc przerwanie kompilacji oznaczało, że straciłeś pół dnia na prawdziwej pracy. Nie trzeba dodawać, że spowodowało to, że programiści korzystali z gałęzi bardziej efektywnie przed scaleniem ich w pień. Dla większości programistów poprzedni sposób myślenia brzmiał: „Po prostu pozwolę systemowi budowania CI powiadomić mnie, jeśli mój kod zostanie uszkodzony”.

Zrobiłaby to prosta zmiana w systemie CI: każda zmiana, która psuje kompilację, jest automatycznie wycofywana. Co więcej, pozwól repozytorium CI stać się obszarem przejściowym, w którym zmiany są przekazywane do repozytorium autorytatywnego tylko wtedy, gdy kompilacja jest zielona. Narzędzia takie jak Gerrit mogą tu pomóc.

Dwie inne rzeczy mogą tu pomóc:

• czy Twój zespół może przetestować lokalnie wersję CI? Jeśli sprawdzisz, czy nie złamiesz kompilacji - a przynajmniej nie przerwiesz kompilacji w zwykły sposób bez konieczności zatwierdzania i wyzwalania zarządzania i gniewu zespołu.
• istnieje wiele sposobów definiowania uszkodzonych kompilacji w zależności od tego, w jaki sposób architekta CI. Obejmuje to definiowanie zepsutych - przy intensywnym rozwoju nie uważamy, że testy nie są przerwą, a raczej innym celem do osiągnięcia.

Ale naprawdę powinieneś spojrzeć na gałęzie.