Komentáře k článku
Integrované systémy pro správu kódu
Pro správu změn ve zdrojovém kódu se používají verzovací systémy. 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ů.
Re: 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
Re: Integrované systémy pro správu kódu
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.
Re: Integrované systémy pro správu kódu
no to mi vysvetlete, proc nekdo neco takhle resi kdyz vetsina dulezitych stranek je desne zabugovana, plna testovacich dat a jede odporne pomalu.
Re: Integrované systémy pro správu kódu
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.
Re: Integrované systémy pro správu kódu
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.
Re: Integrované systémy pro správu kódu
buď sem tě nepochopil, nebo nevim kdo tu (aktuálně) opovrhuje TFSkem
Re: Integrované systémy pro správu kódu
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.
Re: Integrované systémy pro správu kódu
A nebo použijete Github, který vám nezabírá prostor v IDE ;)