Řízení životního cyklu aplikací s Visual Studiem 2010 by Zoner Press

Řízení životního cyklu aplikací ve Visual Studiu 2010

Mickey Gousset, Brian Keller, Ajoy Krishnamoorthy, Martin Woodward

Professional Application Lifecycle Management with Visual Studio® 2010 Mickey Gousset, Brian Keller, Ajoy Krishnamoorthy, Martin Woodward Published by Wiley Publishing, Inc., 10475 Crosspoint Boulevard, Indianapolis, IN 46256, www.wiley.com. Copyright © 2010 by Wiley Publishing, Inc., Indianapolis, Indiana © Translation: ZONER software, a.s., 2010. All Rights Reserved. This translation published under license with the original publisher John Wiley & Sons, Inc. No part of this book may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording or by any information storage retrieval system, without permission from Wiley Publishing, Inc. Všechna práva vyhrazena. Tento překlad je vydán na základě licenční smlouvy s John Wiley & Sons, Inc. Žádná část této publikace nesmí být reprodukována nebo předávána žádnou formou nebo způsobem, elektronicky ani mechanicky, včetně fotokopií, natáčení ani žádnými jinými systémy pro ukládání bez výslovného svolení Wiley Publishing, Inc.

Řízení životního cyklu aplikací ve Visual Studiu 2010 Autor: Mickey Gousset, Brian Keller, Ajoy Krishnamoorthy, Martin Woodward Copyright © ZONER software, a.s. Vydání první v roce 2010. Všechna práva vyhrazena. Zoner Press Katalogové číslo: ZR1017 ZONER software, a.s. Nové sady 18, 602 00 Brno Překlad: RNDr. Jan Pokorný Odborný redaktor: Miroslav Kučera Technický redaktor: Hana Fruhwirtová Šéfredaktor: Ing. Pavel Kristián Obálka: Pavel Kristián ml. DTP: Miroslav Kučera Informace, které jsou v této knize zveřejněny, mohou být chráněny jako patent. Jména produktů byla uvedena bez záruky jejich volného použití. Při tvorbě textů a vyobrazení bylo sice postupováno s maximální péčí, ale přesto nelze zcela vyloučit možnost výskytu chyb. Vydavatelé a autoři nepřebírají právní odpovědnost ani žádnou jinou záruku za použití chybných údajů a z toho vyplývajících důsledků. Všechna práva vyhrazena. Žádná část této publikace nesmí být reprodukována ani distribuována žádným způsobem ani prostředkem, ani reprodukována v databázi či na jiném záznamovém prostředku či v jiném systému bez výslovného svolení vydavatele, s výjimkou zveřejnění krátkých částí textu pro potřeby recenzí. Veškeré dotazy týkající se distribuce směřujte na: Zoner Press ZONER software, a.s Nové sady 18, 602 00 Brno tel.: 532 190 883 e-mail: knihy@zoner.cz www.zonerpress.cz

ISBN 978-80-7413-102-8

Knihu věnuji své ženě, Amye Gousset. Zase jednou jsem měl velkou chuť psát, a ona mi opět znovu poskytla veškerou lásku a podporu, které jsem potřeboval, aby se mi to podařilo. Amye, mám Tě každý den čím dál tím víc rád. – Mickey Gousset

Knihu věnuji svým rodičům, Ray a Sue Ellen Keller, dali mi dobré základy, abych zahájil svou životní dráhu učením a měl rád technologie. Jako dítěti mi dovolili zcizit rodinný počítač, na němž jsem se učil programovat, a jako čerstvému dospělci mi dodali inspiraci, abych zkoumal své touhy i dostatečnou volnost, abych se poučil ze svých selhání. Mámo a táto, mám vás rád. – Brian Keller

Knihu věnuji svému nejlepšímu příteli, své ženě Vidhyi a našim nádherným dětem, Atulovi a Aditi. Díky za vše. – Ajoy Krishnamoorthy

Věnuji Catherine, Williamovi a Jamie. – Martin Woodward

