5

Co mam zamiar zrobić, to mieć CI i automatyczną kompilację dla wszystkich moich oddziałów w repozytorium. Chciałbym, aby każda kompilacja tych aplikacji internetowych miała własny projekt i była umieszczana jako katalog wirtualny (lub odpowiednik) na stronie oddziałów. Byłoby wspaniale móc stworzyć nowy oddział i automatycznie rozpocząć proces ciągłej integracji i budowania. Dodanie nowego katalogu wirtualnego w IIS nie jest wielkim problemem, nie przeszkadza mi to zrobić, jeśli reszta po prostu się ułoży.Automatyczne kompilacje gałęzi z SVN

na przykład:

http://branch.domain.com/branch101/

http://branch.domain.com/otherBranchName/

Obecnie używam SVN Nant i CruiseControl.NET, ale jestem otwarty innego serwera ciągłej integracji lub budowy wykonywanie skryptów, jeśli sytuacja tego wymaga.

+0

Nie jestem pewien, czy rozumiem pytanie - czy szukasz nowego projektu CC.net, który zostanie automatycznie utworzony po odłożeniu kodu?- lub po prostu najlepszy sposób na skonfigurowanie ccnet do budowania wielu oddziałów - wspominasz katalog wirtualny - czy mówimy o aplikacjach internetowych? – Richard

+0

Tak dla obu, zredagowałem pytanie, aby było bardziej zrozumiałe (mam nadzieję!) –

Odpowiedz

1

Nie rozumiem prawdziwego pytania. W każdym razie proponuję ci Hudson (http://hudson-ci.org/).

Jest łatwy w użyciu. Jest łatwy do skonfigurowania za pomocą plików XML. Ma zdalny interfejs API.

+0

+1 dla Hudsona. (Strzeż się jednak: Jeśli tworzysz na wielu platformach, Hudson nie przejdzie do następnej kompilacji, dopóki każda platforma nie zostanie ukończona, co oznacza, że ​​najwolniejsza maszyna do kompilacji/testowania spowalnia wszystkich pozostałych. Przynajmniej tak było w ubiegłym roku kiedy go wypróbowaliśmy.) – sbi

+0

Jesteś pewien? Na platformę masz na myśli pracę Hudsona? Ponieważ możesz ustawić więcej niż jeden "Build Executor". Nigdy go nie używam, ale Hudson obsługuje tryb "master/slave", aby dystrybuować kompilacje. –

+0

@ungarida: Hudson był jednym z bardziej obiecujących narzędzi IK, które oceniliśmy, i ISTR, z którego zrezygnowaliśmy. Ale nawet nie pamiętam, jakie są "prace" dla Hudsona, więc sądzę, że to oznacza, nie, nie jestem pewien. – sbi

1

Nie sądzę, co chcesz, jeśli chodzi o automatyczne konfigurowanie projektów ciągłej integracji w oparciu o rozgałęzianie. Jednakże, jeśli twoje gałęzie są dość standardowe i nie zmieniają się drastycznie, byłoby raczej łatwo napisać skrypt powershell (lub dowolne inne języki skryptowe, które wolisz), aby skonfigurować nowe projekty.

Podejrzewam, że istnieje taka potrzeba, jednak gdy tworzymy gałąź w CC.NET, kopiowanie projektów łączy i wyszukiwanie oraz zastępowanie potrzebnych pól zajmuje mniej niż minutę. Problemy pojawiają się tylko wtedy, gdy mamy niestandardowe skrypty używane podczas kompilacji, jeśli takie istnieją, musimy je również zmodyfikować, ale stanie się tak z każdym ciągłym systemem integracji.

3

Można to zrobić, ale wiele z nich będzie zależało od twoich skryptów budujących. Jeśli powiesz cc.net, aby monitorował folder svn najwyższego poziomu, na przykład masz monitor projektu:

zamiast http://myserver.com/svn/project/trunk. Jeśli jakiekolwiek zmiany są widoczne w http://myserver.com/svn/project, rozpocznie się kompilacja.

Teraz do skryptu kompilacji należy ustalenie, które źródło jest nieaktualne lub czy istnieje nowy oddział do zbudowania. Skrypt budujący tworzy nowy VDir dla dowolnych nowych gałęzi.

Inną opcją jest posiadanie projektu cc.net, który został zaprojektowany tak, aby nie robić nic innego, jak dodawać nowe projekty do twojego cc.net. (Nazwij to projektem BranchBuilder) Wykorzystałbym pre-procesor w cc.net i miałbym najwyższy poziom pliku .config, który zawierał projekt dla pnia i każdej gałęzi. Projekt rozgałęzienia budowałby ścieżkę główną na svn. Gdyby zobaczył jakieś zmiany, powinien sprawdzić, czy od czasu ostatniej kompilacji są jakieś nowe gałęzie. Jeśli takowy istnieje, może utworzyć plik ccnet-branchname.config dla tej gałęzi, utwórz vdir, a następnie zaktualizuj plik główny ccnet.config dodatkowym dołączeniem.

Po aktualizacji konfiguracji ccnet cc.net rozpozna, że ​​plik konfiguracyjny został zmodyfikowany i ponownie załaduje konfigurację dodając nowy projekt oddziału. Ten projekt oddziału zacznie działać i zbuduje nowy oddział.

+0

Jest to, moim zdaniem, naprawdę zły pomysł. Myślę, że za dużo zautomatyzujesz. Ile problemów może być, aby dodać blok do pliku ccnet.config w porównaniu do tego rozwiązania? –

+1

Robimy to również ręcznie. Tylko dlatego, że możesz coś zrobić, nie znaczy, że powinieneś. Jednak wykona automatyczną kompilację dla funkcji gałęzi, o którą prosi OP. To powiedziawszy, nie wiem, jak często się rozgałęziają. Może to być dziesiątki razy dziennie. Komputery są zaprojektowane do powtarzalnych zadań, prawda? – PilotBob

+1

@JoshKodroff Myślę, że to kwestia opinii, "drogie" rozgałęzienia to powód, dla którego wiele projektów jest blobbed razem w jednej linii (zwiększając ryzyko). Konieczność zalogowania się do komputera w celu rekonfiguracji procesu kompilacji wydaje się powodować znaczne koszty rozgałęzień. –

Powiązane problemy