TeamCity – co nám přineslo a co s testy na serveru bez Visual Studia


Na MS Fest 2012 byla přednáška Efektivní vývoj v týmu od Michala Augustýna, jejíž záznam si můžete přehrát na wug.cz.

Celá tato přednáška byla velmi zajímavá a přínosná – vždy je dobré se dozvědět, jak to funguje jinde. Hlavní část přednášky se věnovala TeamCity a jak ho používají v Avastu. O build serveru jsem slyšel dříve, ale vždy jsem měl dojem, že to nepotřebujeme, ale z celé konference jsem odcházel s tím, že tohle opravdu musím zkusit hned večer doma a v pondělí to nainstalovat v práci. Tak se také stalo a přínosů to pro nás má spoustu, ale nebudu opakovat přednášku…

Nám to přineslo také výhody, které na první pohled nemusí být zcela zřejmé a proto jsem se je rozhodl sepsat v tomto článku. Jsou to takové vedlejší výhody, ke kterým nás buildování na serveru motivovalo a které jsme měli řešit už dávno tak, či tak.

V čem nám TeamCity pomohlo:

1) Pořádek v solutionech

Z nějaké vzdálené minulosti byl u nás ve firmě zvyk, že sln soubor nebyl ve verzovacím systému a každý měl na svém počítači svůj sln soubor. Když přišel nový kolega, dostal sln soubor přes Skype… Když někdo vytvořil nový projekt, musel všem říct, aby si ho do svého solutionu přidali… Šílené. Abychom mohli solution buildovat na serveru, museli jsme vytvořit jeden sln soubor, který je teď ve verzovacím systému a všichni mají stejný – konečně!

2) Pořádek v konfiguračních souborech

Stejně, jako u sln souborů, tak ani konfigurační soubory nebyly ve verzovacím systému (opět fungoval geniální systém posílání po Skypu). Důvodem bylo, aby každý na svém počítači mohl mít jinou konfiguraci. To mělo “skvělé” následky například při deployování webů, kdy se muselo hlídat, aby na serveru zůstal správný konfigurační soubor atd., samozřejmě s tím byla spousta problémů. Pro build na serveru jsou konfigurační soubory samozřejmě potřeba, takže jsme museli udělat pořádek i v nich. Navíc jsem konečně správně nastavil transformace konfiguračních souborů, takže další problémové místo odstraněno.

3) Zájem všech o testy

Další věcí, která není právě k chlubení, je to, že testy jsem donedávna psal jen já. Možná je to moje chyba, ale jen slovy jsem kolegy k testování nedostal, tak jsem zkusil “jít příkladem”, ale i tomu zdatně odolávali… Protože ale na serveru spouštíme testy, tak všichni mohou vidět, jestli prochází, kolik jich je, jak přibývají atd. To mělo za následek zájem kolegů o testování a v tuto chvíli se s tím snaží začít – konečně!

Jak spouštět MSTesty na serveru

Problém, na který jsem narazil v začátcích s TeamCity, bylo to, že testy, které jsou ve Visual Studiu defaultně, vyžadují pro své spuštění instalaci Visual Studia (Express verze nestačí). Protože na serveru, kde nám TeamCity běží, nemáme nainstalováno Visual Studio, museli jsme tento problém řešit.

Jednou z možností, jak toto řešit, je začít využívat nějaký testovací framework, který nevyžaduje Visual Studio – NUnit, xUnit… Problém ale je, že by to vyžadovalo zvyknout si na něco jiného než to, co mi doteď vyhovovalo. A to se mi nechtělo. Existují návody, jaké knihovny kam na server nakopírovat, jaké klíče kam nakopírovat do registrů atd., jenže to je způsob, který opravdu není hezký.

Nakonec jsem našel způsob, který se mi sice také nelíbí, ale je to cesta nejmenšího odporu a relativně snadno se takové testy dají spouštět na serveru.

MSTesty a NUnit testy vedle sebe

Celý postup spočívá v tom, že píšete MSTesty, jak jste zvyklí a jak píšete doposud, ale na serveru se tyto testy spouští jako NUnit testy.

V test projektu stačí přidat NUnit framerwork (ideálně přes Nuget). A v kódu testů používat usingy, které zajišťují to, že v debug módu (na lokálním počítači ve Visual Studiu) se spouští testy jako MSTesty a v release módu (TeamCity na serveru) se spouští jako NUnit testy:

#if DEBUG
using Microsoft.VisualStudio.TestTools.UnitTesting;
using TestFixture = Microsoft.VisualStudio.TestTools.UnitTesting.TestClassAttribute;
using SetUp = Microsoft.VisualStudio.TestTools.UnitTesting.TestInitializeAttribute;
using Test = Microsoft.VisualStudio.TestTools.UnitTesting.TestMethodAttribute;
#else
using NUnit.Framework;
using TestClass = NUnit.Framework.TestFixtureAttribute;
using TestMethod = NUnit.Framework.TestAttribute;
using TestInitialize = NUnit.Framework.SetUpAttribute;
using TestCleanup = NUnit.Framework.TearDownAttribute;
#endif

Samozřejmě je to jen naznačení postupu (možná existují mnohem lepší postupy – v tom případě mi prosím dejte vědět!). My například máme upraveny šablony pro soubory testů, takže tento kód samozřejmě nepíšeme ručně.

Jak už jsem psal výše, tento postup se mi nelíbí, není ideální a přináší i nějaké problémy. Záleží, jaké testy píšete, většina problémů se dá vyřešit.

, , , , ,

Komentáře jsou uzavřeny.