O autorech MICKEY GOUSSET pracuje jako Senior Technical Developer pro Infront Consulting Group, což je konzultační firma soustřeďující se na rodinu produktů Microsoft System Center. Už pět let je držitelem Microsoft Team System MVP, je certifikovaným profesionálem v Team Foundation Serveru a SCOM 2007 a spoluautorem (spolu s dvěma dalšími, Jean-Luc David a Erik Gunvaldson) knihy Professional Team Foundation Server (Indianapolis: Wiley, 2006). Gousset provozuje "Team System Rocks!" (http://www.teamsystemrocks.com), což je komunitní web zasvěcený produktům Visual Studio Team System a Visual Studio 2010, kde také bloguje o Visual Studiu a Team Foundation Serveru. Je také spolukomentátorem populárního pořadu o Team Foundation Serveru, "Radio TFS" (http://www.radiotfs.com). Hovořil na téma Visual Studio a Team Foundation Server v různých diskusních skupinách, kódových kempech a konferencích, včetně Microsoft Tech Ed Developer – North America 2008 a 2009. Když ani nepíše, ani nepracuje s počítači, věnuje se Mickey některému ze svých mnoha koníčků, od hraní na Xbox Live ("Gamer Tag: HereBDragons") až po účast v místním ochotnickém divadle. Žádný z nich však nemůže překonat jeho nejmilejší zábavu – sedět na gauči s milovanou ženou Amye a jejich dvěma čivavami, Lucy a Linus. BRIAN KELLER pracuje jako Senior Technical Evangelist pro Microsoft, specializuje se na Visual Studio a správu životního cyklu aplikací. Keller pracuje u Microsoftu od roku 2002 a účastnil se mnoha konferencí po celém světě, včetně TechEd, Professional Developers Conference (PDC) a MIX. Keller je dále pravidelnou osobností na webu MSDN Channel 9 a je spolukomentátorem populární show "This Week on Channel 9". Když nepracuje, věnuje se obvykle některé z outdoorových aktivit, leze po horách, trampuje, lyžuje nebo surfuje. AJOY KRISHNAMOORTHY pracuje jako Senior Product Manager ve skupině Microsoft Patterns and Practices. V této roli se soustřeďuje na plánování v oblastech investice a obchodní strategie pro Patterns and Practices. Předtím Krishnamoorthy pracoval jako Senior Product Manager pro Microsoft Visual Studio Team System. Má více než deset let konzultačních zkušeností. Pracoval na různých pozicích, například jako vývojář, architekt a projektový manažer. Krishnamoorthy píše články pro online i tištěné časopisy a je spoluautorem několika knih o ASP.NET. Můžete také navštívit jeho blog na http://blogs.msdn.com/ajoyk. Krishnamoorthy má titul MBA z Ohio State University. Každou ušetřenou chvilku volného času tráví se svou rodinou, hraje s přáteli stolní nebo karetní hry, dívá se na sportovní přenosy (zejména hrají-li Ohio State Buckeyes) a učí se hrát "Tabla". MARTIN WOODWARD momentálně pracuje jako Program Manager pro Microsoft Visual Studio Team Foundation Server Cross-Platform Tools Team. Než se přidal k Microsoftu, byl Woodward zvolen jako Team System MVP of the Year a hovořil na mezinárodních akcích o Team Foundation Serveru. Woodward nejenže přinesl jedinečný vhled do interního fungování produktu, s nímž měl více než pětileté zkušenosti ze skutečného světa u velkých i malých firem, ale je také rád, že je může sdílet s ostatními lidmi. Když náhodou zrovna nepracuje nebo nepřednáší, najdete ho na jeho blogu, http://www.woodwardweb.com.

Poděkování Mé díky si jako první zaslouží Ajoy, Brian a Martin, že podnikli tuto cestu se mnou. Pracovalo se mi s vámi neuvěřitelně dobře a byla to pro mne opravdu skvělá zkušenost. Rád bych také poděkoval všem ve vydavatelstvích Wiley a Wrox, konkrétně chci uvést naše editory, jimiž byli Bob Elliot a Kevin Shafer. Bez jejich pomoci a neustálé pozornosti k detailům by tato kniha asi nebyla taková, jaká nakonec je. Několik úžasných lidí se také podílelo na odborných editacích knihy, patří mezi ně Clark Sell, Peter Provost, Siddharth Bhatia, Mario Rodriguez, Justin Marks, David Williamson a je mi jasné, že jsem mnohá další jména opominul. Děkuji všem, kdo mi pomohli, aby tato kniha mohla být tak skvělým produktem, jakým vskutku je. Nakonec patří obrovský dík mé rodině, že jste mě tak chápali, měli mě pořád rádi a podporovali mě i v pozdních nočních hodinách a o dlouhých víkendech, kdy jsem mizel do své kanceláře, abych psal. – Mickey Gousset

Do realizace této knihy se zapojilo tolik lidí, že člověk neví, kde začít. Asi nejfundamentálnější je práce inženýrského týmu ve vývojářské divizi Microsoftu, který má doslova neukojitelnou snahu vytvářet skvělý software, což pomáhá ostatním vývojářským týmům na celém světě realizovat plně svůj potenciál. Visual Studio 2010 je neuvěřitelně vzrušující vydání a bylo inspirací pro tuto knihu. Primárním odborným recenzentem kapitol, jimiž jsem přispěl já, byl David Williamson a jeho promyšlené návrhy a doporučení značně přispěly ke kvalitě knihy. Vypomohli mi také Anutthara Bharadwaj, Daryush Laqab, Ed Glas, Euan Garden, Gautam Goenka, Habib Heydarian, Katrina Lyon-Smith, Mark Mydland, Michael Rigler, Tanuj Vohra, Ted Malone, Vinod Malhotra a za poslední rok a půl mraky dalších. Nakonec chci poděkovat našemu vydavateli a spoluautorům, s nimiž jsem měl tu čest sdílet tento zdárný výsledek. – Brian Keller

Dlužím velký dík svému dobrému příteli, jmenuje se Jean-Luc David, že vytrval a nakonec mě přiměl k práci na této knize. Měl jsem štěstí, že jsem dostal šanci spolupracovat s tak talentovaným týmem partnerských autorů. Mickey, Briane a Martine, děkuji, spolupráci s vámi na této knize jsem si opravdu užil. Pomoc mi také nabídlo několik členů vývojového týmu Visual Studia, díky za ni, dlužím jim za mnohé. Jedná se o tyto lidi: Aaron Bjork, Siddharth Bhatia, John Socha-Leialoha, Sunder Raman, David Brokaw, Gokula Thilagar, Habib Heydarian, Justin Marks a Brad Sullivan. Všichni byli vytíženi vytvářením tohoto produktu, ale nikdy neváhali mi pomoci, když jsem je přepadl svými otázkami nebo jsem potřeboval více informací a přístup k předběžnému vydání. Chci vám všem poděkovat za vaši vždy včasnou pomoc. Poděkování si zaslouží i můj manažer John deVadoss a mí kolegové u Patterns and Practices, že mě tak skvěle podporovali a povzbuzovali v průběhu tohoto spisovatelského projektu. Nakonec chci říct, že nemohu dostatečně vyjádřit díky své rodině, která mi umožnila trávit nesčetné večerní a víkendové hodiny prací na této knize. Bez vašeho povzbuzování, podpory a pochopení bych to nikdy nedokázal. Propásl jsem také několik kol stolních her, karetních dýchánků, manželských povinností i dalších věcí. Slibuji, že udělám vše, co je v mé moci, abych to napravil. Díky za vše. – Ajoy Krishnamoorthy

6 Chci vyjádřit poděkování za pomoc, rady a asistenci, které mi poskytli lidé uvnitř i vně týmu Visual Studia Microsoftu, jmenovitě: Aaron Hallberg, Brian Randell, Buck Hodges, Clark Sell, Jim Lamb, Julie MacAller, Mario Rodriguez, Matthew Mitrik a William Bartholomew. Bez těchto lidí by moje příspěvky k této knize nebyly myslitelné. Mé díky si také zasluhují Rob Caron, Jeff Beehler, Brian Harry, Doug Neumann, Eric Sink a Corey Steffen, že po celých posledních pět let podněcovali mou angažovanost v komunitě Visual Studia. Chci také poděkovat spoluautorům, že mě vtáhli do tohoto projektu a že mi pomohli uskutečnit mou celoživotní ambici, napsat knihu. Díky si také zasluhují můj táta, Roy Woodward, a moje maminka, Val Woodward, kterou tak moc postrádám. Navedli mě na cestu směřující k počítačům tím, že mi, když mi bylo šest, dali Vic-20, a když mi bylo osm, dali mi psací stroj. S takovým startem byste čekali, že napíšu knihu o počítačích nejpozději v deseti letech, místo toho jsem znovu napsal "Krotitele duchů" a podílel jsem se jako spoluautor na románu o lesbičkách. No, mami – nakonec se mi to podařilo. Nakonec nejdůležitější dík patří mé ženě, Catherine, že mě povzbuzovala a podporovala a že mi pomáhala najít čas ještě na psaní knihy, i když toho máme jinak oba až nad hlavu. Slyšela ode mne, že "už jsem téměř hotový, jen dotáhnu ještě pár maličkostí" víckrát, než by si zasloužil kdokoli jiný, ale přesto, což je bizarní, pořád ještě nezjistila, že jí ale vůbec nejsem hoden. – Martin Woodward

Stručný obsah Část I – Architekt

Kapitola 1

Úvod do softwarové architektury

Kapitola 2

Návrh s diagramy případů užití, diagramy aktivit a sekvenčními diagramy

Kapitola 3

Návrh shora dolů s diagramy komponent a tříd

Kapitola 4

Analýza aplikací s průzkumníkem architektury

Kapitola 5

Diagramy vrstev

Část I – Vývojář

107

119

Kapitola 6

Úvod do vývoje softwaru

121

Kapitola 7

Unit testy s Unit Test Framework

125

Kapitola 8

Nástroj Managed Code Analysis a metriky kódu

163

Kapitola 9

Profilace a výkon

189

Kapitola 10

Vývoj, testování a nasazování databází

221

Kapitola 11

Úvod do IntelliTrace

261

Část III – Tester

275

Kapitola 12

Úvod do testování softwaru

277

Kapitola 13

Webové výkonové testy a zátěžové testy

297

Kapitola 14

Manuální testy

339

Kapitola 15

Kódové testy uživatelského rozhraní

361

Kapitola 16

Nástroj Lab Management

379

Část IV – Team Foundation Server

399

Kapitola 17

Úvod do Team Foundation Serveru

401

Kapitola 18

Architektura Team Foundation Serveru

425

Kapitola 19

Řízení verzí Team Foundation

441

Kapitola 20

Větvení a slučování

465

Kapitola 21

Team Foundation Build

487

Část V – Správa projektu/procesu

539

Kapitola 22

Úvod do správy projektu

541

Kapitola 23

Šablony procesu

569

Kapitola 24

Reporty, portály a dashboardy

589

Kapitola 25

Agilní plánování s plánovacími sešity

617

Kapitola 26

Přizpůsobování šablony procesu

635

Rejstřík

653

Podrobný obsah O autorech

Poděkování

Úvod

Team System – změna názvu

Seznam produktů Visual Studia 2010

Výzvy moderního softwarového vývoje

Vítejte ve Visual Studiu 2010

Řízení životního cyklu aplikace

Komu je kniha určena?

Co se v knize probírá?

Konvence

Zdrojové soubory

Sdělte nám svůj názor

Část I – Architekt

Kapitola 1

Úvod do softwarové architektury

Navrhování vizuálně

Modelovací strategie Microsoftu

Vývoj řízený modelem

Doménově specifické jazyky (DSL)

Od objektů ke službám Objekty a opětovné využívání v době kompilace

37 37

Komponenty a opětovné využívání při nasazování

Distribuované komponenty a opětovné využívání za běhu

Distribuované služby a architektura orientovaná na služby Nové architektonické nástroje ve Visual Studiu 2010 Ultimate

40 40

Diagramy případů užití

Diagramy aktivit

Sekvenční diagramy

Diagramy komponent

Diagramy tříd

Diagramy vrstev

Průzkumník architektury

Shrnutí

9 Kapitola 2

Návrh s diagramy případů užití, diagramy aktivit a sekvenčními diagramy

Diagramy případů užití

47 47

Výklad diagramu případů užití

Toolbox pro diagram případů použití

Vytvoření diagramu případů užití Diagramy aktivit

51 52

Výklad diagramu aktivit

Toolbox pro diagram aktivit

Vytvoření diagramu aktivit

Přidání diagramu aktivit k diagramu případů užití

Sekvenční diagramy

Výklad sekvenčních diagramů

Toolbox pro sekvenční diagramy

Vytvoření sekvenčního diagramu Shrnutí

Kapitola 3

61 62

Návrh shora dolů s diagramy komponent a tříd

Diagramy komponent Výklad diagramu komponent

63 64 64

Toolbox pro diagramy komponent

Vlastnosti prvků diagramu komponent

Vytvoření diagramu komponent

Zobrazení interních částí komponent

Diagramy tříd

Výklad diagramu tříd

Toolbox pro diagramy tříd

Vlastnosti typů diagramu tříd

Vlastnosti atributů diagramu tříd

Vlastnosti operací diagramu tříd

Vlastnosti asociací v diagramu tříd

Vytvoření diagramu tříd

Shrnutí

Kapitola 4

Analýza aplikací s průzkumníkem architektury

Výklad kódové báze

87 88

10 Základy práce s průzkumníkem architektury Výklad okna průzkumníka architektury

89 89

Volby průzkumníka architektury

Navigace po průzkumníku architektury

Průzkum voleb pro jmenné prostory

Průzkum voleb pro třídy

Průzkum voleb pro členy

Dotazy průzkumníka architektury

Grafy závislostí

Vytvoření prvního grafu závislostí

Vytvoření grafu závislostí bez průzkumníka architektury

100

Navigace po závislostním grafu

101

Legenda grafu závislostí

103

Panel nástrojů závislostního grafu

105

Shrnutí

Kapitola 5

106

Diagramy vrstev

Vytvoření diagramu vrstev Definování vrstev v diagramu

107 108 109

Vytvoření vrstvy pro jediný artefakt

110

Přidávání několika objektů najednou do diagramu vrstev

110

Průzkumník vrstev

111

Definice závislostí

112

Validace diagramu vrstev

114

Diagramy vrstev a sestavovací proces

116

Shrnutí

117

Část II – Vývojář Kapitola 6

Úvod do vývoje softwaru

Co je ve Visual Studiu 2010 nového pro vývojáře

119 121 122

Analýza dopadů změn

122

Zdokonalená kódová analýza

122

Posílení profileru

123

Databázová rozšiřitelnost

123

Pokročilé ladění s IntelliTrace

123

11 Zdokonalení při práci ve stylu "nejprve testy" Shrnutí

Kapitola 7

123 124

Unit testy s Unit Test Framework

Pojetí unit testů Výhody plynoucí z unit testů

125 126 126

Psaní efektivních unit testů

127

Nástroje jiných firem

128

Unit testy Visual Studia

128

Vytvoření prvního unit testu

129

Správa a spouštění unit testů

131

Konfigurace testovacího běhu

134

Výsledky testů

135

Ladění unit testů

135

Programování s Unit Test Framework

136

Inicializace a úklid unit testů

136

Metody třídy Assert

139

Třída CollectionAssert

142

Třída StringAssert

143

Očekávané výjimky

144

Definování vlastních vlastností unit testů

145

Třída TestContext

145

Vytváření unit testů řízených daty

146

Přístup k neveřejným členům z testů

147

Přístup k neveřejným členům instance s PrivateObject

147

Přístup k neveřejným statickým členům s PrivateType

150

Generování kódu Generování testů z kódu Pokrytí kódu

151 151 154

Aktivace pokrytí kódu

154

Prohlížení výsledků pokrytí kódu

155

Analýza dopadů změn

156

Nezbytné předběžné předpoklady analýzy dopadů změn

156

Identifikace vztahů mezi kódem a testy

157

Konkrétní příklad analýzy dopadů změn

159

Shrnutí

162

12 Kapitola 8

Nástroj Managed Code Analysis a metriky kódu

163

Potřeba analytických nástrojů

164

Nástroj Managed Code Analysis

164

Zabudovaná pravidla nástroje Managed Code Analysis

165

Sady pravidel kódové analýzy

167

Jak se zapne nástroj Managed Code Analysis

167

Spuštění statické kódové analýzy

169

Náprava porušení pravidel Kódová analýza z příkazového řádku

170 174

Volby FxCopCmd

174

Projektové soubory FxCopCmd

177

Zabudování kódové analýzy do sestavovacího procesu

178

Vytváření pravidel kódové analýzy Reflexe a introspekce Vytvoření nového pravidla

178 178 179

Metriky kódu

186

Shrnutí

187

Kapitola 9

Profilace a výkon

Úvod do analýzy výkonu

189 190

Typy profilerů

190

Profilace ve Visual Studiu

190

Používání profileru

191

Vytvoření ukázkové aplikace

191

Vytvoření výkonové relace

193

Průzkumník výkonu

196

Konfigurace vzorkovací relace

203

Konfigurace instrumentační relace

205

Konfigurace relace pro profilování alokace paměti .NET

206

Konfigurace relace profilující souběžnost

206

Spuštění výkonové relace

206

Správa reportů relace

207

Čtení a interpretace reportů relace

208

Profilační utility příkazového řádku

216

Virtuální stroje

217

Profilace JavaScriptu

217

Show Just My Code (Zobraz pouze můj kód)

219

13 Běžné potíže při profilaci Ladicí symboly Instrumentace a pokrytí kódu Shrnutí

Kapitola 10

219 219 220 220

Vývoj, testování a nasazování databází

221

Výzvy správy databázových změn

222

Offline vývoj schématu

223

Offline reprezentace schématu

223

Iterační vývoj

224

Testování schématu

225

Sestavení a nasazení do ostrého provozu

226

Vytvoření databázového projektu

226

Prozkoumání databázového projektu

232

Průzkumník řešení versus zobrazení schématu

232

Prohlížeč závislostí schématu

232

Struktura souborů T-SQL

234

Vytváření změn ve schématu

235

Přímá editace souborů T-SQL

235

Detekce syntaktických chyb ve schématu

235

Refaktorace databáze

236

Šablony skriptů T-SQL

239

Nasazování databázových změn

240

Generování dat

243

Plán generování dat

244

Generátory dat

245

Testování databáze

246

Funkce, triggery a uložené procedury

246

Psaní pokročilých databázových unit testů

249

Efektivní testování databáze

250

Statická analýza T-SQL

252

Dodatečné databázové nástroje Shrnutí

Kapitola 11

255 259

Úvod do IntelliTrace

261

Ladění s IntelliTrace

261

Volby pro ladění

262

14 Zaznamenávání událostí

265

Ladění a přehrávání

266

Nové schopnosti bodů přerušení

270

Sdílení bodů přerušení

270

Jmenovky pro body přerušení

271

Datové tipy, které se mohou přišpendlovat

271

Shrnutí

274

Část III – Tester Kapitola 12

Úvod do testování softwaru

275 277

Testovací nástroje založené na rolích

278

Typy testů

278

Diagnostické datové adaptéry

279

Nástroj Microsoft Test Manager

281

Správa automatizovaných testů s VisuaI Studiem

282

Testovací projekty

283

Kategorie testů

285

Práce s výsledky testu

287

Uspořádané testy

290

Testovací nastavení

293

Zobrazení dopadů změn na testy

294

Shrnutí

Kapitola 13

295

Webové výkonové testy a zátěžové testy

Webové výkonové testy Webové výkonové testy versus kódové testy UI

297 298 298

Vytvoření ukázkové webové aplikace

299

Vytvoření uživatelů pro web

299

Tvorba a konfigurace webových testů

301

Nahrání webového výkonového testu

302

Konfigurace nastavení pro běh webového výkonového testu

303

Parametrizace webového serveru

304

Testovací nastavení

305

Spuštění webového výkonového testu

307

15 Pozorování testovacího běhu a výsledků testů

307

Editace webového výkonového testu

308

Webové výkonové testy řízené daty

312

Kódové webové výkonové testy

314

Zátěžové testy

317

Tvorba a konfigurace zátěžových testů

317

Editace zátěžových testů

326

Spouštění zátěžových testů

328

Prohlížení a interpretace výsledků zátěžového testu

329

Spuštění testu z příkazového řádku

333

Spouštění testů

333

Spouštění seznamů testů

333

Další volby pro test

333

Distribuované zátěžové testy

334

Instalace kontrolerů a agentů

334

Konfigurace kontrolerů

335

Konfigurace agentů

335

Testovací nastavení

336

Spuštění distribuovaného zátěžového testu

337

Prohlížení distribuovaného zátěžového testu

337

Shrnutí

Kapitola 14

337

Manuální testy

339

Nástroj Microsoft Test Manager

339

Testovací plány

340

Konfigurace testovacích nastavení

342

Různá sestavení a jak je používat

344

Analýza dopadů změn

345

Definice testovacích konfigurací

345

Obsahy plánu

346

Spuštění testů a sledování výsledků

351

Nástroj Microsoft Test Runner

352

Podporované technologie

356

Uchovávání výsledků testu

356

Spouštění automatizovaných testů

357

Shrnutí

359

16 Kapitola 15

Kódové testy uživatelského rozhraní

Vytváření kódových testů UI s Coded UI Test Builder

361 362

Příprava ukázkové aplikace

362

Vytvoření testovacího projektu

363

Přidání kódového testu UI

363

Nástroj Coded UI Test Builder

364

Vygenerovaný kód

367

Spuštění testu

369

Vytváření testů řízených daty

370

Používání klauzule using()

373

Rozšíření oznamovaných informací o predikátech

374

Vytváření kódových testů z nahrávek akcí

374

Podporované technologie

378

Shrnutí

378

Kapitola 16

Nástroj Lab Management

Infrastruktura Lab Management

379 380

Golden Images

380

Agenti

381

Virtuální prostředí

381

Testování s virtuálními prostředími

388

Vytvoření nových testovacích nastavení

388

Spouštění ručních testů s prostředím

391

Automatizovaný proces "sestavení-nasazení-testování" s virtuálními prostředími

394

Fyzická prostředí

397

Shrnutí

398

Část IV – Team Foundation Server Kapitola 17

Úvod do Team Foundation Serveru

399 401

Co je Team Foundation Server?

401

Klíčové koncepty Team Foundation Serveru

402

Aplikační vrstva Team Foundation

402

Kolekce týmových projektů

403

Týmový projekt

404

17 Šablona procesu

406

Sledování pracovních položek

408

Řízení verzí

409

Týmová sestavení

411

Přístup k Team Foundation Serveru

412

Přístup k Team Foundation Serveru z Visual Studia

413

Správní konzola Team Foundation Serveru

415

Přístup k Team Foundation Serveru prostřednictvím webového prohlížeče

415

Team Foundation Server v Excelu

416

Team Foundation Server v aplikaci Microsoft Project

417

Nástroje příkazového řádku pro Team Foundation Server

418

Přístup k Team Foundation Serveru z Eclipse

418

Integrace průzkumníka Windows s Team Foundation Serverem

419

Přístup k Team Foundation Serveru přes integrace jiných firem

420

Co je nového v Team Foundation Serveru 2010

420

Správa projektu

420

Řízení verzí

421

Sestavování

421

Administrace

421

Zavedení Team Foundation Serveru Hosting Team Foundation Serveru Zaváděcí plán Shrnutí

Kapitola 18

422 422 422 423

Architektura Team Foundation Serveru

Logická architektura Team Foundation Serveru

425 426

Kolekce týmových projektů

428

Team Foundation Server Farm

429

Aplikace Team Foundation Server

430

Instance Team Foundation Serveru

431

Fyzická architektura

431

Nároky na hardware

432

Požadovaný software

433

Nasazovací scénáře

434

Jednotlivci a malé týmy

435

Menší firmy

435

Velké korporace

436

18 Hostovaná prostředí

437

Upgrade ze starších verzí Team Foundation Serveru

438

Shrnutí

Kapitola 19

440

Řízení verzí Team Foundation

Řízení verzí Team Foundation a Visual SourceSafe 2005 Příprava systému řízení verzí

441 442 443

Příprava bezpečnostních rolí

443

Příprava pracovního prostoru

444

Průzkumník řízení zdrojového kódu

445

Vytvoření pracovního prostoru

447

Přidávání projektů do depozitáře zdrojového kódu

450

Nahlašování a odhlašování

451

Nahlášení položky

451

Odhlášení položky

452

Vytváření a správa zásad nahlašování

453

Prohlížení historie

455

Jmenovky

456

Ukládání do regálů

457

Větvení a slučování

458

Větvení

459

Slučování

461

Nástroje příkazového řádku

463

Shrnutí

464

Kapitola 20

Větvení a slučování

Co je větvení a slučování Správa konfigurace softwaru

465 466 466

Základní definice

466

Běžné strategie větvení

467

Žádné větve

467

Nová větev při každém vydání

468

Nová větev při nové úrovni kódu

468

Nová větev pro každou funkci

469

Základní plán větvení

470

Scénář

470

Plán

471

19 Implementace

472

Pokročilý plán větvení

484

Scénář

484

Plán

485

Implementace

486

Shrnutí

Kapitola 21

486

Team Foundation Build

Team Foundation Build Co je nového v Team Foundation Build 2010

487 488 489

Windows Workflow 4.0

490

Nahlašování přes bránu (gated check-ins)

491

Privátní sestavování

491

Kontroler sestavení

491

Oznamování informací o sestavení

492

Vlastnosti vystavené pro společná přizpůsobování

492

Integrace se symbolovým serverem a zdrojovým serverem

492

Rozšířené volby pro odstraňování sestavení

493

Architektura sestavení Team Foundation

493

Práce se sestaveními

495

Průzkumník týmu

495

Průzkumník sestavení

495

Zobrazení podrobností o sestavení

497

Vytvoření definice sestavení

498

Zařazení sestavení do fronty

506

Notifikační systémy

508

Proces týmového sestavení

509

Proces DefaultTemplate

510

Parametry sestavovacího procesu

511

Přizpůsobování sestavovacího procesu

518

Shrnutí

538

Část V – Správa projektu/procesu Kapitola 22

Úvod do správy projektu

Příprava a konfigurace týmového projektu

539 541 542

20 Vytvoření týmového projektu

543

Připojení k Team Foundation Serveru

547

Plánování projektu

549

Vše je v pracovních položkách

550

Co je pracovní položka

550

Propojování pracovních položek a typy propojení

552

Vytváření a aktualizace pracovních položek

554

Dotazy pracovní položky

556

MS Office v součinnosti s Team Foundation Serverem

559

Projekt Office a Team Foundation Server

560

Office Excel a Team Foundation Server

564

Shrnutí

Kapitola 23

567

Šablony procesu

569

Co je šablona procesu

570

Hotové šablony procesu

571

Šablona MSF for Agile Software Development

571

Šablona MSF for CMMI Process Improvement v5.0

582

Šablony partnerů a komunity

587

Shrnutí

588

Kapitola 24

Reporty, portály a dashboardy

Reporty Team Foundation Serveru

589 590

Operační datový sklad Team Foundation Serveru

591

Hlavní datový sklad Team Foundation Serveru

591

OLAP krychle Team Foundation Serveru

592

Práce s reporty Team Foundation Serveru Nástroje pro vytváření reportů

593 593

Práce s reporty Microsoft Excelu

594

Práce s RDL reporty

606

Hotové reporty

608

Projektové portály a dashboardy Shrnutí

Kapitola 25

612 616

Agilní plánování s plánovacími sešity

Soupis zákaznických požadavků na produkt

617 618

21 Plánování vydání Sešit pro plánování produktu

618 620

Umístění sešitu pro plánování produktu

620

Příprava sešitu pro plánování produktu

620

Práce s kalkulační tabulkou soupisu zákaznických požadavků

622

Práce s kalkulační tabulkou iterací

624

Práce s kalkulační tabulkou přerušení prací

625

Plánování iterace

625

Sešit pro plánování iterace

626

Umístění soupisu požadavků na iteraci

627

Práce s kalkulační tabulkou soupisu požadavků na iteraci

628

Práce s kalkulační tabulkou pro plánování kapacit

630

Sledování iterace

632

Problémy

632

Retrospektivy

632

Shrnutí

Kapitola 26

633

Přizpůsobování šablony procesu

Přizpůsobování šablon procesu

635 636

Stažení šablony procesu na plochu

636

Co je v šabloně procesu?

636

Pluginy šablony procesu Nástroje pro přizpůsobování šablon procesu

638 640

Editor XML

640

Utilita witadmin příkazového řádku

642

Editor šablony procesu

642

Nahrávání šablon procesu do Team Foundation Serveru

651

Odstraňování šablon procesu

651

Přizpůsobování směrnic procesu

652

Shrnutí

652

Rejstřík

653

Úvod V červnu 1999 začali u Microsoftu znovu vyhodnocovat, jak se v rámci procesu vývoje softwaru používalo Visual Studio. Ačkoliv společnost Microsoft neustále respektovala potřeby samostatných programátorů, například prostřednictvím vysoce produktivních schopností Visual Studia, které umožňovaly rychlejší vývoj aplikací, už tak moc nepomáhala programátorům, aby mohli spolupracovat jako tým. A co takhle softwaroví architekti – jak ti mají spolupracovat s programátorským týmem? A co testeři? Projektoví manažeři? Mnohé týmy proto začaly připravovat vlastní řešení, která byla typicky tvořena směsicí vlastních nástrojů a nástrojů od jiných firem, aby bylo možné se vypořádat s takovými výzvami, jako jsou řízení verzí, sledování chyb a týmová komunikace. Takový mix všelijakých nástrojů se ovšem obtížně konfiguruje i udržuje (a ještě hůře integruje). Společnost Microsoft se snažila s touto výzvou vypořádat tím, že poskytla integrovanou sadu nástrojů navržených tak, aby uspokojovaly potřeby celého týmu vyvíjejícího software. Došlo ke zrození produktu Visual Studio Team System, který byl poprvé vydán v rámci produktové řady Visual Studio 2005. Team System byl vybudován ze základny nástrojů a technologií, kterou u Microsoftu interně používali už mnoho let při budování některých z nejsložitějších softwarových projektů, do nichž se kdy pustili. Týmového systému se nedožadovali jen programátoři, ale také všichni ostatní členové vývojového týmu – architekti, vývojáři aplikací, databázoví vývojáři, testeři i manažeři projektů. Produkt Team System byl vybudován tak, aby se dokázal vypořádat s kompletním životním cyklem vývoje softwaru, spíše známého pod názvem řízení životního cyklu aplikace (Application Lifecycle Management, ALM). O tři roky později prodělal Visual Studio 2008 Team System evoluční vývoj z předchozí verze a zahrnoval ještě více nástrojů a funkcionality pro potřeby všech členů projektového týmu.

Team System – změna názvu Pozorní čtenáři si už jistě povšimli, že nikde v názvu této knihy se neobjevují slova Team System. A kromě výše uvedené stručné historie, kterou jste si právě přečetli, už nikde jinde v knize slova Team System neuvidíte. Co špatného se přihodilo "týmovému systému"? Microsoft podnikl jisté šetření a zjistil, že vytvořením dvou produktů, které obsahovaly spojení "Visual Studio", dosáhl jistého zmatení zákazníků, kteří moc dobře nevěděli, čím se oba tyto produkty od sebe liší. Produkt s označením Visual Studio měl být na pozici základního nástroje pro vývojáře, zatímco produkt Visual Studio Team System byl zamýšlen jako sada nástrojů pro týmy vyvíjející software. Vývojářská praxe je ovšem taková, že téměř všichni profesionální vývojáři pracují v týmech a uvedení samostatného produktu s označením "Team System" nikdo moc dobře nechápal. Microsoft se po těchto zjištěních rozhodl upustit od názvu "Team System" a zkonsolidovat všechno do jediné sjednocené rodiny pod značkou Visual Studio. Existují ještě další pragmatičtější důvody, proč k této změně došlo. Ale ať už je to tak či onak, v následujícím seznamu produktů Visual Studia 2010 už nenajdete slovní spojení "Team System", nicméně produkty a technologie, které toto označení zahrnovalo, jsou pořád k dispozici (a jsou lepší než kdykoliv předtím).

Seznam produktů Visual Studia 2010 Pohled na nové členění produktů Visual Studia 2010 je uveden v tabulce 1.

23 Tabulka 1. Soupiska produktů Visual Studia 2010. Název produktu

Popis

Microsoft Visual Studio 2010 Ultimate s MSDN

Vyčerpávající sada nástrojů pro řízení životního cyklu aplikace. Je určena pro softwarové týmy a měla by zaručit kvalitní výsledky od návrhu až po nasazení.

Microsoft Visual Studio 2010 Premium s MSDN

Kompletní sada nástrojů, s jejíž pomocí budou moci vývojáři doručovat škálovatelné, vysoce kvalitní aplikace.

Microsoft Visual Studio 2010 Professional s MSDN

Postačující nástroj pro základní vývojové úlohy. Má za úkol asistovat vývojářům tak, aby byli schopni snadno implementovat své myšlenky a nápady.

Microsoft Visual Studio Test Professional 2010 s MSDN

Prvořadý nástroj pro manuální testery a testery generalisty, kteří potřebují definovat a spravovat testovací případy, spouštět testovací běhy a sledovat chyby. Produkt Test Professional zahrnuje také manažera testů (Microsoft Test Manager), se kterým se blíže seznámíte v kapitole 14.

Microsoft Visual Studio Team Foundation Server 2010

Serverová komponenta pro týmový vývoj, řízení verzí, sledování pracovních položek, automatizaci sestavování a tvorbu reportů.

Microsoft Visual Studio Lab Management 2010

Nástroje pro podporu virtuálních laboratoří, má zajistit lepší spolupráci vývojářů a testerů, když se dá dohromady s ostatními nástroji Visual Studia.

Visual Studio 2010 Premium zahrnuje veškerou funkcionalitu edice Visual Studio 2010 Professional. Edice Visual Studio 2010 Ultimate zahrnuje veškerou funkcionalitu Visual Studia 2010 Premium (včetně edice Professional). Podrobnější pohled na funkcionalitu obsaženou v jednotlivých edicích Visual Studia 2010 by vám měla poskytnout tabulka 2. Tabulka 2. Funkcionalita jednotlivých edic Visual Studia 2010. Edice Visual Studia

Funkcionalita

Český název

Microsoft Visual Studio 2010 Ultimate

IntelliTrace

Unified Modeling Language (UML)

Unifikovaný modelovací jazyk

Architecture Explorer

Průzkumník architektury

Logical class designer

Návrhář logické třídy

Test case management

Správa testovacího případu

Manual testing

Manuální testování

Test record and playback

Zaznamenávání a přehrávání testu

Layer diagrams

Diagramy vrstev

Web performance testing

Webové výkonové testy

Load testing

Zátěžové testy

24 Edice Visual Studia

Funkcionalita

Český název

Microsoft Visual Studio 2010 Premium

Coded user interface (UI) testing

Kódové testy uživatelského rozhraní

Performance profiling

Profilace výkonu

Code coverage

Pokrytí kódu

Database change management

Správa databázových změn

Database unit testing

Databázové unit testy

Test impact analysis

Analýza dopadů změn

Static code analysis

Statická kódová analýza

Code metrics

Kódové metriky

Database deployment

Nasazování databází

Test data generation

Generování testovacích dat

Silverlight development

Vývoj se Silverlightem

Web development

Webový vývoj

Windows Presentation Foundation (WPF) development

Vývoj s Windows Presentation Foundation

Multi-core development

Vývoj s více jádry

Cloud development

Vývoj s cloud computing

Windows Forms development

Vývoj s formuláři Windows

Office development

Vývoj s Office

Customizable IDE

Přizpůsobitelné integrované vývojové prostředí

Microsoft Visual Studio 2010 Professional

Tato kniha se soustřeďuje na funkcionalitu, která je obsažena v edicích Visual Studio 2010 Premium a Visual Studio 2010 Ultimate.

Výzvy moderního softwarového vývoje Softwaroví vývojáři sdílejí řadu společných výzev, bez ohledu na to, jak velké jsou jejich týmy. V byznysu se dnes požaduje vysoký stupeň zodpovědnosti – software se musí vyvinout za co nejkratší dobu a typicky nejsou k dispozici žádné rezervy pro případné výpadky. Mezi tyto výzvy patří zejména: Integrační problémy. Většina nástrojů, které běžně používají týmy vyvíjející software, pocházejí od ji-

ných výrobců. Integrace s těmito nástroji může klást velké výzvy – v mnoha případech požaduje duplikovat nebo kopírovat data na více systémů. Každá aplikace má svou křivku učení a přenos informací z jedné aplikace do jiné nekompatibilní aplikace může být frustrující (a zabrat hodně času).

25 Geograficky distribuované týmy. Mnohé nástroje, které jsou určeny pro vývoj a správu aplikací, neu-

mí škálovat pro geograficky zaměřené týmy. Získat přesné reporty bývá obtížné – nehledě na nevalnou podporu komunikačních nástrojů a nástrojů určených pro spolupráci. Výsledkem je, že požadavky a specifikace mohou být zmapovány nesprávně, což vede ke zpožďování práce a zanášení všelijakých chyb. Globální týmy požadují, aby solidní návrh, postup vývoje i správa softwarové konfigurace byly integrovány do jediného balíku. Není ale mnoho softwarových balíků, které nabízejí všechny tyto schopnosti, a ty, které existují, bývají obvykle až neuvěřitelně drahé. Segmentace rolí. Specializace může být v týmu obrovským problémem. Experti mohou sice předpo-

kládat, že ostatní divize budou vnímat informace, které nejsou uvedené ve stavových reportech, mohou ale značně ovlivnit projekt jako celek. Vzájemná komunikace mezi divizemi je často velká výzva. Špatná tvorba reportů. Tohle je dědictví segmentačního problému. Ve většině případů musí reporty

generovat ručně každý tým, což má za následek pokles produktivity. Nejsou k dispozici žádné účinné nástroje, které by uměly agregovat všechna data z mnoha zdrojů. Výsledkem je, že vedení projektu nemá k dispozici taková data, aby mohlo činit správná a efektivní rozhodnutí. Není zdokumentováno, jak má tým postupovat při řešení projektu, chybějí směrnice procesu

(process guidance). Programátorské styly vývoje na jedno použití neškálují. Pokud pravidelně vnášíte do kódu nějaké změny, mohou se kaskádovitě rozrůst do závažných problémů, které mohou vyžadovat hodiny i dny práce. Současný software má vysokou úroveň závislostí. Bohužel, většina nástrojů nemá podporu pro směrnice procesu a jejich vynucování. To vede k neshodám mezi nástroji a postupy. Testování jako občan druhé kategorie. Kratší cykly a to, že se netestuje, může v pozdějších fázích po-

stupu způsobit významné chyby v kódu. Výrobci softwarových vývojových nástrojů téměř kompletně opomíjejí manuální testery. Výsledkem nevalné spolupráce mezi vývojáři a testery jsou často závady v softwaru a vyplýtvání značného úsilí při postupech dopředu a zase zpátky. Komunikační problémy. Většina firem odesílá informace členům týmu pomocí mnoha komunikač-

ních metod (elektronická pošta, instant messaging, rychlé poznámky, vzkazy na samolepkách). Pokud nejste dost pečliví, útržek papíru snadno ztratíte nebo vyhodíte, důležitou zprávu elektronické pošty můžete omylem smazat. Není mnoho centralizovaných systémů pro správu týmové komunikace. Proto se často musejí konat časově náročné schůze, aby tým mohl zůstávat v obraze, a zavádí se mnoho ručních postupů (jako je odesílání elektronické pošty či vyjímání/vkládání reportů přes schránku). Problém v zásadě spočívá v tom, že mezi nástroji a vedením projektu neexistuje žádná komunikace. Firmy si samy zavádějí metodologie a praktiky, aby zjednodušily a zorganizovaly proces návrhu softwaru, tyto metodologie ale musejí být vyvážené. Cílem je učinit celý proces předvídatelným, protože v předvídatelném prostředí udržují metodologie projekty stále na kolejích a zaručují, že nesjedou ze své cesty. Metodologie ovšem také přidávají do procesu nové úlohy (jako je generování reportů). Jestliže vývojáři tráví příliš mnoho času prací na těchto úlohách, bude jejich produktivita nižší a firma bude méně konkurenceschopná.

Vítejte ve Visual Studiu 2010 Řízení životního cyklu aplikace (application lifecycle management) je koncept, který v sobě zahrnuje řízení všech fází života projektu vývoje softwaru. Schopnosti Visual Studia 2010 pro řízení životního cyklu aplikace vychází z dřívějších produktů Visual Studio 2005 Team System a Visual Studio 2008 Team System a byly navrženy tak, aby zmírnily – nebo zcela eliminovaly – mnohé ze zmíněných výzev. Schopnosti Visual Studia 2010 pro správu životního cyklu aplikace lze stručně charakterizovat třemi zásadními principy, kterými jsou produktivita (productivity), integrace (integration) a rozšiřitelnost (extensibility).

26 Produktivita se zvyšuje takto: Spolupráce. Veškerá týmová spolupráce je centralizována v Team Foundation Serveru. Chyby, po-

žadavky, úlohy, testovací případy, zdrojový kód, sestavení – tohle všechno se řídí/spravuje přes Team Foundation Server 2010. Jsou centralizované i veškeré záležitosti okolo reportů, takže vedení projektu může snadno sledovat úhrnný postup prací na projektu, bez ohledu na to, odkud přicházejí metriky. Správa složitosti. Projekty vývoje softwaru jsou dnes složitější než kdy jindy, a rok od roku se jejich

složitost ještě zvyšuje. Team Foundation Server pomáhá se správou této složitosti tím, že centrálně sleduje a eviduje veškerý proces vývoje softwaru a zajišťuje, že celý tým neustále vidí, jaký je momentální stav a pracovní tok (workflow) projektu. A navíc – některé nástroje, jako třeba architektonické nástroje dodávané s Visual Studiem 2010 Ultimate, pomáhají redukovat složitost aplikací tím, že poskytují takové návrhy, které se dají využít k vizuálnímu reverznímu inženýrství existujících kódových bází. Integrace se zdokonaluje takto: Integrované nástroje. Usnadňují komunikaci mezi divizemi, a co je možná ještě důležitější, odstraňují

nedostatek informací. S rodinou produktů Visual Studio 2010 se neintegruje až dodatečně – integrace je klíčovým návrhářským požadavkem na sadu nástrojů. Transparentnost. Visual Studio 2010 a Team Foundation Server zvyšují transparentnost prací na pro-

jektu. Protože vedení projektu se snadno dostane k metrikám vztahujícím se k projektu, může se aktivněji vypořádávat s problémy tím, že identifikuje vzory a trendy. Rozšiřitelnost se poskytuje takto: API služeb jádra Team Foundation (Team Foundation Core Services). Většina platformy je vysta-

vena vývojářům, poskytuje spoustu příležitostí pro rozšiřitelnost a vytváření vlastních nástrojů, které budou integrovány s Team Foundation Serverem. Integrované vývojové prostředí (IDE). I samotné IDE Visual Studia 2010 je rozšiřitelné. Jiným fir-

mám a koncovým uživatelům umožňuje přidávat všechno možné – od vybavování dodatečnými nástroji až ke kompilátorům nových jazyků pro vývojové prostředí.

Řízení životního cyklu aplikace To, jak může Visual Studio 2010 pomoci s řízením životního cyklu aplikace, si nejlépe předvedeme tak, že si popíšeme scénář fiktivní firmy vyvíjející software s názvem eMockSoft. eMockSoft nedávno podepsala partnerství s jistým distributorem, aby vydal katalog jejích produktů. Distributor pro přenos inventáře a informací o cenách interním a externím partnerským organizacím požaduje nějakou bezpečnou webovou službu. Podívejme se na tento scénář z hlediska řízení životního cyklu aplikace a nástrojů Visual Studia 2010.

Požadavky Projektový manažer se setkává s klientem, aby obdržel požadavky na projekt. Tyto požadavky sdělují vývojovému týmu, co všechno sponzor projektu očekává, že bude v softwaru k dispozici. Projektový manažer může uložit tyto požadavky do Team Foundation Serveru libovolným nástrojem, který si vybere (Visual Studio, Excel či Microsoft Project). Klient může s portálem týmového projektu založeného na SharePointu tyto požadavky ověřovat a sledovat. Tento portál, který vytvoří Team Foundation Server, umí vytahovat reporty a další artefakty, které jsou uloženy v Team Foundation Serveru, a umisťovat je na web, který je založen na SharePointu. Architekt infrastruktury může v tuto chvíli začít pracovat na návrhu systému.

27 Návrh systému a modelování Architekt infrastruktury může nyní na základě specifikací od klienta definovat externí webovou službu, a to prostřednictvím nových nástrojů UML (unifikovaného modelovacího jazyka) Visual Studia 2010. Mezitím může projektový manažer sledovat, jak postupuje tvorba návrhů, též pomocí diagramů, které se vygenerovaly. Na základě specifikací pak může projektový manažer začít členit práci do úloh (také uložených v Team Foundation Serveru), aby se mohly přiřadit vývojářům týmu.

Generování kódu Vývojář obdrží pracovní zadání úloh a přezkoumá diagramy UML, které navrhl architekt. Vývojář zkontroluje specifikace – tato konkrétní aplikace požaduje bezpečnou webovou službu používající Web Services Enhancements (WSE) 3.0. Vývojář vytvoří nezbytný kód a udělá několik předběžných testů pomocí statické kódové analýzy a nástrojů pro unit testy, vše je zabudované ve Visual Studiu 2010. V průběhu dne vývojář předá kód a testy do Team Foundation Serveru 2010.

Testování Tester kontroluje postup prací vývojového týmu tím, že monitoruje jednotlivá noční sestavení a automatizované testy. Každé noční sestavení prostřednictvím Visual Studio Lab Management 2010 spouští automatické vytvoření virtuálního stroje, který je každé ráno připravený pro testera, takže s ním může začít hned testovat. Tester pracuje s Visual Studio Test Professional 2010 a každý den autorizuje, spravuje a vykonává sadu manuálních testovacích případů, aby pro vývojový tým odhalil potenciální chyby. Pokud tester najde chybu, zaznamená ji v Team Foundation Serveru, který ji přiřadí vývojáři, aby ji opravil. V Team Foundation Serveru se ukládají všechny reporty o chybách. Díky tomu je možné poskytovat členům týmu a klientům/sponzorům plnou transparentnost, co se týče postupu prací na projektu.

Dejme to do kontextu knihy Tohle byl jen jednoduchý příklad, ve kterém jsem prozkoumali pouze několik z mnoha způsobů, jimiž může Visual Studio 2010 asistovat při řízení životního cyklu aplikace. Během čtení této knihy objevíte další příklady, které mohou pomoci vašeho vývojovému týmu, aby byl soudržnější a vytvářel lepší software.

Komu je kniha určena? Tato kniha je především zacílena na týmy profesionálů pracujících v oblasti vývoje komerčního softwaru nebo softwaru pro velké korporace – jinak řečeno, pro středně pokročilé až pokročilé uživatele. Kniha bude pro vás prospěšná, jste-li: Vývojář, tester nebo architekt a chcete se dozvědět, jak vám může rodina produktů Visual Studio 2010

pomoci při práci. Projektový manažer, který má na starost správu nějakého projektu vývoje softwaru.

Kniha není navržena pro úplné začátečníky. Soustřeďuje se na praktické používání nástrojů, ukázkových příkladů kódu a praktických scénářů. Kniha je uspořádana tak, že se s ní snadno pracuje ve stylu "krok za krokem" nebo jako s referenční příručkou pro modelování, navrhování, testování a koordinování korporačních řešení (a to na všech úrovních).

28 Visual Studio 2010 je navrženo pro softwarové týmy všech velikostí. Takže – ať už je vás v týmu pět nebo dva tisíce, kniha obsahuje pro všechny z vás užitečné informace o Visual Studiu 2010 a o řízení životního cyklu aplikace. Na rozdíl od většiny dostupných knih je tato kniha zacílena na všechny role při organizování vývoje softwaru – architekty, vývojáře, testery, vedení projektu a management – nikoliv pouze na vývojáře.

Co se v knize probírá? Kniha obsahuje úplný přehled schopností Visual Studia 2010 pro řízení životního cyklu aplikace. Je rozdělena do pěti hlavních částí podle rolí v týmu vyvíjejícího software: Část I – Architekt. Část II – Vývojář. Část III – Tester. Část IV – Team Foundation Server. Část V – Správa projektu/procesu.

Část I – Architekt V této části knihy se prozkoumávají nástroje dostupné ve Visual Studiu 2010, které se vztahují k roli architekta. Po stručném úvodu do pojmů souvisejících s architekturou se ponoříme do všech nových nástrojů unifikovaného modelovacího jazyka (UML), včetně diagramů případů užití, diagramů aktivit, sekvenčních diagramů, diagramů tříd a diagramů komponent. Poté se seznámíte s průzkumníkem architektury a dozvíte se, jak pomáhá porozumět architektuře aplikace. Tato část končí výkladem diagramů vrstev.

Část II – Vývojář V této části se probírají všechna témata, která jsou ve středu zájmů vývojářů vytvářejících aplikace s Visual Studiem 2010. Unit testy, refaktorace, statická kódová analýza a pokrytí kódu, to všechno se probírá do detailu. Probírají se také schopnosti, s jejichž pomocí se vyvíjejí, testují a nasazují databázové aplikace. Nechybí ani pokročilé techniky ladění aplikací prostřednictvím nové funkcionality IntelliTrace.

Část III – Tester Visual Studio 2010 má četné nástroje pro testery, a v této části je probereme všechny. Výklad zahájíme pohledem na webové výkonové testy a na zátěžové testy. Pak probereme novou funkcionalitu manuálního testování a schopnosti umožňující automatizovat testy uživatelského rozhraní. Tato třetí část knihy je zakončena pohledem na nové vybavení Visual Studia 2010 zvané Lab Management, které umožňuje automaticky spřádat s virtuálními stroji testovací prostředí, v nichž se pak vykonávají testy.

Část IV – Team Foundation Server Tato část je celá o schopnostech, které poskytuje Team Foundation Server. Probereme novou architekturu Team Foundation Serveru 2010 a pak rovnou skočíme do systému řízení verzí a popisu některých nejlepších praktik točících se okolo větvení a slučování pomocí Team Foundation Serveru. Na konci pak najdete rozbor některých nových změn v automatizovaném týmovém sestavovacím procesu (Team Foundation Build).

29 Část V – Správa projektu/procesu Poslední část knihy se zabývá funkcionalitou správy projektu a procesu Visual Studia 2010 a Team Foundation Serveru. Prozkoumávají se zde nové šablony procesu, které jsou dodávány s produktem, společně s novými schopnostmi pro správu soupisu zákaznických požadavků na produkt (product backlog) a pro plánování iterací a kapacit. Prozkoumávají se i reporty dodávané společně s Team Foundation Serverem. Nakonec předvedeme několik běžnějších přizpůsobení šablony procesu.

Konvence Aby text mohl být co nejvíce čtivý a šlo snadno sledovat, co se právě děje, používáme v knize řadu konvencí. Důležité. Rámečky, jako je tento, obsahují důležité informace. Jedná se o informace, které byste neměli zapomenout a které se současně přímo vztahují k okolnímu textu.

Poznámka. Takto odsazované a zvýrazňované kurzívou jsou poznámky, tipy, rady a triky.

Název odbočky Odbočky mimo aktuální výklad jsou zvýrazňované takto.

Co se týče stylů v textu: Takto zvýrazňujeme důležité termíny a důležitá slova. Klávesové zkratky vyznačujeme tradičním způsobem: Ctrl+A. Názvy souborů, URL a zdrojový kód uvnitř textu uvádíme takto: persistence.properties. Kód prezentujeme dvojím způsobem: Neproporcionálním typem písma bez zvýraznění je většina příkladů kódu. Tučně zvýrazňujeme kód, který je v prezentovaném kontextu obzvlášť důležitý.

Zdrojové soubory Zdrojové soubory k této knize lze stáhnout z následující adresy: http://zonerpress.cz/download/rizeni-zivotniho-cyklu.zip

Velikost souboru ke stažení je cca 65 MB.

Sdělte nám svůj názor Jako čtenáři této knihy se stáváte těmi nejdůležitějšími kritiky a komentátory. Vážíme si vašeho názoru a chtěli bychom vědět, co děláme správně, co bychom mohli dělat lépe, ve kterých oblastech bychom měli publikovat a také vaše další podnětné myšlenky, o které jste ochotni se podělit.

30 Jako odborný redaktor nakladatelství Zoner Press vítám vaše názory. Můžete mi psát – poslat e-mail nebo dopis – a sdělit mi, co se vám v této knize líbilo nebo nelíbilo, stejně tak co bychom měli udělat, aby naše další knihy byly lepší. Pokud mi napíšete, nezapomeňte, prosím, připojit název knihy, ISBN, jméno autora, vaše jméno a e-mail. Pozorně zhodnotím vaše názory a poskytnu je všem lidem, kteří pracovali na této knize. Prosím, vězte, že nemohu pomoci s technickými problémy, které se týkají obsahu knihy, a že díky velkému množství e-mailů, jež dostávám, nemohu zaručit odpověď na každou zprávu. E-mail: miroslav.kucera@zoner.cz nebo knihy@zoner.cz. Adresa: Zoner Press ZONER software, a.s. Miroslav Kučera Nové sady 18, 602 00 Brno

KAPITOLA 3 Návrh shora dolů s diagramy komponent a tříd Co naleznete v této kapitole? Jak se vytvářejí a používají diagramy komponent. Jak se zobrazí interní části diagramu komponent. Jak se vytvářejí a používají diagramy tříd.

V kapitole 2 jsme probrali diagramy případů užití, diagramy aktivit a sekvenční diagramy a dozvěděli jste se, jak pomáhají porozumět řešenému problému. Rovněž také víte, jak začít mapovat, jak by se měla aplikace vybudovat a čeho by se měla snažit dosáhnout. Jakmile máte tyto informace v kupě, dalším krokem je snaha vizualizovat (z vysoké úrovně) strukturu systému a poté se prokopat směrem dolů ke třídám a jiným objektům, které bude aplikace používat. V tento okamžik vstupují na scénu diagramy komponent a diagramy tříd. Tato třetí kapitola začíná úvodem do diagramů komponent. Rozebereme ukázkový diagram komponent, abyste mohli dobře porozumět všem jeho částem. Podíváme se na všechny prvky nacházející se v Toolboxu pro diagram komponent a popíšeme si různé vlastnosti, které jsou k dispozici pro všechny prvky. Výklad o diagramech komponent zakončíme pokyny ve stylu krok za krokem, jak vytvořit diagram komponent, včetně toho, jak jej využít pro modelování interního fungování komponent vyšší úrovně. Potom zde najdete spoustu informací o diagramech tříd UML (dříve se jim říkalo logické diagramy tříd). Podobně jako u diagramů komponent, i zde prozkoumáme některé existující diagramy tříd a probereme prvky Toolboxu (a jejich vlastnosti). Kapitolu zakončíme pokyny ve stylu krok za krokem, které vás provedou procesem vytvoření základní podoby diagramu tříd. Poznámka. V této kapitole se používají termíny "diagram tříd", "logický diagram tříd" a "diagram tříd UML". Všechny znamenají stejný typ diagramu.

Kapitola 3 – Návrh shora dolů s diagramy komponent a tříd

Diagramy komponent Jak jste se dozvěděli v kapitole 2, sekvenční diagramy umožňují modelovat a vizualizovat zprávy systému. S diagramem komponent (component diagram) vizualizujete nejenom komponenty systému, které implementují jeho funkcionalitu, ale také další díly skládačky tvořící dohromady celý systém (jako jsou webové služby, uživatelská rozhraní, komponenty COM atd.). Diagram komponent znázorňuje vztahy mezi různými komponentami aplikace nebo systému. Diagram komponent ukazuje části návrhu softwarového systému. Komponentami mohou být spustitelné jednotky, knihovny DLL nebo dokonce celé systémy. Na této úrovni se nemusíte snažit úplně přesně rozhodnout, jak se věci mají vybudovat. Prostě se jen pokoušíte rozkouskovat celou architekturu do něčeho, co se bude lépe spravovat a bude pochopitelnější. Diagramem komponent se prostě vizualizuje vysokoúrovňová struktura systému a chování služeb, které tyto komponenty poskytují i konzumují. Komponentu (component) chápejte jako modulární nahraditelnou jednotku. Nepotřebujete žádné znalosti o interním fungování komponenty. Stačí vědět, jaká rozhraní komponenta poskytuje nebo konzumuje. Komponenty v diagramu komponent mají jistá rozhraní (interfaces), buď požadovaná, nebo poskytovaná. Rozhraním může být cokoliv od webu až k webové službě. Požadované rozhraní (required interface) vyjadřuje funkcionalitu, kterou komponenta očekává, že bude konzumovat. Poskytované rozhraní (provided interface) vyjadřuje funkcionalitu, kterou komponenta poskytuje jiným komponentám ke konzumaci. Každé požadované rozhraní v diagramu komponent by mělo být napojeno na nějaké poskytované rozhraní. Vytváříte-li diagramy komponent, máte z nich pár milých benefitů. Vývojový tým lépe pochopí stávající návrh a možná přijde i na nějaké způsoby, jak ho vylepšit. Důležitější ale je, že pokud se uvažuje o systému jako o kolekci komponent s dobře definovanými rozhraními, vede to na lepší separaci komponent, takže se pak návrh snadněji mění, jak se v průběhu času mění požadavky.

Výklad diagramu komponent Nejlepší způsob, jak pochopit jakýkoli diagram, je podívat se na příklad a detailně ho rozebrat. Na obrázku 3.1 vidíte ukázku základního diagramu komponent systému pro online prodej knih. Čtvercové objekty na obrázku 3.1 s popisky Web Browser a Book Web Application jsou komponenty. Jak už jsme uvedli výše, komponenta je opětovně využitelný díl funkcionality systému. Komponenta poskytuje a konzumuje chování prostřednictvím různých rozhraní a může používat jiné komponenty. Komponenta se také dá chápat jako jistý druh třídy. Poznámka. Pokud chcete vidět jen záhlaví komponenty (a skrýt ostatní informace o ní), klikněte v levém horním rohu komponenty na symbol "dvě stříšky pod sebou".

Jak už víte, komponenty vystavují různá rozhraní, což je buď funkcionalita, kterou komponenta poskytuje jiným komponentám (poskytované rozhraní), nebo funkcionalita, kterou komponenta potřebuje od jiných komponent (požadované rozhraní). Požadovaná rozhraní se reprezentují půlkruhem zvaným háček (hook). Komponenta Web Browser vystavuje požadované rozhraní s názvem Book Web Site. Poskytovaná rozhraní se reprezentují uzavřeným kruhem zvaným lízátko (lollipop). Komponenta Book Payment System vystavuje poskytované rozhraní s názvem IBookPaymentService.

Řízení životního cyklu aplikací ve Visual Studiu 2010

Obrázek 3.1 Požadovaná a poskytovaná rozhraní se propojují pomocí prvku Dependency. Prvek Dependency se objeví jako přerušovaná čára s šipkou na konci, vede od požadovaného rozhraní k poskytovanému rozhraní.

Toolbox pro diagramy komponent Jednotlivé prvky a asociace, které jsou k dispozici pro diagramy komponent, vidíte na obrázku 3.2.

Obrázek 3.2 Popis jednotlivých prvků a asociací je v tabulce 3.1.

Kapitola 3 – Návrh shora dolů s diagramy komponent a tříd

Tabulka 3.1. Objekty Toolboxu pro diagramy komponent. Název

Český název

Popis

Pointer

Kurzor

Změní tvar kurzoru zpět na normální.

Dependency

Závislost

Definuje, jak prvek závisí na jiném prvku (vztah začínejte od závislého prvku).

Component

Komponenta

Přidá komponentu, která definuje opětovně využitelnou jednotku funkcionality systému.

Delegation

Delegování

Vyznačuje chování mezi portem na vnější komponentě a rozhraním na vnitřní komponentě.

Provided Interface

Poskytované rozhraní

Přidá rozhraní, které komponenta poskytuje jiným komponentám.

Required Interface

Požadované rozhraní

Přidá rozhraní, které komponenta požaduje od jiných komponent.

Comment

Komentář

Přidá komentář.

Generalization

Zobecnění

Definuje, jak se komponenta odvozuje z jiné komponenty (vztah začínejte z odvozené komponenty).

Connector

Konektor

Tento propojovací nástroj vytváří výchozí vztah mezi obrazci (na základě typů propojovaných obrazců).

Part Assembly

Assembly partu

Tento nástroj specifikuje propojení mezi party umístěnými v dané komponentě. Propojuje nějaké požadované rozhraní na jednom partu s poskytovaným rozhraním na jiném partu.

Vlastnosti prvků diagramu komponent Každý prvek v diagramu komponent má vlastnosti, s nimiž lze ve Visual Studiu 2010 manipulovat prostřednictvím okna vlastností. Chcete-li se podívat na vlastnosti nějakého prvku, klikněte na něm v diagramu pravým tlačítkem a vyberte Properties. Vlastnosti se objeví v okně Properties. Vlastnosti, které jsou k dispozici pro diagramy komponent, jsou popsány v tabulce 3.2. Tabulka 3.2. Vlastnosti prvků diagramu komponent. Vlastnost

Výchozí

Prvek

Popis

Name

Výchozí název

Všechny

Identifikuje prvek.

Qualified Name

Balíček::Název

Všechny

Jednoznačně identifikuje prvek. Prefixem je kvalifikovaný název balíčku, ve kterém je prvek obsažen.

Work Items

Všechny

Počet pracovních položek sdružených s tímto prvkem.

Řízení životního cyklu aplikací ve Visual Studiu 2010

Vlastnost

Výchozí

Prvek

Popis

Description

(prázdná)

Všechny

Sem se mohou přidat všeobecné poznámky o prvku.

Is Indirectly Instantiated

True

Component

Komponenta existuje jen jako návrhový artefakt. Za běhu existují jen její party.

Is Abstract

False

Component

Definice komponenty se může použít jen jako zobecnění, z něhož lze specializovat jiné komponenty.

Is Leaf

False

Interface

Toto rozhraní nelze specializovat.

TemplateBinding

(žádná)

Interface

Typ šablony, jejíž instanci tento typ vytváří. Rozbalte parametr, abyste se podívali na vazby parametrů šablony.

TemplateParameters

(žádná)

Interface

Seznam parametrů typu. Používá se, jedná-li se o šablonový typ. Chcete-li se podívat na vlastnosti jednotlivých parametrů, klikněte na [...].

Visibility

Public

Component, Part, Port, Interface

Public – viditelný globálně. Package – viditelný uvnitř balíčku. Private – viditelný uvnitř komponenty,

která prvek vlastní. Protected – viditelný v komponentách

odvozených z vlastníka. Type

Typ při vytvoření

Part

Typ partu je komponenta nebo třída.

Multiplicity

Part

Vyjadřuje, kolik instancí specifikovaného typu formuje part rodičovské komponenty. 1 – Přesně jedna. 0..1 – Jedna, nebo žádná. * – Kolekce o libovolném počtu. n..m – Kolekce od n do m instancí.

LinkedPackage

Model

Diagram

Výchozí jmenný prostor pro prvky přidané do tohoto diagramu.

Vytvoření diagramu komponent Ukažme si nyní, jak se vytvoří diagram komponent, který jste viděli na obrázku 3.1. (Stále pracujeme v modelovacím projektu z kapitoly 2.) V průzkumníkovi řešení klikněte pravým tlačítkem na projektu a z kontextové nabídky vyberte Add -> New Item. Vyberte šablonu Component Diagram a pojmenujte ji BookComponents.componentdiagram. Klikněte na tlačítko Add, aby se diagram vytvořil. V modelovacím projektu se nyní vytvoří prázdný diagram komponent s názvem BookComponents.componentdiagram a otevře se ve Visual Studiu 2010. V tuto chvíli můžete do diagramu přidávat komponenty.

Kapitola 3 – Návrh shora dolů s diagramy komponent a tříd

Komponenty se do diagramu přidávají dvojím způsobem. První spočívá v tom, že v Toolboxu kliknete na prvek Component a poté kliknete v diagramu na prázdném místě tam, kam chcete přidat komponentu. V diagramu se objeví prázdný prvek Component. Tento způsob je vhodný pro vytváření nových komponent. Do diagramu se také mohou přidávat existující komponenty z jiných diagramů téhož modelovacího projektu. Buď otevřete nějaký existující diagram, nebo otevřete okno průzkumníka modelu tím, že vyberete View -> Other Windows -> UML Model Explorer. Klikněte pravým tlačítkem na komponentě, kterou chcete přidat do diagramu, a vyberte Copy. Klikněte na prázdném místě v diagramu komponent a vyberte Paste Reference, čímž v novém diagramu vytvoříte kopii komponenty. Poznámka. Komponentu lze také rovnou přetáhnout z průzkumníka modelu do diagramu.

V okně Toolboxu klikněte na prvek Component a klikněte na prázdném místě v diagramu, abyste vytvořili nový prvek Component. Vyberte komponentu a změňte její název na Web Browser. Stejným postupem přidejte do diagramu komponent pět následujích komponent: Book Web Application Book Web App Database External Credit Card Processor Gateway Book Payment System Book Payment System Database

Až je všechny přidáte do diagramu komponent, měl by vypadat podobně jako na obrázku 3.3.

Obrázek 3.3 Teď, když máte v diagramu všechny komponenty, je dalším krokem ukázat u komponent všechny poskytované vztahy (prostřednictvím rozhraní, která vystavují chování služby). V okně Toolboxu klikněte na prvek

221

KAPITOLA 10 Vývoj, testování a nasazování databází Co naleznete v této kapitole?  Životní cyklus vývoje databází by měl kráčet bok po boku s životním cyklem

správy aplikace. Práce offline s databázemi ve Visual Studiu 2010. Změny ve schématu databáze. Testování schématu databáze, včetně automatického generování pseudonáhod-

ných testovacích dat. Nasazování aktualizací do schématu databáze.

Až doposud jsme se v knize zabývali nástroji a technikami, které pomáhaly budovat a testovat softwarové aplikace. Pro mnoho (ne-li pro většinu) softwarových aplikací jsou však kritickou komponentou databáze. I přes tuto skutečnost nástroje, které usnadňují vývoj, testování a nasazování, tradičně poskytují nedostatečný servis pro databáze. Databázoví vývojáři jsou obvykle ponecháni svému osudu, aby si nějak poskládali dohromady nástroje potřebné pro vývoj databází a nasazování databázových změn do provozu. Databázoví vývojáři se navíc často drží postupu, který je oddělen od procesu, jímž se řídí tým vyvíjející aplikace, což vede k systému spolupráce, který je náchylný k chybám a vyznačuje se značným pracovním vypětím. S Visual Studiem 2010 ovšem můžete realizovat proces správy databázových změn se stejnou sadou nástrojů, jaké používají ostatní členové týmu vyvíjejícího software. V této kapitole uvidíte, jak Visual Studio umožňuje sledovat a spravovat změny v databázovém schématu tím, že řídí zdrojový kód, generuje testovací data, vytváří databázové unit testy, využívá statickou analýzu databázového kódu a automaticky vytváří nasazovací (rozmisťovací) skripty, které jsou založeny na změnách modelovaných ve vývojovém prostředí. Také uvidíte, jak Visual Studio dokáže odbourat tradiční hranice, které existují mezi týmy vyvíjejícími databáze a týmy vyvíjejícími aplikace, což vede k lepší koordinaci a v konečném důsledku k produkci kvalitnějšího softwaru.

222

Kapitola 10 – Vývoj, testování a nasazování databází

Poznámka. Funkce probírané v této kapitole budou fungovat s Microsoft SQL Serverem 2005 a s databázemi SQL Serveru 2008. Microsoft rovněž spolupracuje s jinými firmami na tom, aby vznikaly všelijaké doplňky, které tuto podporu rozšíří i na jiné databáze. V době, kdy jsme psali tyto řádky, Microsoft ohlásil podporu pro Oracle a IBM DB2. V budoucnu tak lze očekávat i podporu pro další databáze.

Výzvy správy databázových změn Databázoví vývojáři čelí jedinečným výzvám, s nimiž se obvykle vůbec nemusejí potýkat jejich protějšky, vývojáři aplikací. Patří mezi ně tyto výzvy (rozhodně však nejsou jediné): Bývá obtížné vytvořit takové vývojové a testovací prostředí, které by přesně napodobovalo schéma

produkčních databází. I když se vývojová nebo testovací databáze vytvoří z přesného snímku produkční databáze, v těchto prostředích může rychle dojít k takovým změnám, že přestanou být synchronizovaná. Organizace musí často kvůli ochraně soukromí, utajení apod. omezit přístup k datům obsažených

v produkční databázi. Když ale data nejsou realistická, tým může databázi jen stěží přesně otestovat, takže vznikají chyby, které vyplují na povrch pozdě – typicky až poté, co byly změny aplikovány na produkční databázi. Chyby, k nimž dochází v ostré databázi, může být podstatně obtížnější diagnostikovat a opravit, než

když se stejné chyby zachytí ve vývojové nebo testovací fázi. Mohou také vést k nákladným přerušením obchodních činností (například ztracené nebo nesprávné objednávky zákazníků, poškozené záznamy, nebo dokonce únik citlivých dat). Když se naopak podíváme na vývoj aplikací, s jistou nadsázkou můžeme říci, že nasazení aktualizace

aplikace do provozu obvykle znamená jen nahradit její starší verzi za novější. Až uživatel spustí aplikaci znovu, načte prostě novější verzi aplikace. Správa aktualizací databáze však bývá mnohem složitější. Databáze je stavový engine (stateful engine) obsahující vazby (relace), různá omezení a samozřejmě i existující data, která se musejí zachovat. Tohle vše se musí udržovat. Zkušený správce (neboli administrátor) databáze obvykle ručně vytváří skripty, s nimiž aplikuje aktualizace, a také zajišťuje, aby všechny operace proběhly ve správném pořadí. Stručně řečeno – je to proces, který je nákladný a zároveň náchylný k chybám. Chyby, k nimž dojde během tohoto procesu, mohou prodloužit dobu, kdy je databáze mimo provoz, nehledě na skutečnosti, že jejich opravami se mohou zanést chyby nové. Proces nasazení nějaké aktualizace do produkční databáze může být jiný než ten, který se požadu-

je, chcete-li stejné změny aplikovat na jinou kopii téže produkční databáze. To se stává tehdy, když se ostré databáze posunou tak, že už nejsou synchronizované; zejména se to týká výrobců softwaru, kteří musejí distribuovat upgrady zákazníkům, kteří provozují vlastní kopie produkční databáze. Tyto produkční databáze možná běží pod různými verzemi schématu databáze, mohou obsahovat různé opravy a modifikace, které byly provedeny jen na dané kopii, nebo dokonce mohou běhat pod různými databázovými enginy (například SQL Server 2005 vs SQL Server 2008). Různorodost možných variant databázových konfigurací často vyžaduje velmi složité nasazovací skripty s podmínkovou logikou pro větvení. Tím se opět zavádějí další rizika, že se nasazení nezdaří nebo se do systému zavedou nové chyby. Ve zbytku této kapitoly budeme zkoumat přístup, který nabízí Visual Studio 2010 pro řešení těchto (i dalších) problémů sdružených s databázovým vývojem.

Řízení životního cyklu aplikací ve Visual Studiu 2010

223

Offline vývoj schématu Přístup, který Visual Studio 2010 používá pro správu databázových změn, popsali u Microsoftu jako offline vývoj schématu (offline schema development). Offline vývoj schématu umožňuje pracovat na změnách databázového schématu, aniž by se muselo udržovat připojení k ostré databázi. V mnoha organizacích je přístup k ostré databázi udělován jen databázovým administrátorům, ne vývojovým týmům. Je tudíž klíčové mít možnost offline vyvíjet a testovat v prostředí, které připomíná prostředí ostrého provozu. Vývojářům se také důrazně doporučuje vyvíjet a testovat odděleně od ostrého prostředí, aby se minimalizovalo riziko, že do něho proniknou nějaké neotestované, nebo dokonce neautorizované změny. Když se změny dělají ve vývojovém prostředí, Visual Studio je pomůže otestovat ve vývojovém prostředí a/ nebo v testovacím prostředí, které bylo k tomuto účelu zřízeno. Visual Studio také umí vygenerovat pseudorealistická data, abyste mohli podniknout adekvátní testy, a to vše bez nutnosti přistupovat ke skutečným ostrým datům. Teprve poté, co jsou změny dostatečně otestovány a zdají se připravené pro nasazení do ostrého provozu, zřídí se znovu připojení k ostré databázi. Visual Studio následně vygeneruje nezbytné skripty, které se požadují pro upgrade produkční databáze, aby odpovídala tomu, co se vymodelovalo ve vývojovém prostředí. Životní cyklus vývoje databáze (database development lifecycle) se skládá ze čtyř hlavních fází:

1. Vytvoření offline reprezentace schématu. 2. Iterační vývoj. 3. Otestování schématu. 4. Sestavení a nasazení do ostrého provozu. Tyto čtyři fáze životního cyklu vývoje databáze detailně prozkoumáme za chvilku. Zaznamenali jste, že se tyto fáze docela přesně shodují s fázemi životního cyklu vývoje aplikace (a že se dokonce mohou provádět v součinnosti se změnami aplikace)?

Offline reprezentace schématu Prvním krokem k tomu, abychom mohli správu databázových změn dělat s Visual Studiem, je vytvořit nový projekt, v němž bude uložena offline reprezentace databázového schématu. Jak jsme uvedli výše, termínem offline chápeme proces, kdy budování databáze a testování změn probíhá v izolaci, odděleně od ostré databáze. Postup, jak se vytvoří projekt a jak se do něho importuje databázové schéma, probereme v této kapitole později, v sekci "Vytvoření databázového projektu". Postup, kterým se databázové schéma dá offline, je obvykle úloha pro správce databáze. Může ho ale také provést databázový vývojář, ovšem za předpokladu, že mu budou udělena postačující přístupová oprávnění k ostré databázi. I když se doporučuje, abyste databázový projekt uložili do nějakého systému pro řízení verzí (version control system), jako je Visual Studio Team Foundation Server 2010, není to nutné. Na obrázku 10.1 je znázorněn postup, jak se dá databázové schéma offline a uloží se do systému pro řízení verzí.

224

Kapitola 10 – Vývoj, testování a nasazování databází

Obrázek 10.1

Iterační vývoj Když je schéma databáze offline, jste svobodní a můžete začít s jeho změnami. Později v této kapitole (v sekci "Změny schématu") uvidíte, že Visual Studio poskytuje několik způsobů, jak tyto změny dělat – od ruční editace jednotlivých souborů .sql až k vyřízení všech změn najednou s využitím zabudovaných refaktoračních nástrojů. Pokud se rozhodnete, že projekt uložíte do nějakého systému pro řízení verzí (jako je Team Foundation Server), bude možné, aby na změnách databázového schématu pracovalo více lidí, a to dokonce simultánně (což je známo jako paralelní vývoj). Změny se nahlašují, odhlašují, větví, slučují a porovnávají úplně stejně jako v libovolném jiném souboru, který je pod správou řízení zdrojového kódu. Proces iteračního vývoje je znázorněný na obrázku 10.2.

Obrázek 10.2

465

KAPITOLA 20 Větvení a slučování Co naleznete v této kapitole? Větvení a slučování.  Běžné strategie větvení. Ukázka implementace základního plánu větvení s Team Foundation Serverem

2010. Jedním z největších problémů, na který narážejí vývojáři softwarových projektů, je plně pochopit software, který se buduje. Tuší, jak jsou organizovány všechny aspekty vašeho softwarového projektu? Opravdu všichni pochopili, jak je organizována kódová báze a jaké důsledky s sebou nesou změny v ní? Mnoho lidé se bojí větvení v řízení verzí kvůli všelijakým dodatečným komplikacím, které to vnáší do správy jejich souborů. Vědí vývojáři přesně, kdy je jim umožněno vytvořit větev kódu a kdy se od nich předpokládá, že sloučí své změny zpět do hlavní linie? Pokud to nevědí, koledujete si o velké problémy, jakmile členové vašeho týmu začnou modifikovat kód. Při strategiích větvení a slučování jde vždy o jisté kompromisy. Největší z nich je mezi rizikovými oblastmi projektu a produktivitou. Vývojáři si často myslí, že větvení nevnáší žádnou dodatečnou zátěž, která by stála za řeč, takže nevidí nic špatného na tom, že vytvářejí novou větev kódu pokaždé, když v něm musejí udělat nějakou změnu. Možnost snadno a rychle vytvářet větve může přispívat k vyšší produktivitě vývojářů. Když se ale větve vytvářejí samoúčelně, zvyšují se tím rizika související s projektem. Jednou z hlavních rizikových oblastí, která se vztahuje k větvení, je slučování změn z větví zpět do hlavní (MAIN) linie. Čím víc máte větví, tím více se musí slučovat, slučování je stále složitější a zvyšuje se šance, že se do slučovacího procesu zavlečou nějaké chyby. Nesnažte se větvit jen proto, že jste slyšeli, že to je prima nápad. Měli byste mít nějaký plán, strategii a důvod, proč vytváříte větve a pak je slučujete. Když vytváříte svou strategii větvení a slučování, položte si otázku: "Jak tato větev podpoří vývojový projekt, na kterém dělám?" Než vytvoříte jakoukoli větev, měli byste být schopni obhájit, proč chcete větvit. Totéž se samozřejmě týká i slučování.

466

Kapitola 20 – Větvení a slučování

Tato kapitola je celá o strategiích větvení a slučování s Visual Studio Team Foundation Serverem 2010. Výklad začneme tím, že probereme nějakou základní terminologii týkající se větvení a slučování. Pak si zběžně popíšeme několik běžných strategií větvení. Poté se dozvíte podrobnosti o dvou konkrétních větvicích strategiích použitých s Visual Studio Team Foundation Serverem 2010. I když s Team Foundation Serverem je možné implementovat většinu z popisovaných strategií větvení, tyto dvě konkrétní strategie zvládnou i lidé, kteří s větvením a slučováním teprve začínají, přičemž se zároveň hodí i pro ty, kdo už s větvením a slučováním mají nějaké zkušenosti. Protože tyto dvě strategie pomáhají předvést funkce a nástroje Team Foundation Serveru, které podporují větvení a slučování, měly by vám pomoci i s pochopením, jak s tímto produktem používat i jiné strategie. To však neznamená, že by autoři knihy doporučovali tyto strategie pro všechny projekty na věčné časy. Nejprve musíte porozumět pojmům z oblasti větvení a slučování, dozvědět se, jakou podporu poskytují nástroje, a teprve poté byste měli rozhodovat o tom, která strategie větvení je nejlepší pro danou situaci v daném čase. Poznámka. Všeobecnější informace k větvení obsahuje skvělá příručka Visual Studio TFS Branching Guide 2010, která je k dispozici zdarma na http://tfsbranchingguideiii.codeplex.com.

Co je větvení a slučování Se správou konfigurace, s větvením i se slučováním je spojena spousta odborné terminologie, která může odradit lidi, kteří chtějí začít pracovat s těmito funkcemi. Objasnění terminologie je ale nezbytné k tomu, abyste byli opravdu schopni porozumět procesu větvení a slučování.

Správa konfigurace softwaru Větvení a slučování je pouze jedním z aspektů rozsáhlejšího tématu, na který je často odkazováno zkratkou SCM (Software Configuration Management, Správa konfigurace softwaru). Ve své knize "Software Engineering: A Practitioner's Approach" (New York: McGraw-Hill Science/Engineering/Math, 2009) Roger Pressman definoval SCM jako "sadu aktivit navržených pro řízení změn tak, aby se mohly identifikovat pracovní produkty (work products), které se pravděpodobně budou měnit, ustanovit vztahy mezi nimi, definovat mechanismy pro správu různých verzí těchto pracovních produktů, řídit uložené změny, provádět audity učiněných změn a vytvářet reporty o nich". SCM je důležitá, protože napomáhá k efektivnější spolupráci a komunikaci mezi členy týmu. Ačkoliv je na první pohled zřejmé, že SCM pokrývá velký rozsah témat, Visual Studio a Team Foundation Server vám pomohou se vypořádat se všemi z nich.

Základní definice Následuje několik definic základních termínů, které se používají při výkladu větvení a slučování:  Větev (branch). Nejsnadněji lze větvení pochopit tak, že když kód větvíte, pořizujete jeho kopii.

A v Team Foundation Serveru děláte přesně tohle – vytváříte si kopie svých souborů. Když větvíte své soubory v Team Foundation Serveru, vytváříte jejich fyzickou kopii na nějakém jiném umístění. Pak můžete začít s prácemi na této nové větvi. Až budete hotovi, sloučíte změny zpět s původní složkou.

Řízení životního cyklu aplikací ve Visual Studiu 2010

467

Sloučení (merge). Jedná se o proces, kdy se vezmou všechny odlišné větve a zkombinují se zpět do je-

diné kódové báze. Hlavním důvodem této činnosti je vytvořit stabilní MAIN (hlavní) linii kódu, která se dá použít k testování a ke správě vydání. Když větvíte kód z MAIN linie, zřídí se relace (vztahová cesta) mezi MAIN linií a větví. V průběhu procesu slučování se porovnávají soubory z MAIN linie se soubory ve větvi. Všechny změny, u kterých je to možné, se integrují automaticky. Jsou ovšem situace, kdy se změny musejí integrovat ručně. Když slučujete kód z rodičovské větve do dceřiné větve, abyste nacpali změny udělané v rodičovské větvi do dceřiné větve, říká se tomu dopředná integrace (forward integration, FI). Slučujete-li kód z dceřiné větve zpět do rodičovské větve, abyste zpět do rodičovské větve vtáhli všechny změny udělané v dceřiné větvi, říká se tomu reverzní integrace (reverse integration, RI).  Bezdůvodné sloučení (baseless merge). Při tomto procesu se slučují položky, které nejsou přímými

větvemi téhož. Ačkoliv je tento proces v Team Foundation Serveru 2010 k dispozici, může vést k řadě zmatečných konfliktů a všeobecně se nepovažuje za dobrou praktiku.  Vydání (release). V jistých okamžicích vývoje softwaru chcete přesunout kód z vývojového prostředí

do další fáze – tedy ho vydat, ať už ke kontrole, zda všechny části produktu mají stanovenou kvalitu, nebo k nějakému jinému účelu. Vydání se definuje jako distribuce kódu, která je určena pro specifický účel, například k již zmiňované kontrole kvality (quality assurance), nebo aby si ho mohli vyzkoušet koncoví uživatelé.

Běžné strategie větvení Jak si jistě dovedete představit, existuje mnoho různých představ a strategií o tom, jak by se měl větvit zdrojový kód. Všechny mají své dobré i špatné stránky. V praxi pravděpodobně zjistíte, že někteří lidé brání své strategie zuby nehty s horlivostí věřících. V této sekci prozkoumáme populární strategie větvení, které se v současné době používají.

Žádné větve Začneme nejběžnější a nejzákladnější strategií větvení, při které se vůbec nevětví! Věřte nebo ne, je to platná strategie větvení, která perfektně vyhovuje v mnoha situacích. Ohledně větvení si zapamatujte důležité pravidlo, že se větve mají vytvářet jen tehdy, když to opravdu potřebujete. Ačkoliv se tato strategie sice pochopí nejsnáze, nepovažujeme za příliš taktické ji detailně probírat v kapitole, která se celá věnuje větvení a slučování. Ukázku strategie bez větvení vidíte na obrázku 20.1.

Obrázek 20.1 V této strategii větvení máme jen jednu oblast kódu – hlavní (MAIN) linii. Veškerý vývoj probíhá přímo proti této kódové bázi. Soubory kódu se nahlašují a odhlašují přímo z hlavní (MAIN) linie. Chyby, které se nacházejí, se postupně opravují a nahlašují do této linie. Když je připraveno nějaké vydání, označí se popiskem (V1, V1.1 atd.) a vývoj pokračuje dál po stejné linii k dalšímu vydání.

468

Kapitola 20 – Větvení a slučování

Připomínáme, že pořád pracujete v hlavní linii (MAIN). To znamená, že chcete-li později zavést nějaké větve, je tato možnost stále otevřená. Pokud si nejste jisti, zdali nebudete v budoucnu potřebovat nějakou složitější strategii větvení, začněte prostě tím, že vytvoříte hlavní linii, a zapamatujte si, že pokud budete potřebovat další větve, budete schopni je snadno vytvořit (teprve tehdy, až budou opravdu nezbytné). Vytváříte-li větev, můžete specifikovat jmenovku (label), datum (date) nebo změnovou sadu (changeset), tedy z čeho se má větev vytvořit. Proto můžete pro kód vytvářet větve později, třeba při vydání V1, pokud se ukáže, že je to zapotřebí. Tato strategie je v pořádku pro malé týmy, které trvale pracují na téže kódové bázi. Typicky jde o tým, který vydává a podporuje vždy jen jedinou verzi aplikace. Správa procesu vydávání softwaru tímto způsobem může znamenat, že máte dlouhá období, v nichž se nemůže provádět žádný vývoj, protože je potřeba stabilizovat kódovou bázi, aby byla připravena k vydání. Klíčovým rysem větvení je to, že umožňuje paralelní vývoj kódové báze. Některé ze zde probíraných větvicích strategií mohou být užitečné dokonce pro firmy tvořené jediným vývojářem, který pracuje úplně sám.

Nová větev při každém vydání Větvení při každém vydání (branching per release) je druhá nejběžněji používaná strategie větvení. Vytvářejí se větve, které obsahují veškerý kód konkrétního vydání, jak to ilustruje obrázek 20.2.

Obrázek 20.2 Každé vydání daného softwaru má svou vlastní větev. Jak je vidět na obrázku 20.2, Vydání 1 startuje na své vlastní větvi. V době, kdy vyjde verze 1.1, začne se pracovat na Vydání 2. V tomto okamžiku se z Vydání 1 vytvoří větev Vydání 2. Vydání 1 a Vydání 2 pak pokračují ve svém vývojovém procesu. Příležitostně se z Vydání 1 slučují opravené chyby nebo jiné kritické opravy do větve Vydání 2, ale to se dělá jen výjimečně. Obvykle se postupuje tak, že pokud je vývoj na některém z vydání ukončen, větev tohoto vydání se prostě opustí. Nová větev pro každé vydání je srozumitelná strategie, protože lidem je dobře znám koncept, kdy je zdrojový kód označen vlastní jmenovkou pro každé konkrétní vydání. Tato strategie umožňuje snadno získat kód, který běží v konkrétní verzi aplikace a dobře se hodí pro organizace, které potřebují podporovat v produkčním prostředí současně více než jednu verzi aplikace. Pro jednotlivá vydání zde ovšem neprobíhá žádný paralelní vývoj – tam je to v podstatě totéž jako při strategii "žádné větve" popisované dříve.

Nová větev při nové úrovni kódu Větvení při povýšení kódu nebo také větvení při nové úrovni (code promotion branching, resp. promotion level branching) znamená, že k novému větvení dochází tehdy, když se kód dostane na novou úroveň, jak to ilustruje obrázek 20.3.

Řízení životního cyklu aplikací ve Visual Studiu 2010

469

Obrázek 20.3 Počáteční vývoj začíná na vývojové linii (Dev). Jakmile si vývojová linie (Dev) myslí, že verze 1.1 je kompletně dokončena, vytvoří se testovací linie (Test). Během testování se nacházejí chyby, které se opravují v testovací větvi (Test) a slučují zpět do vývojové větve (Dev). Jakmile je kód otestován a zdá se, že je možné ho vydat, z testovací linie se vytvoří nová větev, tentokrát to už bude ostrá linie (Prod). V této ostré větvi se kódová báze stabilizuje a připraví k vydání. Jakmile je vydána, všechny změny, které se udělaly, se sloučí zpět do testovací a vývojové větve. Tento model větvení je vhodný pro řízená prostředí, která mají v daném čase jedinou běžící ostrou verzi aplikace. Tato strategie umožňuje pokračovat ve vývoji ve vývojové větvi (Dev), zatímco je kód stabilizován v testovací větvi (Test). Také nabízí velmi vysoký stupeň viditelnosti změn, které jsou přesouvány do ostré větve.

Nová větev pro každou funkci Větvení po funkcích (branching per feature) slouží k izolaci specifických funkcí do samostatných větví, čímž se vyvarujete jejich případnému překrývání s jinými funkcemi. Ukázku větvení při každé funkci vidíte na obrázku 20.4.

Obrázek 20.4 Z hlavní linie (MAIN) se vytvářejí nové větve v závislosti na funkcích. Na obrázku 20.4 vidíte, že se v průběhu vývojového cyklu vytvořily čtyři větve – F1, F2, F3, F4. Každá větev byla vytvořena pro jinou funkci. Když se práce na dané funkci dokončily, sloučily se výsledky zpět do hlavní linie. Rozhodnete-li se vytvořit větev pro každou funkci, snažte se, aby doba života větve každé funkce byla co nejkratší, a zajistěte, aby se změny slučovaly do hlavní linie okamžitě, jakmile je daná funkce dokončena. Do-

Profesionálně

Řízení životního cyklu aplikací ve Visual Studiu 2010 Tento zásadní průvodce od několika zkušených programátorů vás provede nástroji, směrnicemi a metodologiemi, které budete potřebovat pro správu životního cyklu aplikace (Application Lifecycle Management, ALM) ve Visual Studiu 2010. Je zaměřen nejenom na praktické implementační techniky a nejlepší praktiky, ale dostanete se také k podrobným příkladům kódu a případovým studiím. Společně s nimi se vrhnete na všechny nové nástroje unifikovaného modelovacího jazyka (Unified Modeling Language, UML), pokročilé ladicí techniky, funkcionalitu manuálního testování, na novou architekturu Team Foundation Serveru 2010 a na mnoho dalších věcí. Až s touto knihou skončíte, budete schopni s Visual Studiem modelovat, navrhovat a koordinovat korporační řešení na jakékoliv úrovni.

a metriky kódu, profilace a výkon, vývoj, testování a nasazování databází, úvod do IntelliTrace.

Kniha Řízení životního cyklu aplikací ve Visual Studiu 2010 zahrnuje tato témata:

Mickey Gousset pracuje jako Senior Technical Developer pro Infront Consulting Group a je držitelem MVP pro Microsoft Visual Studio ALM.

Část I – Architekt Úvod do softwarové architektury, návrh s diagramy případů užití, návrh shora dolů s diagramy komponent a tříd, analýza aplikací s průzkumníkem architektury, diagramy vrstev. Část II – Vývojář Úvod do vývoje softwaru, unit testy s Unit Test Framework, nástroj Managed Code Analysis

Část III – Tester Úvod do testování softwaru, výkonové testy webů a zátěžové testy, manuální testy, kódové testy uživatelského rozhraní, Lab Management. Část IV – Team Foundation Server Úvod do Team Foundation Serveru, architektura Team Foundation, řízení verzí Team Foundation, větvení a slučování, Team Foundation Build. Část V – Správa projektu/procesu Úvod do správy projektu, šablony procesu, reporty, portály a dashboard, agilní plánování s plánovacími sešity, přizpůsobování šablony procesu.

O autorech:

Brian Keller pracuje jako Senior Technical Evangelist pro Microsoft Visual Studio. Ajoy Krishnamoorthy pracuje jako Senior Product Manager ve skupině Patterns and Practices společnosti Microsoft. Martin Woodward pracuje na pozici Program Manager pro Microsoft Visual Studio Team Foundation Server.

Zdrojové soubory ke knize: http://zonerpress.cz/download/rizeni-zivotniho-cyklu.zip (velikost 65 MB) DOPORUČENÁ CENA: 749 KČ KATALOGOVÉ ČÍSLO: ZR1017

ISBN 978-80-7413-102-8

Zoner Press tel.: 532 190 883 e-mail: knihy@zoner.cz www.zonerpress.cz ZONER software, a.s., Nové sady 18, 602 00 Brno

9 7 8 8 0 7 4

1 3 1 0 2 8