Zawsze pracowałem z kompilacją Continuous Integration (CI) w TFS. Jednak w moim ostatnim projekcie zaczęliśmy używać bramkowanego warunku odprawy.Wady ogrodzonego check-in w TFS
Czy są jakieś niedogodności podczas korzystania z bramofonu? Bo jeśli to uniemożliwi drużynie sprawdzanie zepsutego kodu, jaki jest cel wyzwalacza CI?
Bramkowany checkin jest formą ciągłej integracji. W TFS tworzy on zestaw półek zawierający kod, który jest sprawdzany, a następnie uruchamia kompilację tego kodu. Tylko jeśli ten kod zostanie pomyślnie zbudowany i wszystkie skonfigurowane testy jednostkowe przejdą, kod zostanie faktycznie zatwierdzony.
Ciągła integracja jest inna - w CI kod jest zatwierdzany niezależnie od tego, co dzieje się w wyniku kompilacji. Jeśli kompilacja CI nie powiedzie się z powodu złego kodu, kod nadal znajduje się w źródłowej kontroli dostępnej dla wszystkich.
Teraz dla części opartej na opiniach: Bramka kontrolna jest świetna, jeśli masz dużą liczbę programistów o różnym poziomie umiejętności/doświadczenia, ponieważ zapobiega to przejściu zepsutego kodu do kontroli kodu źródłowego. Minusem jest to, że zwiększa czas między popełnianiem kodu a udostępnianiem kodu dla innych, a zatem może prowadzić do sytuacji, w których ludzie siedzą przy kręceniu kciukami, czekając, aż kompilacja zakończy się pomyślnie.
Polecam używanie bramofonu jako przystawki. Jeśli masz masę zamkniętych budek check-in, to wykonuje swoją pracę i uniemożliwia popełnienie złego kodu. Jeśli z biegiem czasu zespół dojrzeje, a budowane przez check-in kompilacje nierzadko będą się zdarzały, to będzie to miało mniejszy cel i należy je przełączyć na ciągłą integrację i korygowanie nieudanych kompilacji w miarę ich pojawiania się, zamiast opóźniać każde zatwierdzenie w sytuacji, gdy wystąpi problem. .
Dodatkowa uwaga. Jeśli infrastruktura kompilacji nie jest dostępna, bramka kontrolna uniemożliwi deweloperom publikowanie ich kodu; więc sugeruję mieć plan B (może to być kilka skryptów, które zmieniają typ kompilacji z bramkowanego na CI iz powrotem). –
Jeśli używasz Git, możesz użyć zasad kompilacji, aby osiągnąć podobny bramkowany przepływ pracy: https : //msdn.microsoft.com/Library/vs/alm/Code/git/branch-policies#Requirethepullrequesttobuild –
Wyjaśnij, ludzie nie muszą czekać na GC, aby zakończyć ("twiddling ich kciuki czekają"). Mogą zdecydować, że nie zachowają swoich zmian lokalnie i kontynuować swoje następne zadanie. Oczywiście, jeśli są zależne od tego elementu, mogą zachować lokalne zmiany i kontynuować, a po zakończeniu GC mogą uzyskać najnowsze i uzgodnić swoje zmiany serwera/lokalne. Robimy to w ten sposób i powstrzymujemy ludzi przed czekaniem i utrzymujemy GC jako przerwę, jak wskazano. – SnapJag