Názory k článku
Integrované systémy pro správu kódu

"V reálné praxi bývá nutné je integrovat s dalšími nástroji pro ostatní části životního cyklu aplikací – nejčastěji se správou požadavků, bugů a úkolů, velmi často s automatickými nástroji pro vytváření buildů, někdy i se správou testovacích případů a testů."

autor je zřejmě notorický klikač, což mu neberu (taky sem si tim prošel a po přechodu do textovýho režimu se mi dost ulevilo) a nijak neshazuju kvality představovanýho řešení

v reálné praxi si obvykle vystačíte se samotným verzovacím systémem, který má všechno už integrované, případně existují extenze třtích stran

naše reálná praxe: používáme mercurial, kdyby bylo libo, tak můžeme opustit trac a přejít na http://mercurial.selenic.com/wiki/ArtemisExtension (ve skutečnosti by bylo zapotřebí artemis spřáhnout s tracem, nebo jiným frontendem, protože od testujících uživatelů neočekávam že by zadávali bugreporty v commandlajně)

buildy žádný nevytváříme (protože PHP), ale nechat automaticky pustit příkaz pro komplilaci je pořád jenom automatický puštění příkazu nahookovaný na změnu historie centrálního repository, v naší praxi na to teda máme napsanej offline bazmek (několikařádkovej .sh + cron)

" ... (integrovat) se správou testovacích případů a testů" - tohle teda moc nechápu, pro nás to sou zdrojáky jako všechny jiný, takže je verzujeme

My to děláme tak, že veškerý zdrojáky verzujeme v GITu. Nad GITem poslouchá CI server Teamcity, kterej po každým commitu do repozitáře provádí sadu různejch testů, od buildovatelnosti, checkstyle a PMD, přes validaci XML, JS a CSS po hledání zapomenutých devel url a emailů. Při commitu do stable větve se navíc celá webová aplikace poskládá, spustí a rozeběhnou se selenium testy následovaný snímkovačem ve 3 různejch prohlížečích. Nakonec běží ještě jednou sada stresstestů, který hlídaj, že se url nezačala načítat nějak podezřele dlouho. Bugy evidujeme ve flysprayi, ale neprovazujeme to nijak na verzovací systém, stojí to nezávisle. Takže nepotřebujeme žádný kompletní řešení, stačí nám zdarma GIT a Teamcity(zdarma pro malé teamy) + úlohy, co jsme si do něj sami dopsali.

no to mi vysvetlete, proc nekdo neco takhle resi kdyz vetsina dulezitych stranek je desne zabugovana, plna testovacich dat a jede odporne pomalu.

No, my se toho snažíme vyvarovat a proto taková mašinérie. Jistě to nezabrání všem problémům, ale je to jako rozdíl mezi testovat/netestovat kód.

jo, cekal bych ze na tomhle serveru budou vsichni opovrhovat TFSkem...
Ma spoustu hezkych featur ale ty jsou jeste trochu nedotazene a na zakladni veci je TFS obcas trochu drevene...
Osobne si myslim, ze git je nejlepsi co dneska mame k dispozici.

buď sem tě nepochopil, nebo nevim kdo tu (aktuálně) opovrhuje TFSkem

Delsi dobu pouzivame pro mensi tym SVN + CruiseControl.NET + MSBuild scripty. V cem by byla napriklad kombinace GIT + TeamCity(?) prinosem, pri pouziti MSDN Professional urovne ? Na TFS radsi zavislost budovat nechci, byt uznavam ze pro "drazsi" vyvoj je to asi pohodlna cesta.

Podobny problem jsem resil u MSTest versus NUnit. MSTest je sice pekne integrovany do Visual Studia a v zasade funguje (byt nenabizi nektere komfortnejsi vlastnosti NUnit, ale ty nastesti nechybi). Problem je, ze pro spusteni MSTest testu davkove na serveru je potreba tam nainstalovat cele VS :-/ V tomhle je NUnit jednoznacne vyhodnejsi.