Gated check-ins / pre-tested commits for Git?
Patrzę na migrację z TFS (Team Foundation Server) do Git, ale nie mogę znaleźć niczego pasującego do obsługi TFS ' gated check-in (zwanych również wstępnie przetestowanymi lub opóźnionymi zatwierdzeniami).
Atlassian Bamboo nie obsługuje kontroli bramkowej. TeamCity obsługuje je ("opóźnione commity" używając ich terminologii), ale nie dla Gita. Używanie Jenkinsa samo w sobie lub Jenkins+Gerrit ma ogromne wady i nie zbliża się do funkcji odprawy bramkowej w TFS. (Wady wyjaśnione przez twórca samego Jenkinsa w tym filmie: http://www.youtube.com/watch?v=LvCVw5gnAo0 )
Git jest bardzo popularny (nie bez powodu), więc jak ludzie rozwiązują ten problem? Jakie jest obecnie najlepsze rozwiązanie?
6 answers
Właśnie zaczęliśmy używać Gita i zaimplementowaliśmy wstępnie przetestowane commity przy użyciu obiegów pracy(skończyłem testowanie tego właśnie dzisiaj).
Zasadniczo każdy dev ma własne repozytorium, do którego ma dostęp do odczytu/zapisu. Serwer kompilacji TeamCity w naszym przypadku buduje przy użyciu tych osobistych repozytoriów, a następnie, jeśli się powiedzie, przesuwa zmiany do "zielonego" repozytorium. Deweloperzy nie mają dostępu do zapisu "Zielonego", tylko agenci budowania TeamCity mogą pisać do tego, ale deweloperzy pobierają wspólne aktualizacje z "zielony".
Więc dev ciągnie z "zielonego", pcha do osobistego, TeamCity buduje z osobistego, pcha do zielonego.
Ten wpis na blogu pokazuje podstawowy model, którego używamy, z widłami GitHub dla osobistych repozytoriów (używanie forków oznacza, że liczba repozytoriów nie wymknie się spod kontroli i nie będzie kosztować więcej, i oznacza, że deweloperzy mogą zarządzać osobistymi kompilacjami, ponieważ mogą rozwidlać, a następnie tworzyć zadania budowania team city, aby ich kod był wypychany do góry "zielony"): {]}
Jest to więcej pracy do skonfigurowania w TeamCity, ponieważ każdy programista musi mieć własną konfigurację kompilacji. TeamCity wydaje się wykonywać wszystkie kroki kompilacji (w tym ostatni krok "push to green"), nawet jeśli poprzednie kroki kompilacji zawiodą (jak testy:)), co oznaczało, że musieliśmy mieć osobisty build dla dewelopera, a następnie inną konfigurację kompilacji, która była zależna od tego, co po prostu wykonywałoby push zakładając, że program nie działa. Budowa zadziałała.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2012-09-18 21:04:32
Sprawdź Verigreen - lekki, bramkowany system odprawy po stronie serwera. Weryfikuje każdy commit, zanim trafi do gałęzi, które System chroni. Verigreen nie pozwoli, aby jakikolwiek nieudany commit CI przerwał integrację, wydanie lub jakąkolwiek gałąź, która powinna być chroniona. Co więcej-jest to darmowy, open-source projekt.
Jak to działa: Verigreen przechwytuje check-in i uruchamia weryfikację w gałęzi ad-hoc - tak, że w przypadku nieudanego commit, tylko odpowiednie dotyczy to dewelopera.
- Pre-receive hook przechwytuje i tworzy doraźną gałąź kodu.
- weryfikacja jest uruchamiana za pomocą zadania Jenkins. Zawartość zadania weryfikacji jest w pełni konfigurowalna.
- zweryfikowany kod jest scalany z powrotem do chronionej gałęzi, podczas gdy nieudany commit jest blokowany powiadomieniem wysłanym do dewelopera.
Decyzje są podejmowane w oparciu o następujący przepływ:
Dla więcej informacji można znaleźć na wiki lub Verigreen.io Strona
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2015-10-15 10:56:25
Po 23 października 2013 roku odpowiedź może brzmieć - Automatyczne Scalanie w TeamCity .
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2014-09-17 16:22:01
Git ma inną filozofię-commity są łatwe, commit jak chcesz. Jeśli coś jest nie tak, możesz to zmienić później. A połączenia są łatwe. Możesz więc zorganizować odpowiedni przepływ pracy, np. programiści mogą zatwierdzić W oddzielnej gałęzi (gałęziach). Gdy gałąź jest testowana, może zostać scalona w gałąź główną.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2012-09-18 20:37:45
Dlaczego nie użyć TFS jako centralnego repozytorium i użyć GIT jako lokalnego rozwiązania DVCS?
To pozwoli Ci budować i zatwierdzać lokalnie, a następnie wypchnąć to, co chcesz do serwera TFS i zrobić zamkniętą kompilację.
Czasami dobrze jest mieć to, co najlepsze z obu światów...
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2015-04-24 18:27:58
Z usługami VS Team (FKA Visual Studio Online) i TFS 2015 lub nowszymi możesz użyć branch policies requires a passing build dla pull request jako gated checkin workflow with Git.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2016-03-21 13:25:42