Průběžná integrace

Continuous integration je volně řečeno souhrn praktik a nástrojů, při kterých vývojáři integrují (commitují) své změny často (typicky alespoň jednou za den). Každá integrace je automaticky ověřena testy a případně může vést až k automatickému nasazení nové verze aplikace (continuous delivery), v případě neúspěchu k okamžitému reportování problému.
Přínosy continuous integration jsou především zrychlení vývoje, rychlejší dodávání nových verzí a snížení chybovosti – to vše díky automatizaci co nejvíce úkonů, které je třeba dělat při vývoji, testování a nasazovaní aplikace.

Všechno by to šlo implementovat pomocí vzájemně provázaných skriptů, ale za šťastnější řešení (i když zavádí SPOF) považuji nasazení nějakého integračního serveru coby hlavního koordinátora všech operací. Integrační server toho pro nás může ale dělat ještě více – např. provázat buildy a verze aplikace s bug trackerem nebo issue trackerem (Bugzillou, Mantisem, Jirou, …). Integrační server se tak může stát místem, na kterém vidíte vše o projektu (a slovo integrační tak dostává další rozměr).

V tomto článku bych vám rád popsal, proč a jak jsem nasazoval integrační server já. Moc jsem toho o průběžné integraci předem nenastudoval, přistoupil jsem k věci celkem pragmaticky – cílem bylo vyřešit problémy, které mě trápili. A díky TeamCity jsem byl schopen do týdne rozjet prakticky vše, co jsem plánoval – tedy build Solution s více než 100 projekty (C# a C), spuštění unit testů, integračních testů, nasazení a spuštění akceptačních testů. Všechno samozřejmě plně automaticky, odpálené commitem do SubVersion.
Celý příspěvek

Unit testy a globální stav

Unit testy a globální stav – jak to jde dohromady? Vůbec! Za žádných okolností! Takové bylo pro mě hlavní poselství přednášky Miška Heveryho z Googlu, kterou měl v březnu 2011 na ČVUT. Pokud chcete psát dobrý (dobře testovatelný) kód, tak se opravdu použití globálního stavu vyvarujte. Jak ale identifikovat přítomnost globálního stavu v kódu?
Celý příspěvek

Architektura aplikace podle DDD

I když se o návrh architektury aplikací zajímám už nějaký ten pátek, stále si připadám jako bych byl na začátku – inu je to téma, které není vůbec jednoduché a postupem času se navíc komplikuje, jak se dostávají do popředí zájmu nové technologie (NoSQL, HTML5) nebo náhledy na věc (CQRS, messaging, pub/sub). Proto jsem se rozhodl sepsat tento článek, který neberte jako dogma, ale jen jako soupis mých aktuálních myšlenek a chápání architektury aplikace, který by měl rozpoutat diskuzi. Nemyslím si, že by existoval jediný správný přístup, ale o to by mohla být naše diskuze zajímavější 🙂
Celý příspěvek

Pár postřehů k Dependency Injection

Jak známo, existuje více způsobu, jak zajistit nainjectování závislostí do konkrétní třídy. Nejčastější jsou IMHO constructor injection (injectované typy jsou typy parametrů konstruktoru) a property setter injection (injectované typy jsou typy properties). Problém, který mám s druhým typem, je ten, že kontejner musí při konstrukci objektu vědět, které properties má zpracovat. To dává klasicky třída najevo tím, že se daná property označí atributem, specifickým pro jeden konkrétní kontejner. A právě takové zabordelení je to, co se mi na property setter injection nelíbí.
Nabízí se ale několik řešení, jak se vyhnout použití specifických atributů a tím snížit zabordelení kódu.
Celý příspěvek

Moderní programování v C#

Programování pro platformu .NET mi vždy přišlo (např. ve srovnání s J2EE) tak trošku jako divočina. O návrhových vzorech, testování a pružnějších technikách vedení projektů vědělo jen pár vyvolených (nezřídka kdy přicházejí právě ze světa Javy), běžnému programátorovi pojem „návrhový vzor“ evokoval tak maximálně „singleton“. A podle toho aplikace mnohdy vypadaly – netestova(tel)né, obtížně rozšiřitelné, monolity. Klidně se přiznám, že i já jsem byl takový programátor. Zkrátka, nebylo mezi vývojáři v .NETu povědomí o správném návrhu aplikací. Naštěstí se v poslední době začíná blýskat na lepší časy. Nejen blogeři píší o různých způsobech návrhu aplikací, ale i sám Microsoft odvedl na tomto poli kus práce – zpopularizoval návrhové vzory pro prezentační vrstvu díky ASP.NET MVC a MVVM, implementoval podporu pro POCO v Entity Frameworku, dotáhl do použitelné podoby kontejner Unity
V tomto článku bych rád nastínil, které principy vedly v poslední době k rapidnímu zvýšení kvality mých aplikací. Konkrétně se zaměřím na SOLID, TDD, IoC/DI a AOP.
Celý příspěvek

Really simple IoC/DI container implementation

I’m sure you know (or at least have heard of) Inversion of Control/Dependency Injection principle. It’s a very handy principle that leads to plugable application design, simplifies unit-testing and so I can recommend its using.
I wanted to use some really simple IoC/DI container with small footprint. Unity or PicoContainer.NET are propagated as „lightweight IoC/DI containers“ so I wanted to use one of them. Before I had looked into source code of Unity. And…what the hell? Lightweight? There are dozens of classes and interfaces! I’m sure that Unity is really good piece of software but I needed something less sophisticated and more fast. Despite IoC/DI is very strong principle it’s very simple to implement – so I decided to write my own really lightweight IoC/DI container. Just because I love programming 😉
Celý příspěvek

Cassandra očima .NET programátora

V poslední době je v módě termín NOSQL (Not Only Sql) a tak se i já o něm zmíním. Není to proto, že bych potřeboval být nutně cool, ale byl jsem nucen se na NOSQL podívat, protože nabízí efektivní řešení některých specifických úkolů, u kterých klasické relační databáze ztrácí dech. Je trošku zavádějící mluvit o NOSQL databázích (přestože to jsou báze dat), proto upřednostňuji termín NOSQL úložiště. NOSQL úložišť existuje mnoho typů, já se ale zaměřím jen na úložiště typu BigTable, konkrétně na Cassandru. Co zde popíšu ale do jisté míry platí i pro HBase.
Celý příspěvek

Architektura Modelu

V moderních aplikacích na platformě .NET se začínají prosazovat nejrůznější návrhové vzory, což jistě přispívá nejen k lepšímu návrhu aplikací, ale i ke snadnější komunikaci mezi vývojáři. Dosud jsem blogoval především o návrhovém vzoru, který se týkal pouze návrhu Prezentace – Model-View-Controller. Existují ale i jiné prezentační vzory, také Model-View-Presenter a jeho klony se těší velké popularitě (např. v ASP.NET WebForms a WPF/Silverlightu). Tyto návrhové vzory ale neřeší návrh celé aplikace, řeší jen Prezentaci. Zbytek aplikace je nazajímá – ten schovávají za písmenko MModel. Za Model se tedy v tomto případě považuje vše, co není Prezentace (front-end), tedy back-end. A právě návrhu Modelu (back-endu) bych se chtěl v tomto článku (a následujících) věnovat.

Celý příspěvek