Jest serwer Continuos Integration, który pilnuje, żeby nasz cudny kod był buildowalny poza maszyną developera. To bardzo ważne jeśli tego developera akurat nie ma w biurze. Wiadomo – u dev-a wszystko działa i wszystko się builduje – to czego nie wiadomo to co on/ona mają na komputerach poinstalowane i dlaczego tak naprawdę to to się builduje.
Jak napisałem wcześniej mamy serwer CI, który za nas robi buildy i jeszcze sprawdza czy ładny kod piszemy. Tylko, że testowy serwer ręcznie trzeba było aktualizaować – bez sensu. Wprawdzie to tylko jeden publish w visual studio więc jedną komendą jesteśmy wstanie to zrobić (przechodzimy Test Joela w tej kwestii) to jednak robienie tego ręczne jest po prostu… niepotrzebne. Niechaj CI sam zrobi publisha.
Parę kliknięc w TeamCity i jest.
…cisza. Build przeszedł, TeamCity świeci na zielono, wersja na serwerze testowym jest stara. Szybki rzut oka do loga i… nic.
Na serwerze jest wszystko co potrzebne do buildowania ale dalej TeamCity nie zgłasza błędów z MSBuilda. Po prostu MsBuild wykonuje się poprawnie mimo, że nie robi publisha. Zresztą w logu MsBuilda magicznie nie znalazłem informacji, że publish się nie wykonał. Więcej, nie znalazłem informacji że MsBuild robił publish. Ot, nic takiego nie było. WHAAT!!
Instalacja .net framework 4.5 SDK też nie pomogła. W czeluściach internetów jednak znalazlem, żeby przenieść z maszyny developerskiej katalog
c:\program files (x86)\msbuild\microsoft\visualstudio\v12
do
c:\program files (x86)\msbuild\microsoft\visualstudio\v12
na serwerze buildowania.
Run i… nagle wszystko pięknie działa. Team City robi publish i świat już jest piękniejszy. Aby zrobić publish wersji do środowiska testowego, opublikować instalkę, wrzucić ja na sieć, nazwać i coś tam jeszcze zrobić muszę wykonać komendę:
git svn dcommit
