Ří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:
[email protected] 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
4
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.
5
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
7
Stručný obsah Část I – Architekt
31
Kapitola 1
Úvod do softwarové architektury
33
Kapitola 2
Návrh s diagramy případů užití, diagramy aktivit a sekvenčními diagramy
47
Kapitola 3
Návrh shora dolů s diagramy komponent a tříd
63
Kapitola 4
Analýza aplikací s průzkumníkem architektury
87
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
8
Podrobný obsah O autorech
4
Poděkování
5
Úvod
22
Team System – změna názvu
22
Seznam produktů Visual Studia 2010
22
Výzvy moderního softwarového vývoje
24
Vítejte ve Visual Studiu 2010
25
Řízení životního cyklu aplikace
26
Komu je kniha určena?
27
Co se v knize probírá?
28
Konvence
29
Zdrojové soubory
29
Sdělte nám svůj názor
29
Část I – Architekt
31
Kapitola 1
33
Úvod do softwarové architektury
Navrhování vizuálně
33
Modelovací strategie Microsoftu
34
Vývoj řízený modelem
35
Doménově specifické jazyky (DSL)
36
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í
38
Distribuované komponenty a opětovné využívání za běhu
38
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í
41
Diagramy aktivit
41
Sekvenční diagramy
42
Diagramy komponent
43
Diagramy tříd
43
Diagramy vrstev
43
Průzkumník architektury
44
Shrnutí
45
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í
48
Toolbox pro diagram případů použití
50
Vytvoření diagramu případů užití Diagramy aktivit
51 52
Výklad diagramu aktivit
52
Toolbox pro diagram aktivit
56
Vytvoření diagramu aktivit
57
Přidání diagramu aktivit k diagramu případů užití
58
Sekvenční diagramy
59
Výklad sekvenčních diagramů
59
Toolbox pro sekvenční diagramy
60
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
65
Vlastnosti prvků diagramu komponent
66
Vytvoření diagramu komponent
67
Zobrazení interních částí komponent
71
Diagramy tříd
74
Výklad diagramu tříd
75
Toolbox pro diagramy tříd
76
Vlastnosti typů diagramu tříd
78
Vlastnosti atributů diagramu tříd
78
Vlastnosti operací diagramu tříd
79
Vlastnosti asociací v diagramu tříd
80
Vytvoření diagramu tříd
82
Shrnutí
Kapitola 4
85
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
90
Navigace po průzkumníku architektury
90
Průzkum voleb pro jmenné prostory
92
Průzkum voleb pro třídy
94
Průzkum voleb pro členy
95
Dotazy průzkumníka architektury
97
Grafy závislostí
97
Vytvoření prvního grafu závislostí
98
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
22
Ú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
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:
[email protected] nebo
[email protected]. Adresa: Zoner Press ZONER software, a.s. Miroslav Kučera Nové sady 18, 602 00 Brno
63
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.
64
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
65
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.
66
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
0
Všechny
Počet pracovních položek sdružených s tímto prvkem.
Řízení životního cyklu aplikací ve Visual Studiu 2010
67
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
1
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.
68
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:
[email protected] 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